ietf-smime
[Top] [All Lists]

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

1998-02-05 13:39:57
From: jsp(_at_)jgvandyke(_dot_)com (John Pawling)

The only keyUsage-related text that I believe is appropriate for inclusion
in the S/MIME Cert Spec is:  "Prior to verifying the signature of an S/MIME
message, if the keyUsage extension is present in the signer's certificate
and is indicated as being critical, then the verifying software MUST ensure
that the nonRepudiation bit is set to 1."

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."

- John Pawling


John,

I agree with the intent of these suggestions, but have a problem with
the interpretation of the critical bit.

I believe that S/MIME software which supports the keyUsage and
extendedKeyUsage extensions MUST always ensure that the above checks
are done, regardless of whether the extensions are marked critical.
The only question is whether the S/MIME cert profile mandates support
for these extensions.

If S/MIME compliant software must support them then the wording would
be simply: "... if the extendedKeyUsage extension is present in the
certificate, then the S/MIME software MUST ensure that the
id-kp-emailProtection OID is present."

If S/MIME compliant software is not required to support the extensions,
then either the MUST can be changed to SHOULD, or the statements can
be omitted entirely, allowing the standard criticality processing to
reject the certificate if the extensions are marked critical but are
not supported by the software.

I recommend that the two suggested texts be included in the S/MIME
Cert Spec, with the phrase "and is indicated as being critical"
deleted from each.

Dave Kemp