[Smcwg-public] SecureMail EKU in Document signing certs

[Dimitris Zacharopoulos (HARICA)]

On 23/6/2021 9:43 μ.μ., Russ Housley wrote:
> 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:
>>
>>  1. Rely on the KU of the end-entity certificate (usually the
>>     digitalSignature bit) alone, no EKU extension
>>  2. Rely on the KU AND the keyPurposeId:id-kp-emailProtection in the
>>     EKU extension
>>  3. 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 section4.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.


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