<p dir="ltr">They're still respected (for better or worse) by Apple, NSS, and Android.</p>
<p dir="ltr">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 class="gmail_quote">On Jul 29, 2013 1:52 PM, "Kelvin Yiu" <<a href="mailto:kelviny@exchange.microsoft.com">kelviny@exchange.microsoft.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
<br>
<br>
<br>
</blockquote></div>