[cabfpub] Draft Ballot - Subject Common and Alternative Names

[Ryan Sleevi]

On Fri, Apr 8, 2016 at 4:15 PM, Peter Bowen <pzb at amzn.com> wrote:

> If a name constrained CA has a dNSName constraint but does not have a
> constraint for SRVNames, the CA MUST NOT issue certificates containing
> SRVNames where the Name portion is in an excluded dNSName subtree.  Such a
> CA also MUST NOT issue certificates containing SRVNames where the Name
> portion is not in a permitted dNSName subtree if at least one permitted
> dNSName subtree exists."
>

I believe you're missing an update to Section 7.1.5. Any introduction of
additional subjectAltName types should also be met by a corresponding
update to the definitions of technically constrained, since the above
proposed text would not apply under such circumstances (that is, such a CA
would be able to issue arbitrary SRVNames)


>
> In section 7.1.4.2.2(a), append the following sentences to "Contents":
>
> 'If the value from the subjectAltName extension contains at least one
> label that starts with "xn--" (an "A-label"), this field may contain the
> Unicode encoding of the A-labels (an "U-label"), provided that all A-labels
> in the value are converted to U-labels. There MUST NOT be more than one
> commonName attribute in the Subject Distinguished Name.’
>

It'd be useful to explain (preferably on the list, rather than the call)
the goal of this.

Given the risks here (and the IDNA processing model of various relying
parties), I'm much more keen to prohibit Common Name than expand the
possible value set, especially when that value set, on some platforms,
would potentially allow for confusion due to how they process U-labels in
CNs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160408/189a35df/attachment-0003.html>