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