Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.

[Stefan Santesson <[e-mail]>]

Denis,

This is for me a since long well known fact.
Back in 2004 I managed Microsofts revision of X.509 path processing where
most standards deviations were removed or corrected. This one was
deliberately preserved. As it was a too well established method to contrain
cert usages.
Variants of this was (and probably still is) used to for example only allow
code signing EKU if that cert is supported by a path and a root that allows
code signing.
In absence of any other suitable mechanism this one was preserved.
Earlier MS had tried to invent an EKU like extension (Application Policy),
that had path processing properties, but due to lack of support of this
extension. Application Policy was abandoned.

This is one of these area where theory and practice deviate, and probably
will continue to do so for considerable time.
I raised the issue when we revised 3280 to 5280, but concluded that the
standards community was as unlikely to adopt MS implementation of EKU as it
was unlikely that MS would stop doing it.

/Stefan


From:  Denis Pinkas <[e-mail]>
Date:  Tuesday, February 19, 2013 5:49 PM
To:  pkix <[e-mail]>
Subject:  [pkix] A non-compliant use of the EKU extension in Mozilla's CA
Certificate Policy Version 2.1.

>     
>   
> Mozilla's CA Certificate Policy Version 2.1 is available at:
> http://www.mozilla.org/projects/security/certs/policy/
>  
> 
> Clause 9 of the Mozilla CA Certificate Inclusion Policy (available
>  at 
> http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html)
> states:
>  
> 9.   We encourage CAs to technically constrain all subordinate CA
> certificates. For a certificate to be considered
>  technically constrained, the certificate MUST include an Extended Key Usage
> (EKU)  <http://tools.ietf.org/html/rfc5280#section-4.2.1.12> extension
> specifying 
>  all extended key usages that the subordinate CA is authorized to issue
> certificates for.
>  The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension.
>  
> 
>  The above link points to :
> http://tools.ietf.org/html/rfc5280#section-4.2.1.12
>  
>  
>  
>   4.2.1.12 
> <http://tools.ietf.org/html/rfc5280#section-4.2.1.12#section-4.2.1.12> .
> 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 the extended key usage extension be
>  
>    present and 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 in addition to the
>  
>    particular key purposes required by the applications.  Conforming CAs
>  
>    SHOULD NOT mark this extension as critical if the anyExtendedKeyUsage
>  
>    KeyPurposeId is present.  Applications that require the presence of a
>  
>    particular purpose MAY reject certificates that include the
>  
>    anyExtendedKeyUsage OID but not the particular OID expected for the
>  
>    application.
>  
>  
>  
>    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.
>  
>  
>  
> IMO, the semantics of the EKU extension, as defined in RFC 5280 and in X.509,
> does not allow using
>  that extension in the way which is described in this document.
>  
>  
>  
> I have informed Mozilla ([e-mail]) of the issue and the answer
> was a pointer to a FAQ,
> which includes the following statement
> (https://wiki.mozilla.org/CA:CertificatePolicyV2.1
> <https://wiki.mozilla.org/CA:CertificatePolicyV2.1> ).
>  
> Frequently Asked Questions
>  
> 1. RFC 5280 <http://tools.ietf.org/html/rfc5280>  reads "In general, this
> extension will appear only in end entity certificates".
> 2.  Is it non-standard to have EKU in intermediate certificates, and will
> client software break when receiving such a certificate chain?
>> * Inclusion of EKU in CA certificates is generally allowed. NSS and CryptoAPI
>> both treat the EKU extension in intermediate certificates
>> *  as a constraint on the permitted EKU OIDs in end-entity certificates.
>> Browsers and certificate client software have been using EKU
>> *  in intermediate certificates, and it has been common for enterprise
>> subordinate CAs in Windows environments to use EKU in their
>> *  intermediate certificates to constrain certificate issuance. Therefore, it
>> is unlikely that using EKU in intermediate certificates would
>> *  break other client software.
>> * The use of the EKU extension in intermediate certificates was discussed at
>> length in the mozilla.dev.security.policy  forum.
>> <https://groups.google.com/forum/#%21topic/mozilla.dev.security.policy/0jnELv
>> iAxxo>  
>> *  We considered other options, such as standardizing a set of Policy OIDs or
>> un-deprecating NetscapeCertType. The discussion included
>> *  the concern that one interpretation of RFC 5280
>> <http://tools.ietf.org/html/rfc5280>  is that this use of EKU is
>> non-standard, but it was decided that the RFCs are not clear,
>> *  and perhaps conflicting, in regards to EKUs in CA certificates. In the
>> discussion it was pointed out that other major browsers and client
>> *  software already support this use of EKU but do not recognize
>> NetscapeCertType; and we also recognized the difficulties involved in
>> *  standardizing a set of Policy OIDs. The conclusion of the discussion was
>> that EKU is the best tool for technically constraining the types
>> *  of certificates that an intermediate certificate may sign.
>  
>  
>  
> The OID for EKU is the following: {joint-iso-itu-t(2) ds(5)
> certificateExtension(29) extKeyUsage(37)}
>  
> http://www.oid-info.com/get/2.5.29.37 <http://www.oid-info.com/get/2.5.29.37>
> indicates:
>  
> ³This field 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 field.
>  
>  More information can be found in Recommendation ITU-T X.509 (March 2000)
> <http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.50
> 9-200003-s>  and in ISO/IEC 9594-8 (2001)
> <http://www.iso.org/iso/catalogue_detail?csnumber=34551> : "Directory:
> Public-key and attribute
>  certificate frameworks".
>  
>   
> The text from the last available recommendation ITU-X.509 is as follows:
>  
> ³  8.2.2.4 Extended key usage extension
>  
> This field 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 field. This field is defined as follows:
>  
> extKeyUsage EXTENSION ::= {
>  
> SYNTAX SEQUENCE SIZE (1..MAX) OF KeyPurposeId
>  
> IDENTIFIED BY id-ce-extKeyUsage }
>  
> KeyPurposeId ::= OBJECT IDENTIFIER
>  
> A CA may assert any-extended-key-usage by using the anyExtendedKeyUsage
> identifier. This enables a CA to issue a certificate
>  that contains OIDs for extended key usages that may be required by
> certificate-using applications, without restricting the certificate
>  to only those key usages. If extended key usage would restrict key usage,
> then the inclusion of this OID removes that restriction.
>  
> anyExtendedKeyUsage OBJECT IDENTIFIER ::= { 2 5 29 37 0 }[S9]
>  
> Key purposes may be defined by any organization with a need. Object
> identifiers used to identify key purposes shall be assigned
>  in accordance with ITU-T Rec. X.660 | ISO/IEC 9834-1.
>  
> This extension may, at the option of the certificate issuer, be either
> critical or non-critical.
>  
> If the extension is flagged critical, then the certificate shall be used only
> for one of the purposes indicated.
>  
> If the extension is flagged non-critical, then it indicates the intended
> purpose or purposes of the key, and may be used in finding
>  the correct key/certificate of an entity that has multiple keys/certificates.
> If this extension is present, and the certificate-using system
>  recognizes and processes the extendedKeyUsage extension type, then the
> certificate-using system shall ensure that the certificate
>  shall be used only for one of the purposes indicated. (Using applications may
> nevertheless require that a particular purpose be indicated
>  in order for the certificate to be acceptable to that application.)
>  
> If a certificate contains both a critical key usage field and a critical
> extended key usage field, then both fields shall be processed i
>  ndependently and the certificate shall only be used for a purpose consistent
> with both fields. If there is no purpose consistent with both fields,
>  then the certificate shall not be used for any purpose².
>  
>  
>  
> Mozilla announces on https://lists.mozilla.org/listinfo/dev-security-policy:
> ³The subscribers list is only available to the list administrator².
>  So it is quite hard to know who was on the discussion list and thus who
> participated to the discussion.
>  
> Since the publication is recent (February 14, 2013), it might be appropriate
> to ask to the Mozilla community to respect the compliance
>  to the standards. In order to fulfil its needs, the Mozilla community should:
>  
> -          either define its own extension,
>  
> -          or, propose a new extension so that it can be published in an RFC
> according to the IETF rules.
>  
> Any thoughts ?
>  
> Denis 
>  
>          
> _______________________________________________ pkix mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/pkix