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

Jim,

For some extensions, the X.509 and PKIX I specs specify when there are
relationships that must be checked between the values in each of the
extensions present in the certs that compose a cert path (ex:
nameConstraints extension).  I can't find any text in X.509 or PKIX I that
states any requirements for checking any relationship between the values in
the extendedKeyUsage extension present in each cert in the cert path.  

Therefore, I don't agree with your implication that the S/MIME v3 Cert
Handling spec should state any requirements about checking the
extendedKeyUsage extension values in CA certs.  Furthermore, I agree with
Pat Cain's "less-is-more" philosophy (see attached message) regarding
minimizing the mandatory requirements included in the S/MIME v3 Cert
Handling spec (CERT3).  I agree with Pat that CERT3 should not require any
checks of the extendedKeyUsage extension.

- John Pawling


At 12:00 PM 2/13/98 -0800, Jim Schaad (Exchange) wrote:
> John,
>
> > I agree with your suggestion to add wording like:  "Prior to using the
> > public key included in a certificate to support S/MIME 
> > security services, if
> > the extendedKeyUsage extension is present in the certificate and is
> > indicated as being critical, then the S/MIME software MUST 
> > ensure that the
> > id-kp-emailProtection OID is present.  This check is only 
> > required for the
> > end-entity certificates."
> The above is not the way that I had read the docs and how
> extendedKeyUsage would/should be evaluated,  I am curious why you think
> that only the end-entity certificate should be checked?  I had thought
> that the entire chain should be checked even though I did not really
> expect to see any extendedKeyUsage extensions once I got off the
> end-entity certificate.
>
> I can see the case occuring where a super-CA might say that this CA can
> only be used for issuing certifiate with the e-mail purpose and I am not
> sure this should be so explicity disabled.
>
> jim

> Return-Path: <owner-ietf-smime(_at_)imc(_dot_)org>
> X-Sender: pcain(_at_)po1(_dot_)bbn(_dot_)com
> Date: Fri, 06 Feb 1998 16:05:41 -0600
> To: ietf-smime(_at_)imc(_dot_)org
> From: Pat Cain <pcain(_at_)bbn(_dot_)com>
> Subject: Re: un-*extended* key usage
> Sender: owner-ietf-smime(_at_)imc(_dot_)org
> Precedence: bulk
>
> Friends,
>
> I worry that we may end up putting too many constraints on the SMIME
> certificate(s)
> that are not related to interoperability of the protocol. We originally
> specified the 
> key-usage and name extensions because they really (REALLY) did impact
> interoperability. 
> Almost all of the other useful X.509 extensions effect how the signature or
> encrypted/random data is interpreted and/or used. For example, if I, as a
> CA, issue certificates that are good for any number of protocols, it is
> hard for me to beleive 
> that SMIME (the protocol) really cares. Think of this in the 'Do I support
> delta-CRLs' vain. I hope (pray) that we don't specify the CRL-ing technique
> -- it's a CA policy decision. Much like what uses a particular certificate
> is good for.
>
> I vote to leave specific recommendations for extended key usage, beyond
> what X.509 discusses for criticality and other stuff, out of the spec. If a
> particular CA wants 
> to require extended OIDs in their certiifcates, so be it. But that's one of
> those 
> CA 'policy kind of' things.
>
> Pat