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

From: Denis Pinkas <[email-masked]>
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 ([email-masked]  <mailto:[email-masked]>) 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

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 19 Feb 2013 18:08:10 +0100

Bonjour,

2013/2/19 Denis Pinkas <[email-masked]>
[...]

> Mozilla announces on
> https://lists.mozilla.org/listinfo/dev-security-policy: “*The subscribers
> list is only available to the list administrator”. *
>

That's classic.

> participated to the discussion.

No, the list itself is public. You can use their newsgroup server, or
Google Groups to access it.
The discussion is accessible here
https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.security.policy/Rbc-5j6i-vY

> ****
> 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.****
>
>
I proposed to rely on certificatePolicies extension. That's the purpose of
this extension. Unfortunately, it's often incorrectly used, so that would
need a cleaning step and a definition of standardized policyIds for
specific purposes.

-- 
Erwann.

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 19 Feb 2013 13:27:30 -0500

I raised this issue with Mozilla a few
months ago (https://bugzilla.mozilla.org/show_bug.cgi?id=725351),
but didn't get anywhere.

On 02/19/2013 11:49 AM, Denis Pinkas wrote:

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) 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.  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

I have informed Mozilla ([email-masked]) of the issue and the answer was a pointer to a FAQ,
which includes the following statement (https://wiki.mozilla.org/CA:CertificatePolicyV2.1).

RFC 5280
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

The use of the EKU extension in intermediate
certificates was discussed at length in the mozilla.dev.security.policy

forum.

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
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

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 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

More information can be found in Recommendation

ITU-T X.509 (March 2000) and in ISO/IEC
9594-8 (2001): "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

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

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

---

From: "Piyush Jain" <[email-masked]>
Date: Tue, 19 Feb 2013 11:06:36 -0800

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:

-          or, propose a new extension so that it can be published in an RFC
according to the IETF rules.

Any thoughts ?

Denis 

[Piyush] What mozilla is doing is non-standard and mozilla community should
realize that they are doing a disservice to their customers by recommending
this. Their enterprise customers may not understand that EKU constraints
deployed in this way will not be followed by other clients.

Unfortunately this WG has already set precedence to twist the standards to
accommodate non-compliant, insecure implementations as long as the install
base is huge. One cannot fault Mozilla to first make sure that these changes
are adopted before it proposes any standards change. 

Having said that, there may be a genuine requirement to constraint sub CAs
on the EKUs they can put in a certificate that they issue. Given that there
is no documented use case of putting EKU in CA certificates, what is the
harm in standardizing what Mozilla is doing?

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 19 Feb 2013 20:17:55 +0100

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 <[email-masked]>
Date:  Tuesday, February 19, 2013 5:49 PM
To:  pkix <[email-masked]>
Subject:  [pkix] A non-compliant use of the EKU extension in Mozilla's CA
Certificate Policy Version 2.1.

>  at 
> http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html)
> states:
>  
> 9.   We encourage CAs to technically constrain all subordinate CA
>  technically constrained, the certificate MUST include an Extended Key Usage
> (EKU)  <http://tools.ietf.org/html/rfc5280#section-4.2.1.12> extension
> specifying 
> 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
>  
>  
>  
>    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
>  
>    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
> which includes the following statement
> (https://wiki.mozilla.org/CA:CertificatePolicyV2.1
> <https://wiki.mozilla.org/CA:CertificatePolicyV2.1> ).
>  
> 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.
>> *  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
>> *  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.
>  
>  
>  
> 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
> <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".
>  
>   
> ³  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
>  
>  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]
>  
> If the extension is flagged critical, then the certificate shall be used only
> for one of the purposes indicated.
>  
>  the correct key/certificate of an entity that has multiple keys/certificates.
> If this extension is present, and the certificate-using system
>  shall be used only for one of the purposes indicated. (Using applications may
> nevertheless require that a particular purpose be indicated
>  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².
>  to the standards. In order to fulfil its needs, the Mozilla community should:
>  
> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: Stephen Kent <[email-masked]>
Date: Tue, 19 Feb 2013 15:29:59 -0500

Denis,

I agree with your analysis of the situation, as seconded by David Cooper.

I think it unfortunate that Mozilla is advising folks to use EKU in a 
fashion that is not supported
by X.509 or 5280. (Specifically, a compliant RP should not reject a 
subordinate cert based on an EKU value
encountered in a CA cert higher in a cert path.)

While I appreciate the desire to have this sort of transitive scoping 
expressed via an EKU,
that extension, unlike some others in X.509/5280, does not offer this 
feature.  It would be
preferable to define a nee extension, rather that misinterpret an 
existing one.

Sorry, Stefan, but just because MS earlier did this doesn't make it 
right :-).

