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

From: Peter Gutmann <[email-masked]>
Date: Wed, 20 Feb 2013 00:41:38 +0000

Stephen Kent <[email-masked]> writes:

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

The other way of looking at it is that it's unfortunate that PKIX refuses to
standardise a widely-used and -adopted practice.  As Stefan pointed out, this
is just another case of reality vs. PKIX, reality will keep being what it is
and PKIX will keep going down its own path, unconstrained by reality.

Peter.

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 20 Feb 2013 15:50:19 +0100

Peter,

I believe that you are missing a point in the standardization process:
once an OID has been defined, its semantics CANNOT be changed.

You will also notice that the OID for EKU has NOT been assigned by the 
IETF, but by ISO/ ITU-T.
So PKIX is unable to make any change in the semantics, and it is the 
same for ISO/ITU-T even
with the best will.

I do not think it would be reasonable to change the semantics of what an 
OID is.

Thus the reality is not the one you describe, but the fact that large 
companies are ignoring standards and
it is time to let them understand that the software they provide is not 
compliant with the standards.

Denis

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 20 Feb 2013 09:56:04 -0500

If all widely-used -adopted practices were good, we would adopt more of 
them.

That is clearly not the case. And, often, those who choose to adopt a 
practice
that contradicts the standards do so before approaching PKIX. In such 
cases, adopting
what has been done encourages the practice of avoiding the IETF process 
in favor
of a "big vendor has decided to do X, so let's reward them with an RFC."

That's a bad idea in any WG context.

Steve

---

From: "Piyush Jain" <[email-masked]>
Date: Wed, 20 Feb 2013 07:40:46 -0800

+1 for the response below.

Unfortunately the precedence has been set by changing standards to
accommodate implementations that incorrectly treat unknown certificates as
good in violation of 5280.
Don't underestimate the lobbying muscles of the browser forum. This time
they have two of the biggest corporations behind them :).

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stephen Kent
> Sent: Wednesday, February 20, 2013 6:56 AM
> To: Peter Gutmann; pkix
> Subject: Re: [pkix] A non-compliant use of the EKU extension in Mozilla's
CA
> Certificate Policy Version 2.1.
> 
practice
> that contradicts the standards do so before approaching PKIX. In such
cases,
> adopting what has been done encourages the practice of avoiding the IETF
> process in favor of a "big vendor has decided to do X, so let's reward
them
> with an RFC."
> >> 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.)
> > The other way of looking at it is that it's unfortunate that PKIX
> > refuses to standardise a widely-used and -adopted practice.  As Stefan
> > pointed out, this is just another case of reality vs. PKIX, reality
> > will keep being what it is and PKIX will keep going down its own path,
> unconstrained by reality.
> >
> > Peter.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 Feb 2013 07:47:11 +0000

There's an issue here of what the role of an SDO.

You can take the approach that the SDO is in charge of the technology. In that case, no certificate is valid for the Internet unless it is compliant with an RFC issued by the PKIX working group. That's a nice model, and one where the needs of multiple stakeholders will be taken into consideration. But this can and does lead to a disconnect between the standards and the practice.

Another approach is that the SDO does not define the standard, but rather it captures the standard, whether that standard was set by a big vendor implementing it or by some people on a mailing list reaching rough consensus. Of course, big vendor doesn't need the standard, but it really helps the other stakeholders catch up.

10 years ago, the browser market was dominated by Internet Explorer, and some of the HTML features it supported were not standardized. Despite the efforts of W3C, web sites optimized their HTML for IE, which left the other browsers at a significant disadvantage. In the end, the tides turned, the market dominance is gone, and websites are now written to standards so that they work with all browsers, although we are seeing a similar issue with WebKit on the mobile platforms.

If SDOs were to document IE's behavior rather than stick to their own vision of how HTML should be, it would have been easier for the other browsers to work with all sites, instead of relying on reverse engineering. It's even possible that the dominance of IE would have gone away earlier. 

This sounds bad, like an SDO rubber-stamping what the big vendor has done. It's especially bad in hindsight, because in the end the little guys (if you can consider Google and Mozilla "little guys") won, and the pure vision of HTML standards triumphed. It could have ended very differently, though.

Yoav

On Feb 20, 2013, at 4:50 PM, Denis Pinkas <[email-masked]> wrote:

