<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style>
<!--
@font-face
{font-family:"Cambria Math"}
@font-face
{font-family:Calibri}
@font-face
{font-family:Tahoma}
@font-face
{font-family:Verdana}
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif"}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline}
p
{margin-right:0cm;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif"}
pre
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Courier New"}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif"}
span.HTML-voorafopgemaaktChar
{font-family:"Courier New"}
span.BallontekstChar
{font-family:"Tahoma","sans-serif"}
span.E-mailStijl22
{font-family:"Verdana","sans-serif";
color:#1F497D}
span.E-mailStijl23
{font-family:"Verdana","sans-serif";
color:#1F497D}
span.E-mailStijl24
{font-family:"Verdana","sans-serif";
color:#1F497D}
.MsoChpDefault
{font-size:10.0pt}
@page WordSection1
{margin:70.85pt 70.85pt 70.85pt 70.85pt}
div.WordSection1
{}
-->
</style>
</head>
<body lang="NL" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-GB" style="font-size:10.0pt; font-family:"Verdana","sans-serif"; color:black">Although I understand the need for tightening the definition and I can follow the reasoning below to a certain point I feel that, instead of tightening
it, the new definition seems to have broadened the scope. The vast majority of certificates issued under the Logius PKIoverheid root are not intended for the identification of SSL servers. However, roughly 90% of these certificates will now fall under this
new definition. In the present version, the scope made clear that the BR only addressed certificates meant for servers.</span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:10.0pt; font-family:"Verdana","sans-serif"; color:black"> </span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:10.0pt; font-family:"Verdana","sans-serif"; color:black">What about personal certificates on a SSCD that have no EKU or have an anyExtendedKeyUsage as a safetynet? Would these certificates suddenly by
seen as SSL certificates although they are obviously not intended for servers? What about certificates issued to autonomous devices such as onboard computers in taxicabs or domestic gas meters, to name but two? Would these be considered SSL certificates if
they have no EKU or the clientauth EKU in combination with anyExtendedKeyUsage? </span>
</p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:10.0pt; font-family:"Verdana","sans-serif"; color:black"> </span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt; font-family:"Verdana","sans-serif"; color:black">Regards,
</span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:black">Robert</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN" style="font-size:10.0pt; font-family:"Verdana","sans-serif"; color:#1F497D"> </span></p>
<p class="MsoNormal"><span lang="EN" style="font-size:10.0pt; font-family:"Verdana","sans-serif"; color:#1F497D"> </span></p>
<div style="border:none; border-top:solid #B5C4DF 1.0pt; padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:10.0pt; font-family:"Tahoma","sans-serif"">Van:</span></b><span lang="EN-US" style="font-size:10.0pt; font-family:"Tahoma","sans-serif"">
<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [<a href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>]
<b>Namens </b>Ryan Sleevi<br>
<b>Verzonden:</b> maandag 29 juli 2013 22:</span><span style="font-size:10.0pt; font-family:"Tahoma","sans-serif"">57<br>
<b>Aan:</b> Kelvin Yiu<br>
<b>CC:</b> CABFPub<br>
<b>Onderwerp:</b> Re: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements</span></p>
</div>
<p class="MsoNormal"> </p>
<p>They're still respected (for better or worse) by Apple, NSS, and Android.</p>
<p>Even if that changed tomorrow, the fact that a significant portion of the deployed user base for those products may not upgrade immediately suggests it would be wise to keep them in scope - especially given that even few products implement Microsoft's EKU
chaining behaviour for intermediates.</p>
<div>
<p class="MsoNormal">On Jul 29, 2013 1:52 PM, "Kelvin Yiu" <<a href="mailto:kelviny@exchange.microsoft.com">kelviny@exchange.microsoft.com</a>> wrote:</p>
<p class="MsoNormal" style="margin-bottom:12.0pt">I prefer to drop any mention of the MS or Netscape SGC OIDs. These OIDs have been obsolete for over a decade and have ceased to have any meaning on MS platforms since Windows 2000.<br>
<br>
Kelvin<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a>] On Behalf Of Ryan Sleevi<br>
Sent: Friday, July 26, 2013 12:35 PM<br>
To: jeremy rowley<br>
Cc: CABFPub<br>
Subject: Re: [cabfpub] Ballot 108: Clarifying the scope of the baseline requirements<br>
<br>
Jeremy,<br>
<br>
If I might suggest a slight modification to the wording, which still leaves things a little ambiguous. "All root and intermediate certificates included in a browser's trust store" - AIUI, none of the browsers are really accepting intermediates to the trust
store at this point.<br>
<br>
This was a sticky point when working on Mozilla's wording on this policy to. Luckily, the terminology for "Root CA" and "Subordinate CA"<br>
may be sufficient here to help clarify.<br>
<br>
"All root certificates included in a browser's trust store, all subordinate CA certificates signed by one of these root certificates, and all end-entity certificates that either lack any Extended Key Usage extension or contain an Extended Key Usage extension
that contains one of the following:<br>
- Server Authentication (1.3.6.1.5.5.7.3.1)<br>
- anyExtendedKeyUsage (2.5.29.37.0)<br>
- Netscape Server Gated Cryptography (2.16.840.1.113730.4.1)<br>
- Microsoft Server Gated Cryptography (1.3.6.1.4.1.311.10.3.3) are expressly covered by these requirements."<br>
<br>
Note that Appendix B, 3.F lists other values as SHOULD NOT. However, that presumably only applies when a certificate is 'in scope' of the BRs, hence the restatement of potential EKUs that are relevant.<br>
<br>
<br>
<br>
On Fri, Jul 26, 2013 at 12:22 PM, Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>> wrote:<br>
> Hi everyone,<br>
><br>
><br>
><br>
> As mentioned on the phone call last week, CAs have claimed exemption<br>
> from the BRs because the definition of a publicly-trusted SSL certificate is not<br>
> clear. I would like to clarify the scope of the BRs to avoid confusion on<br>
> what particular certificate contents are necessary to require<br>
> compliance. I am looking for on endorser (Stephen Davidson has already endorsed).<br>
><br>
><br>
><br>
> The third paragraph of Section 1 of the baseline requirements is:<br>
><br>
> "This version of the Requirements only addresses Certificates intended<br>
> to be used for authenticating servers accessible through the<br>
> Internet. Similar requirements for code signing, S/MIME,<br>
> time-stamping, VoIP, IM, Web services, etc. may be covered in future versions."<br>
><br>
><br>
><br>
> I'd like to replace the above text with the following:<br>
><br>
> "This version of the Baseline Requirements addresses all root,<br>
> intermediate, and end entity certificates that can be used in<br>
> publicly-trusted SSL handshakes. All root and intermediate<br>
> certificates included in a browser's trust store and all end entity<br>
> certificates containing an extended key usage extension of Server<br>
> Authentication (1.3.6.1.5.5.7.3.1) are expressly covered by these<br>
> requirements. Similar requirements for code signing, S/MIME,<br>
> time-stamping, VoIP, IM, Web services, etc. may be covered in future versions."<br>
><br>
><br>
><br>
> I look forward to your comments.<br>
><br>
><br>
><br>
> Jeremy<br>
><br>
><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><br>
><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><br>
<br>
</p>
</div>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1"><br>
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid
voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten.<br>
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind
resulting from the risks inherent in the electronic transmission of messages. .<br>
</font>
</body>
</html>