Steve

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 20 Feb 2013 16:46:20 +0100

Steve,

I don't make any statement in the context of right and wrong.

I'm merely exploring the facts of the case.

Another fact of the case is that implementers priority often put customer
demands and what works first.
This is done as far as possible by following standards, but if necessary,
by stretching them and if necessary by breaking them.

What can make those organisations change attitude is, I'm afraid, not a
yard stick held up by a standards body.

The present case is as far as I can see a complete deadlock.
Nor ITU/ISO nor PKIX can change the meaning of EKU, neither can
implementers do what they feel they need to do without breaking/stretching
the standard.

/Stefan

On 2/19/13 9:29 PM, "Stephen Kent" <[email-masked]> wrote:

>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

---

From: Piyush Jain <[email-masked]>
Date: Wed, 20 Feb 2013 08:13:25 -0800

really?

implementers can choose to define another eku like extension with a
different OID. it does not break the standards and serves their need.
Their attitude will change only when their customers start complaining that
their products are cannot inter operate with others because they don't
follow the standards.

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 20 Feb 2013 11:15:12 -0500

Actually MSFT has (or had it).  It  is (was) "application policies.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Piyush Jain
Sent: Wednesday, February 20, 2013 11:13 AM
To: Stefan Santesson
Cc: pkix
Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's CA Certificate Policy Version 2.1.

really?

implementers can choose to define another eku like extension with a different OID. it does not break the standards and serves their need.
Their attitude will change only when their customers start complaining that their products are cannot inter operate with others because they don't follow the standards.
On Feb 20, 2013 7:46 AM, "Stefan Santesson" <[email-masked]<mailto:[email-masked]>> wrote:
Steve,

/Stefan

On 2/19/13 9:29 PM, "Stephen Kent" <[email-masked]<mailto:[email-masked]>> wrote:

>[email-masked]<mailto:[email-masked]>

_______________________________________________
pkix mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pkix

---

From: Erwann Abalea <[email-masked]>
Date: Wed, 20 Feb 2013 17:26:37 +0100

2013/2/20 Piyush Jain <[email-masked]>

> Their attitude will change only when their customers start complaining
> that their products are cannot inter operate with others because they don't
> follow the standards.
>
They can define their own extension, like MS ApplicationPolicy, or
NetscapeCertType.
They can also rely on CertificatePolicies (which they do for EV
certificates, and are starting to do for DV/OV).

-- 
Erwann.

---

From: Dr Stephen Henson <[email-masked]>
Date: Wed, 20 Feb 2013 16:54:37 +0000

On 20/02/2013 16:26, Erwann Abalea wrote:
> 
> They can define their own extension, like MS ApplicationPolicy, or NetscapeCertType.
> They can also rely on CertificatePolicies (which they do for EV certificates,
> and are starting to do for DV/OV).
> 

When this issue has come up before CertificatePolicies has often been mentioned
as an option but without many details.

How would this work in practice?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: [email-masked] (Martin Rex)
Date: Wed, 20 Feb 2013 18:41:08 +0100 (CET)

> implementers do what they feel they need to do without breaking/stretching

I'm seeing flawed assumptions about the protocol feature EKU
in several places: some large companies, PKIX(IETF) and ITU/ISO.

First of all, the stuff that is defined to be processed along the
certification path (i.e. within the certficate path validation function)
are name constraints, the path length constraint of BasicConstraints,
certificate policies and certificate policy constraints.