> You will also notice that the OID for EKU has NOT been assigned by the IETF, but by ISO/ ITU-T.
> So PKIX is unable to make any change in the semantics, and it is the same for ISO/ITU-T even
> with the best will.
> 
> I do not think it would be reasonable to change the semantics of what an OID is.
> 
> Thus the reality is not the one you describe, but the fact that large companies are ignoring standards and
> it is time to let them understand that the software they provide is not compliant with the standards.
> 
> Denis
> 
> Email secured by Check Point

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 21 Feb 2013 12:50:57 +0100

> I do not think it would be reasonable to change the semantics of what an OID is.

Where is the conflict with X.509? There is not eveb a problem with PKIX's definitions
of concrete values IMO. In fact, PKIX has no semantics defined, just a comment
to the ASN.1 syntax.  As Peter Gutman mentioned 'email protection' means what?
There is no conflict IMO with existing specs if one would say:

- email protection means xyz. If put into and end certficate, then the cert can only
   be used for that purpose, if put into a CA cert, than this extend the path validation
   algorithm, such a CA is only supposed to issue certs that have this EKU in EE certs.

from X509:

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 independently 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.
This Directory Specification defines the following key purpose that can be included in the extended 
key usage
extension. Other purposes that can also be included are defined in other specifications, such as 
IETF RFC 5280.
keyPurposes OBJECT IDENTIFIER ::= {ds 38 1}

---

From: "Piyush Jain" <[email-masked]>
Date: Thu, 21 Feb 2013 07:41:23 -0800

Where is the conflict with X.509? There is not eveb a problem with PKIX's
> definitions of concrete values IMO. In fact, PKIX has no semantics
defined,
> just a comment to the ASN.1 syntax.  As Peter Gutman mentioned 'email
> protection' means what?
> - email protection means xyz. If put into and end certficate, then the
cert can
> only
>    be used for that purpose, if put into a CA cert, than this extend the
path
> validation
>    algorithm, such a CA is only supposed to issue certs that have this EKU
in EE
> certs.
The conflict is that some implementations have started deducing the extended
key usage of a certificate based on what EKU is present in other
certificates up in the chain.

Semantic of an extension with OID id-ce-extKeyUsage is clear. 5280 clearly
defines how this extension should be processed and that it applies only to
the certificate in which it is present.
What it does not defined is the meaning of objects contained within the EKU
extension because those meanings are application dependent - however this is
not the point that is being argued.

The way I see it, the purposeIDs that are defined in 5280 do not belong
there. Those definitions should have been part of application protocol
specification.

The fact that some of the purpose IDs are not being enforced by applications
has nothing to do with how applications deduce the purpose associated with a
cert.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 21 Feb 2013 22:45:36 +0100

Please send me and Steve a note if you have anything you wish to present
at the PKIX WG in Orlando.

The slot is for 1.5 hour and we will be a bit restrictive due to the fact
that we are not allowed to take on any new work.
But we will try to use the time if there are things of interest to discuss.

/Stefan

---

From: Stephen Kent <[email-masked]>
Date: Wed, 27 Feb 2013 00:53:30 -0500

Yoav,

Your characterization of roles for SDOs does not constitute a partition. 
There are other options.

WGs in the IETF, when we do our work well, develop good, technical 
solutions for problems,
and communicate these solutions in a clear fashion, via RFCs.

Developers may or may not follow the RFCs we produce, either by accident 
or intentionally.
Thus implementations may differ because of ambiguities in the RFCs, 
because of implementation
sloppiness, or for business reasons (which may be good reasons, or not).

If an influential vendor elects to not follow some aspect of a standard, 
other vendors may feel
that they have to accommodate the deviation adopted by the influential 
vendor, to preserve interoperability.
The deviation from a standard may have obvious, adverse security 
implications, or subtle security
problems, or may just be a security-neutral alternative.

A WG can elect to modify a standard, to accommodate what has become 
common practice, or not.
If the WG modifies the RFC, and if the modification has adverse security 
implications, this
is bad. Even if the deviation from the standard is security-neutral, the 
change sets a bad
precedent, as it undermines the standards development process in which 
others invested time
and effort.

 From my perspective, making a change to a standard to accommodate 
deviations from the standard,
when the change does not address a bug in the standard, rewards bad 
behavior, and it cheapens RFCs.
I oppose such behavior in any IETF WG.

Steve