On Fri, Aug 18, 2017 at 11:14 AM, Doug Beattie <doug.beat...@globalsign.com> wrote:
> > > > > *From:* Ryan Sleevi [mailto:sle...@google.com] > *Sent:* Friday, August 18, 2017 10:33 AM > *To:* Doug Beattie <doug.beat...@globalsign.com> > *Cc:* CA/Browser Forum Public Discussion List <public@cabforum.org>; Kirk > Hall <kirk.h...@entrustdatacard.com> > *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? > 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). 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. 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 :) > 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. > 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. 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) > > > 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? > Now that we have CT, I wholly support this :) It was not viable in 2009 or 2012, but certainly is now :)
_______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public