Blake,
RFC3280 requires a client who understands an extension to implement its
contents regardless of the criticality flag. The critical flag tells a
client who don't understand that extension if it they can use the cert
or not.
So
If the extended key usage extension is present and the client implements
the extension, and it does not contain at least one of the
anyExtendedKeyUsage or the emailProtection key purpose Ids, then the
certificate is not considered suitable for verifying signatures or key
management. Otherwise,
continue with normal certificate processing.
If you don't understand the extension then you are simply following the
criticality flag so there is no specific behaviour required by S/MIME in
this case except beyond what's in 3280.
Trevor
-----Original Message-----
From: Blake Ramsdell [mailto:blake(_at_)brutesquadlabs(_dot_)com]
Sent: Wednesday, February 19, 2003 3:45 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Extended Key Usage extension and S/MIME
I received a request to include language regarding the extended key
usage certificate extension in the next version of the CERT draft.
It seems that the language is basically:
If the extended key usage extension is present and marked critical, and
it does not contain at least one of the anyExtendedKeyUsage or the
emailProtection key purpose Ids, then the certificate is not considered
suitable for verifying signatures or key management. Otherwise,
continue with normal certificate processing.
So the point is that if:
1. The extension is present and not marked critical, and doesn't contain
emailProtection or anyExtendedKeyUsage, no one cares because it isn't
critical, and processing continues
2. The extension is present and marked critical and doesn't contain
emailProtection or anyExtendedKeyUsage, it's rejected
3. If it's not present, then processing continues
Anyone have any understanding of the current use of this extension, so
that we might have some assurance that this is the right way to move
forward, or is that outside the scope of this?
Blake
--
Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com