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

Ryan Sleevi sleevi at google.com
Fri Aug 18 14:33:19 UTC 2017


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

> Hi Kirk and Ryan,
>
>
>
> I think this points out a couple of important changes we should make to
> the BRs:
>
>
>
> 1) We should clarify which fields can’t have just meta data characters.
> The statement is currently ambiguous in 2 ways:
>
> 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.
>
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.
>

Wholeheartedly agree :) This is consistent with the spirit and intent, and
is an unnecessary ambiguity :)


> 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.

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.

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?

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170818/05947100/attachment-0002.html>


More information about the Public mailing list