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

[[e-mail] (Martin Rex)]

Stefan Santesson wrote:
>
> 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.

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