<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 18, 2017 at 10:25 AM, Doug Beattie <span dir="ltr"><<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div class="m_5005008457185405433WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Hi Kirk and Ryan,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I think this points out a couple of important changes we should make to the BRs:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">1) We should clarify which fields can’t have just meta data characters. The statement is currently ambiguous in 2 ways:
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">1.1) It’s listed under “Other Subject Attributes” which implies it’s OK in any other field (which we know is not accurate). This applies especially to the OU
field that is listed above and then seems to be precluded from this requirement.</span> </p></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_5005008457185405433WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">1.2) It’s not just optional fields, it should be ANY field in the subject DN. Although, all required fields should have clear requirements on what they MUST contain,
it would not hurt to apply this meta data requirement to all Subject information fields.</span></p></div></div></blockquote><div><br></div><div>Wholeheartedly agree :) This is consistent with the spirit and intent, and is an unnecessary ambiguity :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_5005008457185405433WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">2) The list of meta data characters is not spelled out clearly. We say parenthetically meta data characters such as ‘.’, ‘‐‘, and ‘ ‘ (i.e. space). I think
there are 2 categories of content we need to specifically disallow:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">2.1) Fields that consist of only meta data characters are clearly not allowed. I think this is the list: ASCII 32 - 47, 58 - 64, 91 - 96, 123 – 126. This
is easy to specify and then audit against.</span></p></div></div></blockquote><div><br></div><div>I think this is a good step, but it's worth noting that these fields can also contain Unicode data (e.g. UTF8String), and as a result, has a variety of metacharacters in a variety of languages (the number of ways to represent a 'period / full-stop' in Unicode is... surprising). The danger in specifying to this extent is that we're imply that these other sets _are_ acceptable, but I don't believe that's the intent.</div><div><br></div><div>Of course, this itself is a symptom of allowing CAs arbitrary flexibility for additional attributes. It would be useful to know whether CAs have availed themselves of this flexibility, as perhaps we can cut this Gordian Knot simply by prohibiting additional fields.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_5005008457185405433WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">2.1) The harder one is to say don’t put nonsense into any fields like N/A, NA, test, “not applicable” etc. The descriptions of all the fields in BR section 7.1.4.2.2
items a-h are clear on the content. Item i) OU and j) Other subject attributes, might need to more clearly specify what is permitted and what is prohibited.</span></p></div></div></blockquote><div><br></div><div>Harder in what sense? I suspect you mean regarding programatic auditing, but I wanted to make sure I'm not confusing the issue. I think that as long as we allow CA discretion, we won't be able to solve the programatic auditing, and so our best hope is to provide the procedural guidance.</div><div><br></div><div>Or were you suggesting that, similarly to what I remarked above, we should restrict/eliminate the blanket provision, instead specify the additional fields, and their necessary content?</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_5005008457185405433WordSection1"><div><div class="h5"><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div>
</div>
</div>
</div></div></div>
</div>
</blockquote></div><br></div></div>