<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 2, 2014 at 10:33 AM, Dean Coclin <span dir="ltr"><<a href="mailto:Dean_Coclin@symantec.com" target="_blank">Dean_Coclin@symantec.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal">Further to today’s discussion on our call, I’d like to get more feedback on a proposal to make a unique standardized OID mandatory for DV and OV certificates in the Baseline Requirements. Currently we have a mandatory OID for EV certificates but optional for OV and DV.  This makes things difficult for at least two groups of constituents:<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p><u></u><span>1.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">       </span></span><u></u>Relying parties that would like to distinguish between these certificates</p></div></div></blockquote><div>You've heard repeatedly from several browsers about an explicit non-goal of distinguishing DV and OV. As the Forum is comprised of CAs and Browsers, do we have have any Browsers that wish to make such a distinction?</div><div><br></div><div>If not, it would be wholly inappropriate for the Forum to require it. If there are non-browser relying parties interested in such distinctions, the CA can always provide such distinctions themselves.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p><u></u><u></u></p><p><u></u><span>2.<span style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">       </span></span><u></u>Analysts that report on SSL certificate data who have had to issue revised reports because of cert misclassification</p></div></div></blockquote><div>As mentioned on the call, this has been discussed with Mozilla in the past - <a href="https://groups.google.com/d/msg/mozilla.dev.security.policy/-mCAK5zfhFQ/hEOQK-ubGRcJ">https://groups.google.com/d/msg/mozilla.dev.security.policy/-mCAK5zfhFQ/hEOQK-ubGRcJ</a></div><div><br></div><div>As someone very keen on programatic checks and detection for misissuance, there's no question that this would NOT meaningfully help address the concerns we see.</div><div><br></div><div>That is, there would need to be an OID _per revision_ of the BRs, to indicate "which" version of the BRs something was complying to. </div><div><br></div><div>I would hope that <a href="https://groups.google.com/d/msg/mozilla.dev.security.policy/-mCAK5zfhFQ/2tRUS444krwJ">https://groups.google.com/d/msg/mozilla.dev.security.policy/-mCAK5zfhFQ/2tRUS444krwJ</a> would capture some of these concerns more fully.</div><div><br></div><div>Finally, to do anything meaningful with this in all major clients, it would require that CAs redo their certificate hierarchy, as policy OIDs are inherited. That's a silly thing, especially when CAs are still struggling to migrate from SHA-1 to SHA-256 in their intermediates.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">My proposal is for CAs to put in OID X if it’s a DV certificate and OID Y if it’s an OV certificate.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">As Rick reminded me on the call, we currently have something like this for EV certificates (except that CAs are free to use the standard OID or define one of their own).<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I’d like to hear pros/cons of this. Ryan S indicated that Google would not support such a proposal but we didn’t have time to discuss the reasons.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I’m sure there are both technical and policy reasons. Personally I’d like to focus on the latter but remarks on both are welcome. This proposal doesn’t require anyone to do anything with this data (i.e relying parties can choose whether or not to utilize it).<u></u><u></u></p><p class="MsoNormal"><br>Thanks,<br>Dean<u></u><u></u></p><p><u></u> <u></u></p><p style="margin-left:0in"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p></div></div><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">https://cabforum.org/mailman/listinfo/public</a><br>
<br></blockquote></div><br></div></div>