[cabfpub] Draft Ballot - Subject Common and Alternative Names

[Peter Bowen]

> On Apr 9, 2016, at 12:09 AM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> On Fri, Apr 8, 2016 at 9:44 PM, Peter Bowen <pzb at amzn.com <mailto: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.

Clients will do exactly what they do today, which is allow SRVNames for any CA that doesn’t have a SRVName constraint.

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

The only thing preventing a name constrained CA from issuing certificates with SRVName in them today is the BRs.  I was going for a balance to allow existing scoped CAs to issue for their scope. However that would require relying on the CA to do the right thing (which is what we already do).

Either way, I want to ensure that CAs that are considered technically constrained today don’t suddenly fail to be considered technically constrained just because SRVNames become allowed.

Thanks,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20160410/d8d6d114/attachment.html