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

I am inclined to agree with both Jim and John. 
I agree with Jim that the contents of the extended key usage extension may
have implication on the cert chain. The difficulty with extended key usage
is that the set of possible values will never be constrained, so we don't
know what all the possible outcome would be of a check. I also agree with
john that the right place to clarify this point as what the right thing to
do is in the pkix workgroup.
Trevor

-----Original Message-----
From: jsp(_at_)jgvandyke(_dot_)com [SMTP:jsp(_at_)jgvandyke(_dot_)com]
Sent: Friday, February 13, 1998 12:50 PM
To:   Ietf-Smime (E-mail)
Subject:      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

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