<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 14/6/2021 1:57 μ.μ., Doug Beattie
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:SG2PR03MB314512BC0746B4596852A3E2F0319@SG2PR03MB3145.apcprd03.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas",serif;}span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}div.WordSection1
{page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Hi Dimitris,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I had a feeling that was the case.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Is this logic also flawed?</p>
</div>
</blockquote>
<br>
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:<br>
<ol>
<li>Rely on the KU of the end-entity certificate (usually the
digitalSignature bit) alone, no EKU extension<br>
</li>
<li>Rely on the KU AND the keyPurposeId:id-kp-emailProtection in
the EKU extension</li>
<li>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<i> </i><i>id-kp-</i><i>emailProtection
</i>keyPurposeId</li>
</ol>
<p>Option 3 is kind of described in section <a
moz-do-not-send="true"
href="https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12">4.2.1.12</a>
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.</p>
<p>Put differently, if a CA Certificate has an EKU extension which
does not include the <i>id-kp-emailProtection</i> 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.</p>
<p><br>
</p>
<p>Dimitris.<br>
</p>
<br>
<blockquote type="cite"
cite="mid:SG2PR03MB314512BC0746B4596852A3E2F0319@SG2PR03MB3145.apcprd03.prod.outlook.com">
<div class="WordSection1">
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Doug<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Dimitris Zacharopoulos
(HARICA) <a class="moz-txt-link-rfc2396E" href="mailto:dzacharo@harica.gr"><dzacharo@harica.gr></a> <br>
<b>Sent:</b> Monday, June 14, 2021 1:15 AM<br>
<b>To:</b> Doug Beattie
<a class="moz-txt-link-rfc2396E" href="mailto:doug.beattie@globalsign.com"><doug.beattie@globalsign.com></a>; SMIME Certificate
Working Group <a class="moz-txt-link-rfc2396E" href="mailto:smcwg-public@cabforum.org"><smcwg-public@cabforum.org></a>; Stephen
Davidson <a class="moz-txt-link-rfc2396E" href="mailto:Stephen.Davidson@digicert.com"><Stephen.Davidson@digicert.com></a><br>
<b>Subject:</b> Re: [Smcwg-public] SecureMail EKU in
Document signing certs<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
Hi Doug,<br>
<br>
I believe you are describing an ideal situation and I wish
things were as simple as stated :-)<br>
<br>
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.<br>
<br>
<br>
Dimitris.<br>
<br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal">On 10/6/2021 4:18 μ.μ., Doug Beattie via
Smcwg-public wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre><o:p> </o:p></pre>
<pre>I'm sorry I missed the working group meeting, but wanted to point out<o:p></o:p></pre>
<pre>something that might help us focus on the charter and how to address other<o:p></o:p></pre>
<pre>use cases for EE certificates that need to contain the Secure Mail EKU.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>It's my understanding that this WG is defining rules for secure mail<o:p></o:p></pre>
<pre>certificates and those will have a specific Cert Policy OID in them to<o:p></o:p></pre>
<pre>indicate that they comply. That will show adherence to the spec and<o:p></o:p></pre>
<pre>auditors will audit these certs against this spec. Certificates without one<o:p></o:p></pre>
<pre>of these CABF EKUs are outside the scope of this spec and WG. I don't think<o:p></o:p></pre>
<pre>(please correct me, I could be wrong) this spec precludes CAs from<o:p></o:p></pre>
<pre>continuing to issue pubic trust certificates with the secure mail EKU but<o:p></o:p></pre>
<pre>with other certificate policies, does it? Of course they won't be trusted<o:p></o:p></pre>
<pre>by email clients that have taken steps to only trust compliant certificates.<o:p></o:p></pre>
<pre>Basically I'm assuming that mail clients will look at the Root, CA, EE<o:p></o:p></pre>
<pre>certificate for proper EKU AND EE certificate certificate policy to<o:p></o:p></pre>
<pre>determine trust.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Assuming this is true, then CAs can continue issuing certificates with the<o:p></o:p></pre>
<pre>secure mail EKU in them for other purposes, such as document signing so long<o:p></o:p></pre>
<pre>as they do not include the CABF Cert Policy OIDs.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Am I making poor assumptions?<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Doug<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>-----Original Message-----<o:p></o:p></pre>
<pre>From: Smcwg-public <a href="mailto:smcwg-public-bounces@cabforum.org" moz-do-not-send="true"><smcwg-public-bounces@cabforum.org></a> On Behalf Of Stephen<o:p></o:p></pre>
<pre>Davidson via Smcwg-public<o:p></o:p></pre>
<pre>Sent: Wednesday, June 9, 2021 2:28 PM<o:p></o:p></pre>
<pre>To: SMIME Certificate Working Group <a href="mailto:smcwg-public@cabforum.org" moz-do-not-send="true"><smcwg-public@cabforum.org></a><o:p></o:p></pre>
<pre>Subject: [Smcwg-public] Approved Minutes of SMCWG May 26, 2021<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Minutes of SMCWG<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>May 26, 2021<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>These are the Minutes of the Teleconference described in the subject of this<o:p></o:p></pre>
<pre>message. Corrections and clarifications where needed are encouraged by<o:p></o:p></pre>
<pre>reply.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Attendees <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Adrian Mueller (SwissSign), Ali Gholami (Telia Company), Andrea Holland<o:p></o:p></pre>
<pre>(SecureTrust), Andreas Henschel (D-TRUST), Atsushi Inaba (GlobalSign), Ben<o:p></o:p></pre>
<pre>Wilson (Mozilla), Bruce Morton (Entrust), Chris Kemmerer (SSL.com), Clint<o:p></o:p></pre>
<pre>Wilson (Apple), Corey Bonnell (DigiCert), Curt Spann (Apple), Dimitris<o:p></o:p></pre>
<pre>Zacharopoulos (HARICA), Don Sheehy (WebTrust), Hazhar Ismail (MSC<o:p></o:p></pre>
<pre>Trustgate.com), Hongquan Yin (Microsoft), Inigo Barreira (Sectigo), Klauss<o:p></o:p></pre>
<pre>Voss (Zertificon), Mads Henriksveen (BuyPass), Mauricio Fernandez<o:p></o:p></pre>
<pre>(TeleTrust), Morad Abou Nasser (TeleTrust), Niko Carpenter (SecureTrust),<o:p></o:p></pre>
<pre>Pedro Fuentes (OISTE), Rebecca Kelley (Apple), Renne Rodriguez (Apple), Russ<o:p></o:p></pre>
<pre>Housley (Vigil Security), Sebastian Schulz (GlobalSign), Stefan Selbitschka<o:p></o:p></pre>
<pre>(rundQuadrat), Stephen Davidson (DigiCert), Tadahiko Ito (SECOM Trust<o:p></o:p></pre>
<pre>Systems), Thomas Zermeno (SSL.com), Tim Crawford (WebTrust), Wendy Brown<o:p></o:p></pre>
<pre>(Federal PKI)<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>1. Roll Call<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>The Roll Call was taken.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>2. Read Antitrust Statement<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>The Antitrust/Compliance Statement was read.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>3. Review Agenda<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>4. Approval of minutes from last teleconference<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>The minutes of the May 12 teleconference were approved. <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>5. Discussion of certificate profile<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>The discussion regarding the Mailbox-validation Legacy profile continued. <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Discussion took place between regarding the overlap between certificates<o:p></o:p></pre>
<pre>intended for S/MIME and those intended for document signing, both of which<o:p></o:p></pre>
<pre>may use the emailProtection EKU. The document signing certs may not have an<o:p></o:p></pre>
<pre>email address or the digitalSignature keyUsage.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>In our effort to improve the S/MIME ecosystem we must be mindful of the<o:p></o:p></pre>
<pre>SMCWG Charter proscription of breaking other use cases. <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>There was a reminder of the IETF Internet-draft to create a generic EKU for<o:p></o:p></pre>
<pre>document signing, which would assist in separating the S/MIME and document<o:p></o:p></pre>
<pre>signing use cases.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>The SMCWG Charter defines both that our deliverable address certs that<o:p></o:p></pre>
<pre>contain the contain the emailProtection EKU and elsewhere as certificates to<o:p></o:p></pre>
<pre>be used for S/MIME. There was concern that the scope of the S/MIME BR be<o:p></o:p></pre>
<pre>clearly delineated, for example to prevent future linters from sweeping in<o:p></o:p></pre>
<pre>document signing certs.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>It was agreed that a certificate with the emailProtection EKU and containing<o:p></o:p></pre>
<pre>an email address in the Subject or SAN should be considered in scope.<o:p></o:p></pre>
<pre>Following points made by Dimitris Zacharopoulos and Wendy Brown it was<o:p></o:p></pre>
<pre>agreed that that any Issuing CA that issued any certs of that type would be<o:p></o:p></pre>
<pre>in scope. The goal of the Legacy/Multipurpose profiles is to accommodate<o:p></o:p></pre>
<pre>those "crossover certs" with the intent that those profiles ultimately would<o:p></o:p></pre>
<pre>be phased out in favor of the Strict. Client Wilson said that the long term<o:p></o:p></pre>
<pre>goal must be to separate the S/MIME and document signing use cases as other<o:p></o:p></pre>
<pre>areas have shown the policy and agility risks of multipurpose certificates.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Wendy Brown, Thomas Connelly, and Russ Housely discussed that there is a<o:p></o:p></pre>
<pre>cost of separating certs by use case, and that current client software UI<o:p></o:p></pre>
<pre>may present a challenge for users in identifying which certificate they are<o:p></o:p></pre>
<pre>looking at, particularly over time when managing expired certificates<o:p></o:p></pre>
<pre>required to view historic emails.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>The discussion turned to EKU. Stephen Davidson pointed out that a review of<o:p></o:p></pre>
<pre>S/MIME certs found on the internet showed that even "strict-looking" ICA<o:p></o:p></pre>
<pre>profiles used additional EKU beyond emailProtection. These include<o:p></o:p></pre>
<pre>clientAuth, a range of Microsoft EKU, and document signing EKU.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Curt Spann indicated that while it may be acceptable in Legacy/Multipurpose<o:p></o:p></pre>
<pre>profiles, it would be unusual to allow in the Stricter policies. Dimitris<o:p></o:p></pre>
<pre>pointed out that no standards existed for clientAuth and other BR allowed<o:p></o:p></pre>
<pre>its use.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>It was agreed that the Microsoft EKU and the document signing EKU would be<o:p></o:p></pre>
<pre>acceptable in Legacy/Multipurpose. Ben Wilson asked CAs to consider their<o:p></o:p></pre>
<pre>issuance and to make the case for EKU combinations that may be required.<o:p></o:p></pre>
<pre>Curt raised that it may be that the Legacy/Multipurpose profiles could be<o:p></o:p></pre>
<pre>combined once the actual differences in the "identity" profiles are<o:p></o:p></pre>
<pre>considered.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Stephen Davidson raised the question of the smimeCapabilities extension and<o:p></o:p></pre>
<pre>asked if other specialist extensions were commonly used in S/MIME. Stephen<o:p></o:p></pre>
<pre>noted that an additional tab called "leaf profile" has been added to the<o:p></o:p></pre>
<pre>worksheet starting to lay out the other leaf certificate fields that will be<o:p></o:p></pre>
<pre>in common across the profile types.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre> <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>6. Any Other Business<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre> <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>None<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>7. Next call<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Next call: Wednesday, June 9, 2021 at 11:00 am Eastern Time <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre>Adjourned<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<pre> <o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Smcwg-public mailing list<o:p></o:p></pre>
<pre><a href="mailto:Smcwg-public@cabforum.org" moz-do-not-send="true">Smcwg-public@cabforum.org</a><o:p></o:p></pre>
<pre><a href="https://lists.cabforum.org/mailman/listinfo/smcwg-public" moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a><o:p></o:p></pre>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Smcwg-public mailing list<o:p></o:p></pre>
<pre><a href="mailto:Smcwg-public@cabforum.org" moz-do-not-send="true">Smcwg-public@cabforum.org</a><o:p></o:p></pre>
<pre><a href="https://lists.cabforum.org/mailman/listinfo/smcwg-public" moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<br>
</body>
</html>