<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@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:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri","sans-serif";}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
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]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Another possibility is to redefine the meaning of the BRs hen moving to the 3647 format.  This format lends itself nicely to requiring general provisions of the BRs for all publicly trusted certificates while limiting the certificate validation and content requirements only to SSL certs.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Ryan Sleevi [mailto:sleevi@google.com] <br><b>Sent:</b> Friday, December 20, 2013 1:24 PM<br><b>To:</b> Ryan Hurst<br><b>Cc:</b> Jeremy Rowley; CABFPub<br><b>Subject:</b> Re: [cabfpub] Definition of an SSL certificate<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Ryan,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I absolutely agree, and this was more or less the conclusion we reached several months ago.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>As I mentioned on our most recent telecon, the BRs SHOULD cover any and all certificates that are technically capable of being used as SSL/TLS certificates. Our examination of what that meant to different root stores / browsers (which, as I understand, has been summarized on the members-only wiki) basically showed that today, this is a very liberal set.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The other big concern is that the BRs do not just cover end-entity certificates, but also set forth policies for intermediate certificates as well. By measuring "BR-applicable" by simply examining the leaf certificate, we create a hole that may be exploited for security-sensitive purposes, intentionally or not. It's not merely sufficient to determine whether a leaf certificate is BR applicable, but also to examine whether an intermediate certificate is BR-applicable.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>This is why I advocate that only Roots whose entire hierarchy is conformant and audited to the BRs - that is, every leaf and every intermediate issued from that Root - should be entered into Root Programs. CAs can still have roots that cross-sign these "BR-only Roots", but it would seem best/unambiguous for all parties to declare the entire hierarchy from a given root (potentially cross-signed) and below as being in-scope of the BRs.<o:p></o:p></p><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><p class=MsoNormal>On Fri, Dec 20, 2013 at 12:17 PM, Ryan Hurst <<a href="mailto:ryan.hurst@globalsign.com" target="_blank">ryan.hurst@globalsign.com</a>> wrote:<o:p></o:p></p><div><p class=MsoNormal>Jeremy,<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The proposal seems to be to re-write the definition to represent the intent of the issuer (I only expected this to ever be used in this way) vs what the technical capability of the certificate that they have issued.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>In my opinion the problem with this approach is that whats material is not what the intent of the action was but what the result of it is. Basically any certificate that is technically capable of being used as a publicly trusted SSL certificate IS a publicly trusted SSL certificate even if that was not the intent.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>If the group decides to go this way I think that browsers should change what they require of SSL certificates so that only those that match this intent can be technically used.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>This of course is quite difficult since the group has refused to mandate certificate policies map to the common CABF OIDs for the corresponding policies but  not addressing this seems to expose the internet to risk.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thoughts?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Ryan<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div></div><div><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><div><div><div><p class=MsoNormal>On Thu, Dec 19, 2013 at 8:05 AM, Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>> wrote:<o:p></o:p></p></div></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>We are looking to clarify the scope of the BRs.  Right now the BR scope is very loose and subjective: “This version of the Requirements only addresses Certificates intended to be used for authenticating servers  accessible through the Internet.”<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>This loose definition excludes internal names (which are not typically accessible through the Internet), a type of certificate the BRs are clearly designed to regulate (see 11.1.4).  In addition, a CA could easily issue a certificate outside of the BRs  that could later be used in a TLS/SSL attack simply because the certificate wasn’t intended to be used for SSL.  <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Issuance of certificates outside the BRs may not be intentional, especially by CAs who aren’t regularly issuing SSL certificates.  These CAs may not be aware that the BRs apply to their certificates and may not realize their client certificates could be used for SSL since “authenticating servers” is not a well-defined term.  <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Clarifying the scope will ensure that every CA is aware of the minimum standards and what they cover.  Originally, the idea was to tie the scope to the values in the EKU.  Unfortunately, there are several obstacles to this approach:<o:p></o:p></p><p>1)<span style='font-size:7.0pt'>      </span>Grid Certificates require serverAuth in the EKU.  It’s unclear whether these certs should be covered.<o:p></o:p></p><p>2)<span style='font-size:7.0pt'>      </span>Per 5280, browsers treat the absence of an EKU and the anyEKU as serverAuth, meaning they are enabled for TLS Server Authentication.<o:p></o:p></p><p>3)<span style='font-size:7.0pt'>      </span>The FBCA requires anyEKU in several certificates.  These are clearly client certificates and are outside the BR scope.<o:p></o:p></p><p>4)<span style='font-size:7.0pt'>      </span>Qualified certificates in the EU have either the anyEKU present or omit the EKU.  They are client certs and clearly not covered by the BRs.  However, they can be used  for server authentication.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>For qualified certificates, Moudrick provided the following guidance:<o:p></o:p></p><p>“Certificates using applications MAY require that the extended key usage extension be present and that a particular purpose be indicated in order for the certificate to be acceptable to that application.<o:p></o:p></p><p> <o:p></o:p></p><p>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***.<o:p></o:p></p><p> <o:p></o:p></p><p>So a QC pretending to be RFC 5280/BR and ETSI (web server QCs) compliant would have to at least have:<o:p></o:p></p><p> <o:p></o:p></p><p>QC + [anyEKU] + id-kp-serverAuth + {DV/OV/EV}<o:p></o:p></p><p> <o:p></o:p></p><p>I'm quite confident that the absolute majority of QCs issued so far (that have anyEKU, see Mark Janssen's 08/08/2013 - thank you Stephen) do not contain any DV/OV/EV policy IDs, so why not accept them as BR compliant but not sufficient for TSL/SSL establishment?<o:p></o:p></p><p> <o:p></o:p></p><p>In order for a QC to have a TSL/SSL capability, BR may require:<o:p></o:p></p><p> <o:p></o:p></p><p>QC + {{id-kp-serverAuth and/or id-kp-clientAuth} + {DV/OV/EV}} (optionally no anyKEY allowed).<o:p></o:p></p><p> <o:p></o:p></p><p>A practical interpretation: a WEB server that also does some web site related document/content signing.”<o:p></o:p></p><p> <o:p></o:p></p><p>There appears to be a significant conflict between the CAB Forum’s work and the standards set by other bodies.  In particular, their use of the anyEKU or omission of an EKU is permitting the realm of client certs to overlap SSL certs.  Approaching each government body to stop this practice is not feasible and will take a very long time to complete<o:p></o:p></p><p> <o:p></o:p></p><p>Hopefully this summary helps inspire ideas on where we can go from here.  I’m looking forward to ideas. <o:p></o:p></p><p> <o:p></o:p></p><p>Thanks!<o:p></o:p></p><p><span style='color:#888888'> <o:p></o:p></span></p><p><span style='color:#888888'>Jeremy<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#888888'> <o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='color:#888888'> <o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal style='margin-bottom:12.0pt'>_______________________________________________<br>Public mailing list<br><a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br><a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></p></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal style='margin-bottom:12.0pt'><br>_______________________________________________<br>Public mailing list<br><a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br><a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></div></body></html>