<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 21, 2016 at 3:07 PM, Kirk Hall <span dir="ltr"><<a href="mailto:Kirk.Hall@entrust.com" target="_blank">Kirk.Hall@entrust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_-7262974214216930133WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">That’s good news, Ryan – some have said that no OIDs are permitted in certificates except for those specified in the BRs and/or RFC 5280, etc.  I couldn’t see
 where that was specified so I thought I’d check with the browsers.  Sounds like Google has no objections to additional OIDs.</span></p></div></div></blockquote><div><br></div><div>So long as those additional OIDs do not introduce conflicting requirements, either within the validation of the fields or in the encoding of them (which was the main topic of concern during the call).</div><div><br></div><div>This is no different than the notion that the validation procedures for OV/IV/EV should be additive (build upon) the BRs, rather than replace/supplant. If, for example, the profile of an EV certificate is fully compliant with that of a DV certificate, then one can (but not necessarily should) assert both the DV and EV policy OIDs.</div><div><br></div><div>Functionally, this indicates that the certificate has been validated to the DV level, and the encoded profile is compliant with the requirements set forth in the BRs, and then *above and beyond that*, information has been validated to the EV level and the encoded profile is compliant with those set forth in the EVG.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-7262974214216930133WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">Assuming the other browsers take the same position, then in the future when a CA or a political jurisdiction wants extra markers in certificates for their own
 purposes, the Forum and the browsers won’t have to get involved.</span></p></div></div></blockquote><div><br></div><div>I'm not sure my response, or your interpretation, supports the last part of that statement.</div><div><br></div><div>1) I answered only in the context of the technical profile supported by the BRs and RFC 5280, for which they allow multiple expressions of policy OIDs. I did not, however, make any statements or claims to how client libraries handle such certificates, for which there may be a concern within the Forum to ensure maximum interoperability of certificates.</div><div>2) The additional markers are only suitable to the extent that they are additive upon the existing requirements, and do not materially change or conflict with the requirements for the Forum-policies being asserted. If they are in conflict, that is a matter for the Forum and browsers to be involved in.</div><div>3) Further, if they are in conflict, the notion of jurisdictional reforms within the BRs are extremely relevant, to ensure that CAs properly understand the distinction between MUST and MAY.</div><div><br></div><div>So no, I don't believe "the Forum and the browsers won't have to get involved" is a correct summary of the issue, but to the question of "Can multiple policy OIDs be included in a certificate" - RFC 5280 permits this, and the BRs permit this provided that no conflicts exist. In the existence of conflicts, it intrinsically requires some degree of Forum and Browser involvement.</div><div><br></div><div>To perhaps alternatively state this, since the nuance appears to not have been clear:</div><div>Imagine a CA's CPS states we use policy ID "Foo" to indicate a cert issued following the BRs' DV policy. This CA may assert the following policies:</div><div>a) 2 policies: "Foo" + 2.23.140.1.2.1</div><div>b) 1 policy: 2.23.140.1.2.1</div><div>c) 1 policy: "Foo"</div><div><br></div><div>For most CAs (such as your past and present employer), they opt for Option C - indicating the CA's specific policy, which may be the same as the BRs DV policy or may be additive upon it (e.g. "We only issue these certs to citizens of Country X, Y, Z").</div><div><br></div><div>Jody's proposed Microsoft policy changes (which may CAs objected to) would have required Option B, to some extent. Understandably, it was pointed out the technical concern with this (the reissued of intermediates), so under Microsoft's present program requirements, CAs MUST use either Option A or Option B - which it appears not many CAs have started doing (yet).</div><div><br></div><div>The requirement to use Option A, FWIW, comes from <a href="http://aka.ms/rootcert">http://aka.ms/rootcert</a> , Section 4, Sub-section A, Item 15, which requires that the CA MUST include the DV OID - but, like the BRs, makes no statement regarding other OIDs.</div><div><br></div><div>However, this only applies to the extent that "Foo" is fully compatible with 2.23.140.1.2.1. If it was not, we're back to what we were discussing on the call - how to resolve that conflict.</div></div></div></div>