[Smcwg-public] SecureMail EKU in Document signing certs

[Russ Housley]

Dimitris:

>>>> Let me try one other angle.  For TLS certs to be trusted and for them to be in scope of the BRs, the root programs and browsers require that the CA have server auth in order to issue TLS certificates or they won’t be trusted.  They are also outside the scope of the BRs and those CAs do not need to be audited as TLS CAs.  The rule to have EKUs in the CA is not RFC based, but rather browser/root program based and these applications check the hierarchy to be sure that a cert with serverAuth was issued from a root and CA with those permissions.
>>>>  
>>>> Not all EKUs are treated this way, but a few are, and secure mail I think is one of them.  Would an email client reject the use of a cert issued from a CA with only the document signing EKU?  Is issuance of compliant SMIME certs limited to those CAs technically capable of issuing them (those with secure mail EKU in them)?  If so, then perhaps those document signing applications that need the secure mail EKU but do not need to actually send secure mail can continue since these are issued from CAs outside the scope of the SMIME WG spec.
>>>>  
>>>> Is this logic also flawed?
>>> 
>>> Definitely not flawed, this is a complicated topic so there is not one right answer. In my understanding, certificate consumers of S/MIME Certificates have several choices:
>>> Rely on the KU of the end-entity certificate (usually the digitalSignature bit) alone, no EKU extension
>>> Rely on the KU AND the keyPurposeId:id-kp-emailProtection in the EKU extension
>>> Rely on the KU AND the keyPurposeId:id-kp-emailProtection in the EKU extension AND ensure the Issuing CA also includes an EKU extension which includes the id-kp-emailProtection keyPurposeId
>>> Option 3 is kind of described in section 4.2.1.12 <https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12> of RFC 5280 but as you noticed, it's probably not supported by all email clients. That doesn't mean the S/MIME Working Group should not set policy requirements if clients don't take advantage of them.
>>> 
>> I disagree.  Section 4.2.1.12 of RFC 5280 says: "In general, this extension will appear only in end entity certificates."  I think that option 3 should be taken off the list.
>> 
>> I realize that many implementations use the EKU extension as a path constraint, but it was never intended to be used that way.  
> 
> Sorry for the late reply :)
> 
> If it was never intended to be used that way, the language would not say "in general,".  The option was clearly left open, purposely. The following paragraph from section 4.2.1.12 makes it very clear that the option to "restrict" exists.
> 
>    If a CA includes extended key usages to satisfy such applications,
>    but does not wish to restrict usages of the key, the CA can include
>    the special KeyPurposeId anyExtendedKeyUsage in addition to the
>    particular key purposes required by the applications. 
> 
> There is already a precedent of the CA EKU extension being used as a path constraint for Public Internet services and despite its problems, it has proved to be quite effective in terms of setting at least the policy scope. Technical implementations can take it one step further and protect Relying Parties with additional restrictions using the EKU extension as a tool to constrain the path.

I think you are misunderstanding the point of that paragraph.  The CA includes KeyUsage to limit the cryptographic operations that can be performed with the certified key, and the CA includes ExtendedKeyUsage to limit the applications that the certified public key supports.

Neither X.509 nor RFC 5280 suggests that ExtendedKeyUsage has any impact on certification path construction or validation.  BasicConstraints, NameConstraints, and PolicyConstraints are examples of certificate extension there were intended to do that.  As a result, they are all discussed in Section 6 of RFC 5280. KeyUsage does get discussed in Section 6 to ensure the certified key is appropriate for signing certificates and CRLs.

I do not expect this note to change anyone's mind (or implementation).

Russ

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20210702/03346388/attachment.html>