<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 18, 2017 at 11:14 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_-7106460591739596729WordSection1">
<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"><a name="m_-7106460591739596729__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:30.5pt"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Ryan Sleevi [mailto:<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>]
<br>
<b>Sent:</b> Friday, August 18, 2017 10:33 AM<br>
<b>To:</b> Doug Beattie <<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>><br>
<b>Cc:</b> CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>>; Kirk Hall <<a href="mailto:Kirk.Hall@entrustdatacard.com" target="_blank">Kirk.Hall@entrustdatacard.com</a><wbr>><span class=""><br>
<b>Subject:</b> Re: [cabfpub] Question on BR BR 7.1.4.2.2(j) - Other Subject Attributes<u></u><u></u></span></span></p>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="margin-left:30.5pt">
<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:</span><u></u><u></u></p><span class="">
<p class="MsoNormal" style="margin-left:30.5pt">
<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><u></u><u></u></p>
</span></div>
</div>
</blockquote><span class="">
<div>
<p class="MsoNormal" style="margin-left:30.5pt"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:30.5pt">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.<u></u><u></u></p>
</div>
</span><div>
<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="color:#1f497d">Sure, so we could frame this for this specified character set as a better example of the fields maybe?</span></p></div></div></div></div></div></div></div></blockquote><div><br></div><div>Unfortunately, just allowing specific character sets is either unnecessarily restrictive (e.g. there should be no reason to limit the languages here present, provided that the CA has appropriately verified) or increasingly complex (e.g. needing to consider metacharacters in each language).</div><div><br></div><div>I'm sure, if we wanted an absolute technical profile, we could go through that exercise, since the Unicode tables do have associated data about the context of the character (for some categories), but I suspect that, much like NetSec requirements, it would be onerous to maintain and evolve, as Unicode itself continues to evolve.</div><div><br></div><div>I realize this is, shockingly, one of the few times I'm advocating against a programmatic solution, which is no doubt surprising. Yet this specific issue (metacharacters) is within the bounds that I think risk-limiting approaches would be viable and appropriate, and we can use that opportunity to figure out what 'less than overspecifying' solutions we can do. For example, does the issuing CA have a process in place where it reviews such fields of issued certificates on a regular basis? Does it have a blacklist of phrases or characters its employees have issued (historically) to help guide? I'm sure we could evolve a process short of programmatic checks that appropriately balances the intent and purpose with the risk :)</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_-7106460591739596729WordSection1"><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div><div><div><div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Yes, harder to programmatically audit/check.  Guidance is pretty good for most fields, but the OU field description remains a bit open, perhaps by design.</span></p></div></div></div></div></div></div></div></blockquote><div><br></div><div>Right, very much by design. I think this similarly goes with other restrictions on the OU, such as the use of brandnames or other information. Whether or not an OU is misleading, or the brand has been authorized, is admittedly someone of a judgement call. Should a certificate be issued where someone disagrees with the conclusion of the CA, then I think ultimately, what the community is wanting to understand what processes the CA had in place, were they followed, and what opportunities exist for improvement.</div><div><br></div><div>Alternatively, it may be that we want to limit the attributes in certificates to only those that can be consistently and programatically verified. In such a case, this would mean deprecating the OU field (as no such registries exist, and it's subscriber-reported), and ensuring that other attributes are consistently used (much like the serialNumber attribute of an EV certificate, or the C attribute of others - a consistent and well-defined form)</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_-7106460591739596729WordSection1"><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div><div><div><div><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"><u></u> <u></u></span></p>
</div><span class="">
<div>
<p class="MsoNormal" style="margin-left:30.5pt">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?<u></u><u></u></p>
</div>
</span></div>
<p class="MsoNormal"><span style="color:#1f497d">If CAs are not using any other Subject fields, then we should probably disallow them.  Someone with better programming skills could certainly parse the CT logs looking for additional subject fields – if there
 are only a few, then why not include them and preclude all others?</span></p></div></div></div></div></div></blockquote><div><br></div><div>Now that we have CT, I wholly support this :) It was not viable in 2009 or 2012, but certainly is now :) </div></div><br></div></div>