[x500standard] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
- From: Denis Pinkas <denis.pinkas@xxxxxxxx>
- To: pkix <pkix@xxxxxxxx>
- Date: Tue, 19 Feb 2013 17:49:15 +0100
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 (certificates@xxxxxxxxxxx
<mailto:certificates@xxxxxxxxxxx>) of the issue and the answer was a pointer to
a FAQ,
whichincludes the following statement*
(*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".
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/0jnELviAxxo>
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.37indicates:
"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.509-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
Other related posts:
- » [x500standard] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1. - Denis Pinkas
