[cabfpub] Draft Ballot - Subject Common and Alternative Names

[Ryan Sleevi]

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

> You are correct that 7.1.5 needs updating, as a (d) needs to be added that
> starts “For each SRVName in permittedSubtrees …”.  That being said, the
> sentence I proposed above references “named constrained” CAs not
> “technically constrained” CAs.  My intent was to say that any CA that has
> dNSName constraints but does not have SRVName constraints (which is likely
> almost all current name constrained CAs) does not have carte blanche to
> issue certificates with SRVNames but can do so for subtrees they are
> already allowed.
>

What will clients do? My understanding is that clients won't name-constrain
SRVNames to the dNSName constraints, so as a practical matter, a
technically constrained subCA would be able to issue arbitrary SRVNames.

Certainly, of the APIs represented by the vendors in the Forum, it would be
problematic to implement this support correctly in the application layer,
due to the lack of influence in the path building API.


> I think there are three options for when NC do not include SRVName
> constraints: 1) As above, they can include SRVNames only where the Name
> portion is allowed as a dNSName or 2) forbid them from issuing unless at
> SRVName is present in at least on of the constraint subtrees or 3) the CA
> is allowed to issue anything.  Do you think it would be better to forbid
> existing name constrained CAs from including SRVNames in certificates?
>

That's where I lean, yes.

This is the admitted downside to technically constrained sub-CAs (and, in
general, the nameConstraints extension), in that every existing certificate
has carte blanche, from a client PKI perspective, to issue whatever they
want for the new name.

I suppose one solution would be if clients rejected a name type if it
appeared in a SAN but did not appear in permittedSubtrees, but for which
permittedSubtrees was present, but...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160409/ea02318d/attachment-0001.html