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)
</ul>
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 </table> 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</code> (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 </ul> W niektórych certyfikatach niekwalifikowanych te rozszerzenia (Netscape i X.509) są ze sobą pomieszane, zwykle dublując swoje znaczenie.