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 23:53:19 +0000

Denis Pinkas <[email-masked]> writes:

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

So this means almost every bit of text since RFC 2459 is invalid or illegal or
whatever happens when you change the semantics of an OID?  There are OIDs for
all sorts of things in there that have been modified and adapted in every RFC
since then.

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

Lest the hand of God come down and smite them, because we all know how
seriously God takes standards.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 21 Feb 2013 00:01:04 +0000

Martin Rex <[email-masked]> writes:

>Properly defined EKU usage in app protocols seem to exist only for
>
>[...]
>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).

emailProtection is vague enough to be useless as well, since in crypto terms
it means "any usage at all (signing, encryption, keyAgreement) as long as
email is involved somewhere".  For example a certificate that handles license
management for a spam-filtering appliance could be designated as being for
emailProtection even though it's never actually used for sending, receiving,
or processing email.

Peter.