[Smcwg-public] SecureMail EKU in Document signing certs

Mon Jun 14 10:57:24 UTC 2021

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?

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  <mailto:smcwg-public-bounces at cabforum.org> <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  <mailto:smcwg-public at cabforum.org> <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

_______________________________________________
Smcwg-public mailing list
Smcwg-public at cabforum.org <mailto:Smcwg-public at cabforum.org> 
https://lists.cabforum.org/mailman/listinfo/smcwg-public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20210614/a4e73fdd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 8424 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20210614/a4e73fdd/attachment-0001.p7s>