Re: Key usage. No, wait, *extended* key usage

> To: dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil (David P. Kemp)
>
> I suggest being conformant with the PKIX interpretation of this extension
> (the OID must be present only if the extension is marked critical) for
> three reasons:
>
>  1. This is really a generalized cert validation issue, with S/MIME as the
>       particular application in question, rather than being an S/MIME issue at
>       its core. As such, it seems that being in agreement with PKIX is better
>       than being different. (Although it certainly appears that stating this
>       would not make S/MIME non-compliant with PKIX, as it includes an out for
>       applications which would presumably also apply to protocol profiles.)

I agree that S/MIME should be fully conformant with PKIX and X.509.

However, the peculiar definition of the extKeyUsage extension (if the
critical bit is set, the cert must be used only for the specified purposes,
otherwise the purposes are only advisory) and certficatePolicies extension
(similar definition) have been discussed elsewhere, and as a result of
those discussions Warwick Ford will be processing a defect report
against X.509.

The problem is overloading the critical bit for two different purposes:

1) differentiating between clients that do or do not support a particular
   extension, and
2) differentiating between extensions that are intended by the CA to be
   mandatory-to-enforce or advisory in nature.

These may sound like similar purposes, but there are cases where the
CA really wants a particular extension to be MUST-enforce for all
supporting applications, but is not willing to shut out non-supporting
applications by setting the critical bit.  The non-supporting software
will eventually be upgraded, but the intended mandatory/advisory
semantics shouldn't depend on how long it takes to flush old software
out of the system.

For the certificatePolicies and extKeyUsage extensions, it is possible to
fix the problem in two ways:

1) define two new extensions for "advisoryCertPolicies" and
"advisoryExtKeyUsage" and retain the existing extensions as the
mandatory versions, or

2) define two new extensions which contain a boolean "advisory" flag
within the syntax of the extension value, and deprecate the existing
extensions.

For future extensions, of course, it would be preferable to
include the advisory flag in the extension syntax rather than defining
two parallel extensions with similar purposes.