[Smcwg-public] SecureMail EKU in Document signing certs

Wed Jun 23 08:28:26 UTC 2021

On 14/6/2021 1:57 μ.μ., Doug Beattie wrote:
>
> Hi Dimitris,
>
> I had a feeling that was the case.
>
> 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 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.

Put differently, if a CA Certificate has an EKU extension which does not 
include the /id-kp-emailProtection/ keyPurposeId, it would make sense 
for it to be out of scope of the SMBRs, although some email clients 
would treat them as valid S/MIME certificate issuers. We must draw the 
line somewhere. A similar approach was taken by the Server Certificate 
Working Group for the TLS Baseline Requirements.

Dimitris.

> Doug
>
> *From:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
> *Sent:* Monday, June 14, 2021 1:15 AM
> *To:* Doug Beattie <doug.beattie at globalsign.com>; SMIME Certificate 
> Working Group <smcwg-public at cabforum.org>; Stephen Davidson 
> <Stephen.Davidson at digicert.com>
> *Subject:* Re: [Smcwg-public] SecureMail EKU in Document signing certs
>
>
> Hi Doug,
>
> I believe you are describing an ideal situation and I wish things were 
> as simple as stated :-)
>
> I don't recall the WG having a "scope" discussion based on the 
> certificatePolicies extension but rather on EKU. My understanding is 
> that if an EE or intermediate CA Certificate includes the 
> id-kp-emailProtection keyPurposeId, it will be in scope of these new 
> SMBRs. That's why Stephen and others are trying to be as inclusive as 
> possible to accommodate other purposes so that it will not break 
> existing implementations. It will take us years before S/MIME 
> Certificate Consumers reach a level of restricting certificates based 
> on policy OIDs. So far, such a restriction has failed in the TLS world.
>
>
> Dimitris.
>
>
> On 10/6/2021 4:18 μ.μ., Doug Beattie via Smcwg-public wrote:
>
>     I'm sorry I missed the working group meeting, but wanted to point out
>
>     something that might help us focus on the charter and how to address other
>
>     use cases for EE certificates that need to contain the Secure Mail EKU.
>
>     It's my understanding that this WG is defining rules for secure mail
>
>     certificates and those will have a specific Cert Policy OID in them to
>
>     indicate that they comply.  That will show adherence to the spec and
>
>     auditors will audit these certs against this spec.  Certificates without one
>
>     of these CABF EKUs are outside the scope of this spec and WG.  I don't think
>
>     (please correct me, I could be wrong) this spec precludes CAs from
>
>     continuing to issue pubic trust certificates with the secure mail EKU but
>
>     with other certificate policies, does it?  Of course they won't be trusted
>
>     by email clients that have taken steps to only trust compliant certificates.
>
>     Basically I'm assuming that mail clients will look at the Root, CA, EE
>
>     certificate for proper EKU AND EE certificate certificate policy to
>
>     determine trust.
>
>     Assuming this is true, then CAs can continue issuing certificates with the
>
>     secure mail EKU in them for other purposes, such as document signing so long
>
>     as they do not include the CABF Cert Policy OIDs.
>
>     Am I making poor assumptions?
>
>     Doug
>
>     -----Original Message-----
>
>     From: Smcwg-public<smcwg-public-bounces at cabforum.org>  <mailto:smcwg-public-bounces at cabforum.org>  On Behalf Of Stephen
>
>     Davidson via Smcwg-public
>
>     Sent: Wednesday, June 9, 2021 2:28 PM
>
>     To: SMIME Certificate Working Group<smcwg-public at cabforum.org>  <mailto:smcwg-public at cabforum.org>
>
>     Subject: [Smcwg-public] Approved Minutes of SMCWG May 26, 2021
>
>     Minutes of SMCWG
>
>     May 26, 2021
>
>       
>
>     These are the Minutes of the Teleconference described in the subject of this
>
>     message. Corrections and clarifications where needed are encouraged by
>
>     reply.
>
>     Attendees
>
>     Adrian Mueller (SwissSign), Ali Gholami (Telia Company), Andrea Holland
>
>     (SecureTrust), Andreas Henschel (D-TRUST), Atsushi Inaba  (GlobalSign), Ben
>
>     Wilson (Mozilla), Bruce Morton (Entrust), Chris Kemmerer  (SSL.com), Clint
>
>     Wilson (Apple), Corey Bonnell  (DigiCert), Curt Spann (Apple), Dimitris
>
>     Zacharopoulos (HARICA), Don Sheehy (WebTrust), Hazhar Ismail (MSC
>
>     Trustgate.com), Hongquan Yin  (Microsoft), Inigo Barreira (Sectigo), Klauss
>
>     Voss (Zertificon), Mads Henriksveen  (BuyPass), Mauricio Fernandez
>
>     (TeleTrust), Morad Abou Nasser (TeleTrust), Niko Carpenter (SecureTrust),
>
>     Pedro Fuentes (OISTE), Rebecca Kelley (Apple), Renne Rodriguez (Apple), Russ
>
>     Housley (Vigil Security), Sebastian Schulz (GlobalSign), Stefan Selbitschka
>
>     (rundQuadrat), Stephen Davidson (DigiCert), Tadahiko Ito (SECOM Trust
>
>     Systems), Thomas Zermeno (SSL.com), Tim Crawford (WebTrust), Wendy Brown
>
>     (Federal PKI)
>
>     1. Roll Call
>
>     The Roll Call was taken.
>
>     2. Read Antitrust Statement
>
>     The Antitrust/Compliance Statement was read.
>
>     3. Review Agenda
>
>     4. Approval of minutes from last teleconference
>
>     The minutes of the May 12 teleconference were approved.
>
>     5. Discussion of certificate profile
>
>     The discussion regarding the Mailbox-validation Legacy profile continued.
>
>       
>
>     Discussion took place between regarding the overlap between certificates
>
>     intended for S/MIME and those intended for document signing, both of which
>
>     may use the emailProtection EKU. The document signing certs may not have an
>
>     email address or the digitalSignature keyUsage.
>
>       
>
>     In our effort to improve the S/MIME ecosystem we must be mindful of the
>
>     SMCWG Charter proscription of breaking other use cases.
>
>       
>
>     There was a reminder of the IETF Internet-draft to create a generic EKU for
>
>     document signing, which would assist in separating the S/MIME and document
>
>     signing use cases.
>
>       
>
>     The SMCWG Charter defines both that our deliverable address certs that
>
>     contain the contain the emailProtection EKU and elsewhere as certificates to
>
>     be used for S/MIME.  There was concern that the scope of the S/MIME BR be
>
>     clearly delineated, for example to prevent future linters from sweeping in
>
>     document signing certs.
>
>       
>
>     It was agreed that a certificate with the emailProtection EKU and containing
>
>     an email address in the Subject or SAN should be considered in scope.
>
>     Following points made by Dimitris Zacharopoulos and Wendy Brown it was
>
>     agreed that that any Issuing CA that issued any certs of that type would be
>
>     in scope. The goal of the Legacy/Multipurpose profiles is to accommodate
>
>     those "crossover certs" with the intent that those profiles ultimately would
>
>     be phased out in favor of the Strict.  Client Wilson said that the long term
>
>     goal must be to separate the S/MIME and document signing use cases as other
>
>     areas have shown the policy and agility risks of multipurpose certificates.
>
>       
>
>     Wendy Brown, Thomas Connelly, and Russ Housely discussed that there is a
>
>     cost of separating certs by use case, and that current client software UI
>
>     may present a challenge for users in identifying which certificate they are
>
>     looking at, particularly over time when managing expired certificates
>
>     required to view historic emails.
>
>       
>
>     The discussion turned to EKU.  Stephen Davidson pointed out that a review of
>
>     S/MIME certs found on the internet showed that even "strict-looking" ICA
>
>     profiles used additional EKU beyond emailProtection.  These include
>
>     clientAuth, a range of Microsoft EKU, and document signing EKU.
>
>       
>
>     Curt Spann indicated that while it may be acceptable in Legacy/Multipurpose
>
>     profiles, it would be unusual to allow in the Stricter policies.  Dimitris
>
>     pointed out that no standards existed for clientAuth and other BR allowed
>
>     its use.
>
>       
>
>     It was agreed that the Microsoft EKU and the document signing EKU would be
>
>     acceptable in Legacy/Multipurpose.  Ben Wilson asked CAs to consider their
>
>     issuance and to make the case for EKU combinations that may be required.
>
>     Curt raised that it may be that the Legacy/Multipurpose profiles could be
>
>     combined once the actual differences in the "identity" profiles are
>
>     considered.
>
>       
>
>     Stephen Davidson raised the question of the smimeCapabilities extension and
>
>     asked if other specialist extensions were commonly used in S/MIME. Stephen
>
>     noted that an additional tab called "leaf profile" has been added to the
>
>     worksheet starting to lay out the other leaf certificate fields that will be
>
>     in common across the profile types.
>
>       
>
>     6. Any Other Business
>
>       
>
>     None
>
>     7. Next call
>
>     Next call: Wednesday, June 9, 2021 at 11:00 am Eastern Time
>
>     Adjourned
>
>       
>
>     _______________________________________________
>
>     Smcwg-public mailing list
>
>     Smcwg-public at cabforum.org  <mailto:Smcwg-public at cabforum.org>
>
>     https://lists.cabforum.org/mailman/listinfo/smcwg-public  <https://lists.cabforum.org/mailman/listinfo/smcwg-public>
>
>
>
>     _______________________________________________
>
>     Smcwg-public mailing list
>
>     Smcwg-public at cabforum.org  <mailto:Smcwg-public at cabforum.org>
>
>     https://lists.cabforum.org/mailman/listinfo/smcwg-public  <https://lists.cabforum.org/mailman/listinfo/smcwg-public>
>

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