With few exceptions EKU is a mostly useless attribute, for which the
interpretation is left _entirely_ up to the calling application --
and calling applications often ignore it (or need to do so, per spec).

rfc5280 section 6.1 does not specify processing of EKUs anywhere
-- 6.1.4 (n) is limited to processding the KeyUsage certSign,
and 6.3.3 (f) is limited to processing the KeyUsage crlSign,
and 6.1 explicitly RECOMMENDs against performing conformance
checks for stuff described in Section 4 & 5 of rfc5280.

The path validation function also does not have an input of the type
"intended key usage", so there is really nothing that the path validation
function could do about application usage.

Although there exist a few EKU definitions in rfc5280:
http://tools.ietf.org/html/rfc5280#page-45

not all of them are actually used.  id-kp-timeStamping is required
by rfc3151-Timestamps, id-kp-OCSPSigning might be used in some
places for dedicated OCSP signers (that differ from the cert issuer),
and id-kp-emailProtection might be used by some S/Mime implementations.

Two fairly useless EKUs seem to be:

   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

Above two EKUs are unknown to all versions of TLS (rfc2246-rfc5246)
**AND** unknown to the HTTP-over-TLS spec rfc2818.  Unlike the PKIX
definition of these two EKUs, usage of TLS isn't limited to
HTTP-over-TLS anyway, so these two EKUs are pretty useless with the
existing specs.

Properly defined EKU usage in app protocols seem to exist only for

id-kp-OCSPSigning      http://tools.ietf.org/html/rfc2560#section-4.2.2.2
id-kp-timeStamping     http://tools.ietf.org/html/rfc3161#section-2.3
id-kp-emailProtection  http://tools.ietf.org/html/rfc3850#section-4.4.4
                       http://tools.ietf.org/html/rfc5750#section-4.4.4

(however, it was undefined in S/Mime 2 and S/Mime 3.0, so it must be
 ignored when backwards interop is desired).

-Martin

---

From: Michael StJohns <[email-masked]>
Date: Wed, 20 Feb 2013 12:57:45 -0500

>How would this work in practice?

The simplest way would be to just use the EK usage OIDS (not the EKU cert extension OID) as "policies".  You'd have to include each and every one in all of the CA's in the chain in the policy extension (or the anyPolicy policy), but that's probably easier than defining a whole new extension and modifying the path processing algorithms to add another path-binding extension.  I'd probably also include the EK oid in the EKU of the end certificate to actually signal the cert can do what the EK oid says it can do, otherwise you get some issues where the intermediate CA has the usage bits set to sign code (for example).

A different way might be to define a "BindingExtendedKeyUsage" policy and use that in conjunction with the EKU extension to signal that the set of OIDs in an EKU must be a subset of the parents EKU OID set (and for purposes of path walking will be reduced to a subset during evaluation).  Unfortunately, the semantics of the policy extension are more in tune with turning on things (e.g. if policy A is present in the chain then you get treated better) than turning off things.  In this case, you'd have to change the meaning of the policy to say that if its present in any parent then the path processing has to do the "binding key usage" processing to that parent, otherwise the last CA in the path can just decline to place the policy in the cert it issues.

But I'd like to note that this treatment of EKs as a general class is pretty short sighted.  There are few if any key usages that you really want to control from the root, and those are more properly handled as part of the path processing implementation based on the chain characteristics, rather than trying to do something like general path-like processing for the EKU based on the parent CA.

E.g. if the attributes for the trust anchor for this chain says that the chain can't be used for signing code, then the presence of the appropriate code signing EK oid is ignored.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 20 Feb 2013 13:09:32 -0500

>   -- Key usage bits that may be consistent: digitalSignature

I've actually used this EK oid for client certificates for TLS.  The general code for accepting (and deriving user credentials from) client certificates is mostly useless.  

I've ended up getting the raw certificate (after path processing validates the basics) and pulling it apart to see if it has what I want.  This works well when you have a standard mapping from a cert/cert chain to a user credential, but you want to make sure that you aren't  - for example - accepting an email credential.

