[cabfpub] Question on BR BR 7.1.4.2.2(j) - Other Subject Attributes

[Ryan Sleevi]

On Fri, Aug 18, 2017 at 11:14 AM, Doug Beattie <doug.beattie at globalsign.com>
wrote:

>
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Friday, August 18, 2017 10:33 AM
> *To:* Doug Beattie <doug.beattie at globalsign.com>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>; Kirk
> Hall <Kirk.Hall at 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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170818/44325d64/attachment-0001.html>