<div dir="ltr"><div class="gmail_extra"><br class=""><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><div class="h5"><div>On 7/4/2016 10:55 πμ, Ryan Sleevi wrote:<br></div><blockquote type="cite"><p dir="ltr"><br>On Apr 7, 2016 12:45 AM, "Dimitris Zacharopoulos" <<a href="mailto:jimmy@it.auth.gr" target="_blank"></a><a href="mailto:jimmy@it.auth.gr" target="_blank">jimmy@it.auth.gr</a>> wrote:<br>><br>> On 7/4/2016 10:30 πμ, Ryan Sleevi wrote:<br>>><br>>> Dimitris,<br>>><br>>> Your changes are actually quite opposite of what I was suggesting, and is even more problematic to support.<br>>><br>>> I think the best step would be to simply drop that item from this ballot, and then I can work with Peter to see if we can propose a suitable text that provides the same degree of clarification, while addresses the concerns I raised.<br>>><br>>> To be explicit: I do not want to see 7.1.4.2 deleted.<br>><br>><br>> Hello Ryan,<br>><br>> You mentioned:<br>><br>><br>> "<br>> - Let's work up a ballot that:<br>>   - Moves the remarks about "required/optional" for subject names (which is only relevant to subscriber certificates) into a new 7.1.2.3 (g) [thus mirroring 7.1.2.1 [e] and 7.1.2.2 [h])<br>>   - Moves the remarks about "required/optional" for subjectAltNames to a new 7.1.2.3 [h]<br>> "<br>><br>> I don't think I did the opposite. Perhaps I did not follow your entire line of thought. Anyway, at least I discovered some incorrect references which should be resolved a soon as possible.<br>></p><p dir="ltr">You moved the entire section, rather than the required/optional, which introduced the very loophole I was concerned about introducing - namely, that it limits the validation procedures for optional nametypes to subscriber certificates.</p><p dir="ltr">The overarching goal is to separate out validation procedures for obtaining information (aka the 3.2.2 sections), how that information is to be used / when that information needs to be used (aka 7.1.4.2), and when such information is required to appear in an actual certificate (the profiles of <a href="http://7.1.2.1/.2/.3" target="_blank">7.1.2.1/.2/.3</a>)</p><p dir="ltr">Alternatively stated a third way, the goal being that 7.1.2.[1-3] covers the profile, but just makes reference to the name types and whether they're required or optional •but says nothing about what information must appear in that type•, 7.1.4.2 covers what is acceptable to appear in that name type, and applies to ANY certificate that contains that name type, as well as what vetting sections to use, and 3.2.2.* covers the actual procedures to use to vet that information.</p></blockquote><br></div></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. 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><br>Of course I leave it to you to steer these changes.<br><br><br>Best regards,<br>Dimitris.<br><br></div></blockquote></div></div></div>