[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.  Years ago I wrote an Internet-Draft about a way to impose constraints on the EKU extension, but by that point too many implementations were locked into the current approach.

Russ

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