(You can't do this without writing additional processing code: I want to accept a cert that's no more than 1 CA below a known and specific root, and I want to take the UID field from the subject name of the cert as the handle for mapping the cert to the server user/role and I want this cert to be a TLS cert, any other cert that chains to one of my acceptable roots gets the guest credential and role)

Mike

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 20 Feb 2013 11:01:37 -0800

If you replace "1 below" with "n below" this strikes me as a really common use case.  It's a pity the standards don't address it clearly enough that standard software handles it more easily.

> (You can't do this without writing additional processing code: I want to accept a cert that's no more than 1 CA below a known and specific root, and I want to take the UID field from the subject na…

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 20 Feb 2013 20:22:43 +0100

Again I'm not here to defend MSFT, but I can shead some light about the
rationale.

Don't make the mistake to believe that this was done by ignorant people with
no respect for standards.
Nor assume that they were to lazy to come up with their own extension and
such.

This was introduced well over 10 years ago and I truly believe that the
engineers at the time did their best and thought they did the right thing.
They did try their own extension, but that is a rocky road. MSFT tried with
ApplicationPolicy. But it didn't do the job. Presumably because no once
cared to implement it besides Microsoft.
Certificate policy does not work either. As we at that time discovered the
hard way, certificate policy implementations are terribly broken.
A huge amount of PKI:s put policies in CA certificates that has nothing to
do with the constraining mechanism defined in X.509 and RFC 5280 path
processing.

As deployments as they are effectively prevents standards compliant path
processing of policies, the result is that no one really checks policies as
per 5280 path processing, and if they do, they don't use the resulting
policy set for anything useful.
As a result, no one discover their error and corrects it. And the problems
goes on and on forever.

/Stefan

From:  Erwann Abalea <[email-masked]>
Date:  Wednesday, February 20, 2013 5:26 PM
To:  Piyush Jain <[email-masked]>
Cc:  Stefan Santesson <[email-masked]>, pkix <[email-masked]>
Subject:  Re: [pkix] A non-compliant use of the EKU extension in Mozilla's
CA Certificate Policy Version 2.1.

>> their products are cannot inter operate with others because they don't follow
>> the standards.
> 
> Erwann. _______________________________________________ pkix mailing list

---

From: Erwann Abalea <[email-masked]>
Date: Thu, 21 Feb 2013 10:36:38 +0100

2013/2/20 Stefan Santesson <[email-masked]>
> They did try their own extension, but that is a rocky road. MSFT tried
> with ApplicationPolicy. But it didn't do the job. Presumably because no
> once cared to implement it besides Microsoft.

Then PKITS came, with some sets of tests on CertificatePolicies. I hope
that by now, major tookits (NSS/libpkix, MSCAPI, OpenSSL, ...) validates
all the tests.

> do with the constraining mechanism defined in X.509 and RFC 5280 path

That's sadly true.

> policy set for anything useful.

Policies are checked for EV validation, and may be (in the future) for DV
and OV as well.
I don't know if the performed validation is RFC5280 compliant.

Anyway, between modifying EKU semantics for a browser + asking all CAs to
update their subordinate CAs, and correctly implementing policies path
processing, which way is better?

-- 
Erwann.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 21 Feb 2013 11:57:30 +0100

> processing, which way is better?

It's not just a matter of what is better. It is a matter of what will happen
and what works.
Asking CAs to update their CA certs does no good unless they actually do it.
And that is extremely unlikely.

Sometimes I sense that standards groups slip away from a perception of what
their role is.

The standards body is not a legal institution proclaiming any rules that
product developers must follow.
The standards body produces specifications that implementers MAY use if and
wen they see any benefits in using them.

The crime committed by an implementer that ignores a standard is not
committed against the standards body, but (if at all) against its customers
and possibly towards other implementers.

So if you ask me, we should offer the implementers and stakeholders a place
to resolve the issues in a way that best serves the community.
These are matters that can't be resolved in a way that everybody is happy
with.

/Stefan