[Openswan Users] X.509 key usage
Andreas Steffen
andreas.steffen at strongsec.net
Mon Jul 19 16:43:53 CEST 2004
Hi Gregor,
The IETF draft document <draft-ietf-pki4ipsec-ikecert-profile-00.txt>
"The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX"
recommends the following:
4.1.3. X.509 Certificate Extensions
Conforming applications MUST recognize extensions which must or may
be marked critical according to this specification. These extensions
are: KeyUsage, SubjectAltName, and BasicConstraints.
Implementations SHOULD generate certificates such that the extension
criticality bits are set in accordance with PKIX and this document.
With respect to PKIX compliance, implementations processing
certificates MAY ignore the value of the criticality bit for
extensions that are supported by that implementation, but MUST
support the criticality bit for extensions that are not supported by
that implementation. That is, if an implementation supports (and thus
is going to process) a given extension, then it isn't necessary to
reject the certificate if the criticality bit is different from what
PKIX states it must be. However, if an implementation does not
support an extension that PKIX mandates be critical, then the
implementation must reject the certificate.
implements bit in cert PKIX mandate behavior
------------------------------------------------------
yes true true ok
yes true false ok or reject
yes false true ok or reject
yes false false ok
no true true reject
no true false reject
no false true reject
no false false ok
4.1.3.3. KeyUsage
The meaning of the nonRepudiation bit is not defined in the context
of IPsec, although implementations SHOULD interpret the
nonRepudiation bit as synonymous with the digitalSignature bit.
Implementations SHOULD NOT generate certificates which only assert
the nonRepudiation bit.
See PKIX for general guidance on which of the other KeyUsage bits
should be set in any given certificate.
4.1.3.13. ExtendedKeyUsage
No ExtendedKeyUsage usages are defined specifically for IPsec, so if
this extension is present and marked critical, use of this
certificate for IPsec MUST be treated as an error unless the
extension contains the anyExtendedKeyUsage keyPurposeID, which
asserts that the certificate can be used for any purpose.
Implementations MAY ignore this extension if it is marked non-
critical. Implementations MUST NOT generate this extension in
certificates which are being used for IPsec.
Note that a previous proposal for the use of three ExtendedKeyUsage
values is obsolete and explicitly deprecated by this specification.
For historical reference, those values were id-kp-ipsecEndSystem,
id-kp-ipsecTunnel, and id-kp-ipsecUser.
The more general PKIX certificate profile (RFC 3280) defines
4.2.1.3 Key Usage
The key usage extension defines the purpose (e.g., encipherment,
signature, certificate signing) of the key contained in the
certificate. The usage restriction might be employed when a key that
could be used for more than one operation is to be restricted. For
example, when an RSA key should be used only to verify signatures on
objects other than public key certificates and CRLs, the
digitalSignature and/or nonRepudiation bits would be asserted.
Likewise, when an RSA key should be used only for key management, the
keyEncipherment bit would be asserted.
This extension MUST appear in certificates that contain public keys
that are used to validate digital signatures on other public key
certificates or CRLs. When this extension appears, it SHOULD be
marked critical.
id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 }
KeyUsage ::= BIT STRING {
digitalSignature (0),
nonRepudiation (1),
keyEncipherment (2),
dataEncipherment (3),
keyAgreement (4),
keyCertSign (5),
cRLSign (6),
encipherOnly (7),
decipherOnly (8) }
Bits in the KeyUsage type are used as follows:
The digitalSignature bit is asserted when the subject public key
is used with a digital signature mechanism to support security
services other than certificate signing (bit 5), or CRL signing
(bit 6). Digital signature mechanisms are often used for entity
authentication and data origin authentication with integrity.
The nonRepudiation bit is asserted when the subject public key is
used to verify digital signatures used to provide a non-
repudiation service which protects against the signing entity
falsely denying some action, excluding certificate or CRL signing.
In the case of later conflict, a reliable third party may
determine the authenticity of the signed data.
Further distinctions between the digitalSignature and
nonRepudiation bits may be provided in specific certificate
policies.
The keyEncipherment bit is asserted when the subject public key is
used for key transport. For example, when an RSA key is to be
used for key management, then this bit is set.
The dataEncipherment bit is asserted when the subject public key
is used for enciphering user data, other than cryptographic keys.
The keyAgreement bit is asserted when the subject public key is
used for key agreement. For example, when a Diffie-Hellman key is
to be used for key management, then this bit is set.
The keyCertSign bit is asserted when the subject public key is
used for verifying a signature on public key certificates. If the
keyCertSign bit is asserted, then the cA bit in the basic
constraints extension (section 4.2.1.10) MUST also be asserted.
The cRLSign bit is asserted when the subject public key is used
for verifying a signature on certificate revocation list (e.g., a
CRL, delta CRL, or an ARL). This bit MUST be asserted in
certificates that are used to verify signatures on CRLs.
The meaning of the encipherOnly bit is undefined in the absence of
the keyAgreement bit. When the encipherOnly bit is asserted and
the keyAgreement bit is also set, the subject public key may be
used only for enciphering data while performing key agreement.
The meaning of the decipherOnly bit is undefined in the absence of
the keyAgreement bit. When the decipherOnly bit is asserted and
the keyAgreement bit is also set, the subject public key may be
used only for deciphering data while performing key agreement.
This profile does not restrict the combinations of bits that may be
set in an instantiation of the keyUsage extension. However,
appropriate values for keyUsage extensions for particular algorithms
are specified in [PKIXALGS].
4.2.1.13 Extended Key Usage
This extension indicates one or more purposes for which the certified
public key may be used, in addition to or in place of the basic
purposes indicated in the key usage extension. In general, this
extension will appear only in end entity certificates. This
extension is defined as follows:
id-ce-extKeyUsage OBJECT IDENTIFIER ::= { id-ce 37 }
ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECT IDENTIFIER
Key purposes may be defined by any organization with a need. Object
identifiers used to identify key purposes MUST be assigned in
accordance with IANA or ITU-T Recommendation X.660 [X.660].
This extension MAY, at the option of the certificate issuer, be
either critical or non-critical.
If the extension is present, then the certificate MUST only be used
for one of the purposes indicated. If multiple purposes are
indicated the application need not recognize all purposes indicated,
as long as the intended purpose is present. Certificate using
applications MAY require that a particular purpose be indicated in
order for the certificate to be acceptable to that application.
If a CA includes extended key usages to satisfy such applications,
but does not wish to restrict usages of the key, the CA can include
the special keyPurposeID anyExtendedKeyUsage. If the
anyExtendedKeyUsage keyPurposeID is present, the extension SHOULD NOT
be critical.
If a certificate contains both a key usage extension and an extended
key usage extension, then both extensions MUST be processed
independently and the certificate MUST only be used for a purpose
consistent with both extensions. If there is no purpose consistent
with both extensions, then the certificate MUST NOT be used for any
purpose.
The following key usage purposes are defined:
anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 }
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }
-- TLS WWW server authentication
-- Key usage bits that may be consistent: digitalSignature,
-- keyEncipherment or keyAgreement
id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }
-- TLS WWW client authentication
-- Key usage bits that may be consistent: digitalSignature
-- and/or keyAgreement
id-kp-codeSigning OBJECT IDENTIFIER ::= { id-kp 3 }
-- Signing of downloadable executable code
-- Key usage bits that may be consistent: digitalSignature
id-kp-emailProtection OBJECT IDENTIFIER ::= { id-kp 4 }
-- E-mail protection
-- Key usage bits that may be consistent: digitalSignature,
-- nonRepudiation, and/or (keyEncipherment or keyAgreement)
id-kp-timeStamping OBJECT IDENTIFIER ::= { id-kp 8 }
-- Binding the hash of an object to a time
-- Key usage bits that may be consistent: digitalSignature
-- and/or nonRepudiation
id-kp-OCSPSigning OBJECT IDENTIFIER ::= { id-kp 9 }
-- Signing OCSP responses
-- Key usage bits that may be consistent: digitalSignature
-- and/or nonRepudiation
As you can see the matter is quite complex and it must be taken into
consideration that not many Certification Authorities strictly conform
to the PKIX profile. The introduction of strict keyUsage checks might
potentially break a considerable number of existing IPsec applications.
Gregor, in your opinion, what would be the gain in terms of
increased security by heeding the keyUsage flags? Which would be the
most important checks you'd like to see implemented in *swan?
Kind regards
Andreas
Gregor Bethlen wrote:
> Hello Andreas,
>
> thank you for your response. Do you know if there are any plans to include a
> (extended)keyUsage-check in further *swan-implementations?
>
> Bye,
>
> Gregor
>
> Andreas Steffen <andreas.steffen at strongsec.net> schrieb am 19.07.04 13:54:15:
>
>
>> The keyUsage and extendedKeyUsage flags are not checked by *swan.
>>
>> An exception are the OCSP signing certificates introduced with the X.509
>> patch version >= 1.5, where the OCSPSigning flag must be mandatorily set in
>> the extendedKeyUsage field.
>>
>> Intermediate CA certificates sent via PKCS#7-wrapped certificate payloads
>> must have the CA basicContraints field set to TRUE in order to get
>> accepted.
>>
>> Regards
>>
>> Andreas
>>
>> Gregor Bethlen wrote:
>>
>>> Hello list,
>>>
>>> I wondered if OpenS/WAN refers to the keyUsage and
>>> extendedKeyUsage-Fields in X.509-certificate-extensions. I found nothing
>>> in readme.X509, and on an archived mailing-list-entry from FreeS/WAN it
>>> said, just the DN and the Public Key are used. (I hope, the signature
>>> gets proofed, though.) Since this mail was from somewhat 2001, I
>>> wondered, if the keyUsage gets checked by OpenS/WAN.
>>>
>>> Thanks for any answers,
>>>
>>> Gregor ____________________________________________________ Aufnehmen,
>>> abschicken, nah sein - So einfach ist WEB.DE Video-Mail:
>>> http://freemail.web.de/?mc=021200
=======================================================================
Andreas Steffen e-mail: andreas.steffen at strongsec.com
strongSec GmbH home: http://www.strongsec.com
Alter Zürichweg 20 phone: +41 1 730 80 64
CH-8952 Schlieren (Switzerland) fax: +41 1 730 80 65
==========================================[strong internet security]===
More information about the Users
mailing list