Encyklopedia PKI: X.509 extendedKeyUsage

Submitted by Paweł Krawczyk on czw., 2006-12-21 16:42

extendedKeyUsage

Trzeba pamiętać, że omawiane wcześniej rozszerzenie X.509 keyUsage określa zastosowania klucza bądź certyfikatu na wysokim poziomie abstrakcji, bez precyzowania konkretnych protokołów lub produktów. Nie zawsze jest to wystarczające - na przykład wystawiając certyfikat z keyUsage=digitalSignature na potrzeby podpisywania maili S/MIME niekoniecznie naszą intencją musi być również wykorzystanie go do podpisywania aplikacji.

Dodatkowe rozszerzenie extendedKeyUsage określa zastosowanie danego klucza bardzo precyzyjnie, wręcz "produktowo". RFC 3280 "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" definiuje następujące wartości tego pola:

    serverAuth (1.3.6.1.5.5.7.3.1) - uwierzytelnienie serwera SSL/TLS
    clientAuth (1.3.6.1.5.5.7.3.2) - uwierzytelnienie klienta SSL/TLS
    codeSigning (1.3.6.1.5.5.7.3.3) - podpisywanie kodu aplikacji (głównie Java i MS Authenticode)
    emailProtection (1.3.6.1.5.5.7.3.4) - podpisywanie i/lub szyfrowanie poczty elektronicznej (S/MIME)
    timeStamping (1.3.6.1.5.5.7.3.8) - podpisywanie znaczników czasowych (timestamp)
    ocspSigning (1.3.6.1.5.5.7.3.9) - podpisywanie odpowiedzi OCSP

Poza wyżej wymienionymi poprzednia wersja tego RFC (RFC 2459, appendix A.2, str. 87) definiowała następujące wartości:

    ipsecEndSystem (1.3.6.1.5.5.7.3.5) -- IP security end system
    ipsecTunnel (1.3.6.1.5.5.7.3.6) -- IP security tunnel termination
    ipsecUser (1.3.6.1.5.5.7.3.7) -- IP security user

Draft IETF draft-ietf-ipsec-pki-req, zamiast nich ("these object identifiers never achieved any significant use
in the IPsec community") proponował jedną flagę 

draft-ietf-ipsec-pki-req-03.txt
iKEIntermediate  (1.3.6.1.5.5.8.2.2)
. Draft wygasł jednak w 2000 roku, a w RFC 3280 się nie pojawiły.

Dodatkowo spotyka się jeszcze dwie wartości prywatne, które w czasach amerykańskich ograniczeń eksportowych na produkty kryptograficzne odblokowywały silną kryptografię w serwerach Microsoftu i Netscape:

  • microsoftSGC (1.3.6.1.4.1.311.10.3.3)
  • netscapeSGC (2.16.840.1.113730.4.1)

keyUsage

Wartościom extendedKeyUsage powinny towarzyszyć odpowiednie wartości rozszerzenia keyUsage. Poniższa tabelka (za RFC 3280) wskazuje jakie kombinacje mogą mieć sens, o tym jakie konkretnie wartości mają występować powinien decydować wystawca certyfikatu w zależności od tego, jak konkretnie mechanizmy kryptograficzne wykorzystuje.

extendedKeyUsage keyUsage
serverAuth digitalSignature, keyEncipherment, keyAgreement
clientAuth digitalSignature, keyAgreement
codeSigning digitalSignature
emailProtection digitalSignature, nonRepudiation, keyEncipherment, keyAgreement
timeStamping digitalSignature, nonRepudiation
OCSPSigning digitalSignature, nonRepudiation

Rozszerzenia Netscape

Opisane wyżej rozszerzenie extendedKeyUsage w pewnym stopniu dubluje wprowadzone w latach 90-tych rozszerzenia Netscape o nazwie netscape-cert-type. Przyjmowały one prawie takie same wartości jak extendedKeyUsage wprowadzone przez IETF.

Rozszerzenie code>netscape-cert-type (OID 2.16.840.1.113730.1.1) jest ciągiem bitowym, gdzie kolejne bity oznaczają odpowiednio:

  • bit-0 SSL client
  • bit-1 SSL server
  • bit-2 S/MIME
  • bit-3 Object Signing
  • bit-4 Reserved
  • bit-5 SSL CA
  • bit-6 S/MIME CA
  • bit-7 Object Signing CA

W niektórych certyfikatach niekwalifikowanych te rozszerzenia (Netscape i X.509) są ze sobą pomieszane, zwykle dublując swoje znaczenie.