From: Ryan Sleevi [mailto:[email protected]] Sent: Friday, August 18, 2017 10:33 AM To: Doug Beattie <[email protected]> Cc: CA/Browser Forum Public Discussion List <[email protected]>; Kirk Hall <[email protected]> Subject: Re: [cabfpub] Question on BR BR 7.1.4.2.2(j) - Other Subject Attributes
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: 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. 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. Sure, so we could frame this for this specified character set as a better example of the fields maybe? 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. 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. 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. 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. 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? 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?
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
