[pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
Denis Pinkas <denis.pinkas@bull.net> Tue, 19 February 2013 16:49 UTC
Return-Path: <denis.pinkas@bull.net>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2511921F8D0B for <pkix@ietfa.amsl.com>; Tue, 19 Feb 2013 08:49:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.248
X-Spam-Level:
X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U767oN2IbSG9 for <pkix@ietfa.amsl.com>; Tue, 19 Feb 2013 08:49:21 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0A34821F8E01 for <pkix@ietf.org>; Tue, 19 Feb 2013 08:49:21 -0800 (PST)
Received: from MSGC-007.bull.fr (unknown [129.184.87.136]) by odin2.bull.net (Bull S.A.) with ESMTP id 2483E1D247; Tue, 19 Feb 2013 17:49:20 +0100 (CET)
Received: from [127.0.0.1] ([129.184.39.15]) by MSGC-007.bull.fr (Lotus Domino Release 8.5.3FP1) with ESMTP id 2013021917491916-40696 ; Tue, 19 Feb 2013 17:49:19 +0100
Message-ID: <5123AD0B.4050709@bull.net>
Date: Tue, 19 Feb 2013 17:49:15 +0100
From: Denis Pinkas <denis.pinkas@bull.net>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: pkix <pkix@ietf.org>
X-MIMETrack: Itemize by SMTP Server on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 19/02/2013 17:49:19, Serialize by Router on MSGC-007/SRV/BULL(Release 8.5.3FP1|March 07, 2012) at 19/02/2013 17:49:20, Serialize complete at 19/02/2013 17:49:20
Content-Type: multipart/alternative; boundary="------------050608020508000407000500"
Subject: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Feb 2013 16:49:27 -0000
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@mozilla.org <mailto:certificates@mozilla.org>) 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
- [pkix] A non-compliant use of the EKU extension i… Denis Pinkas
- Re: [pkix] A non-compliant use of the EKU extensi… Erwann Abalea
- Re: [pkix] A non-compliant use of the EKU extensi… David A. Cooper
- Re: [pkix] A non-compliant use of the EKU extensi… Piyush Jain
- Re: [pkix] A non-compliant use of the EKU extensi… Stefan Santesson
- Re: [pkix] A non-compliant use of the EKU extensi… Stephen Kent
- Re: [pkix] A non-compliant use of the EKU extensi… Peter Gutmann
- Re: [pkix] A non-compliant use of the EKU extensi… Denis Pinkas
- Re: [pkix] A non-compliant use of the EKU extensi… Stephen Kent
- Re: [pkix] A non-compliant use of the EKU extensi… Piyush Jain
- Re: [pkix] A non-compliant use of the EKU extensi… Stefan Santesson
- Re: [pkix] A non-compliant use of the EKU extensi… Piyush Jain
- Re: [pkix] A non-compliant use of the EKU extensi… Santosh Chokhani
- Re: [pkix] A non-compliant use of the EKU extensi… Erwann Abalea
- Re: [pkix] A non-compliant use of the EKU extensi… Dr Stephen Henson
- Re: [pkix] A non-compliant use of the EKU extensi… Martin Rex
- Re: [pkix] A non-compliant use of the EKU extensi… Michael StJohns
- Re: [pkix] A non-compliant use of the EKU extensi… Michael StJohns
- Re: [pkix] A non-compliant use of the EKU extensi… Henry B. Hotz
- Re: [pkix] A non-compliant use of the EKU extensi… Stefan Santesson
- Re: [pkix] A non-compliant use of the EKU extensi… Peter Gutmann
- Re: [pkix] A non-compliant use of the EKU extensi… Peter Gutmann
- Re: [pkix] A non-compliant use of the EKU extensi… Yoav Nir
- Re: [pkix] A non-compliant use of the EKU extensi… Erwann Abalea
- Re: [pkix] A non-compliant use of the EKU extensi… Stefan Santesson
- Re: [pkix] A non-compliant use of the EKU extensi… Peter Sylvester
- Re: [pkix] A non-compliant use of the EKU extensi… Piyush Jain
- [pkix] Agenda items for PKIX in Orlando Stefan Santesson
- Re: [pkix] A non-compliant use of the EKU extensi… Stephen Kent
- [pkix] PKIX WG's (lack of) agility to adopt missi… Martin Rex