<div dir="ltr"><div class="gmail_extra"><br class=""><br><div class="gmail_quote">On Thu, Apr 7, 2016 at 1:24 AM, Ryan Sleevi <span dir="ltr"><<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.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 dir="ltr">Drat, and I just realized you dropped the CA/B forum list midway in this thread.<div><br></div><div>Would you object to me reposting each of these messages?</div></div><div class=""><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 7, 2016 at 1:23 AM, Ryan Sleevi <span dir="ltr"><<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.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 dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 7, 2016 at 1:08 AM, Dimitris Zacharopoulos <span dir="ltr"><<a href="mailto:jimmy@it.auth.gr" target="_blank">jimmy@it.auth.gr</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 bgcolor="#FFFFFF" text="#000000"><div><br></div>I see. I was probably confused because the profiles of 7.1.2.1 and 7.1.2.2 already include the subject extension, what information should be included in specific fields (countryName, organizationName) and also mention how this information is verified with references to 3.2.2.* at least in this cleanup proposal.</div></blockquote><div><br></div><div>Correct, and it's that asymmetry that I think is (also) mistaken and needs to be cleaned up.</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 bgcolor="#FFFFFF" text="#000000">I must admit from a CA perspective that having all information in one section (profile options, which option is optional/required and validation references for each option) makes things very clear. The more references we have, the worse it gets.<br></div></blockquote><div><br></div><div>The arguable benefit here is that the proposed split (also covers/can covers) cases where, say, there's a distinguishedName in a [subject/issuer]alternative name.</div><div><br></div><div>At fundamental question is whether a field like "countryName" should always be validated consistently between certificate types (... yes?), and whether it should be permissible for, say, a technically constrained subCA certificate (which is arguably a 'subordinate CA' certificate) can also contain, say, no SAN and a CN for "<a href="http://www.google.com/" target="_blank">www.google.com</a>". Under Peter's/your proposal, that would appear to be a valid action, and that's why I think it's buggy.</div><div><br></div><div>The alternative, coupling it all into a table (DN name type, validation method, required for root, required for subCA, required for end-entity) means that you've got even more information with a growing number of permutations, which can't scale well to accommodate additional certificate types, and can't scale well to handle the general appearance of name forms in other contexts.</div><div><br></div><div>That's why I suggested the split I did</div><div>- Validation procedures collect multiple pieces of information, and may include things like a QGIS (which could return DBA name, jurisdiction of incorporation, serial number, etc)</div><div>- Certificate profiles, which will necessarily vary between the types of certificates (for example, consider the myriad ETSI profiles here)</div><div>  - This also aligns with the push by Microsoft to split DV/OV/IV/EV profiles into their respective policy OIDs, which also necessitates varying profiles as to which fields (like jurisdictionOfEncorporation) are mandatory, and under which profiles</div><div>- Name forms, which will hopefully be universal - for example,  you don't want organizationName to be arbitrary data for a sub-CA certificate, but the legal entity name for an OV certificate; because now it means all relying parties now have to know under which context and profile to interpret information</div><div><br></div><div>Anyways, this is largely why I suggested a separate ballot - the changes are bigger in scope, there's subtleties to discuss, and, as you noted, cross-references to validate.</div><div><br></div><div>To save Peter a roundtrip - if the ballot from <a href="https://cabforum.org/pipermail/public/2016-April/007170.html" target="_blank">https://cabforum.org/pipermail/public/2016-April/007170.html</a> was amended once more to remove the following statement "Append " - Subscriber Certificates" to the the title of section 7.1.4.2." - would you be willing to endorse that ballot?<br></div></div></div></div></blockquote></div><br></div></div></div></blockquote></div></div></div>