[cabfpub] Draft Ballot - Subject Common and Alternative Names

[Peter Bowen]

> On Apr 8, 2016, at 4:36 PM, Ryan Sleevi <sleevi at google.com> wrote:
> On Fri, Apr 8, 2016 at 4:15 PM, Peter Bowen <pzb at amzn.com <mailto: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)

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.

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?

Thanks,
Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160408/a23ee2e0/attachment-0003.html>