> On Apr 9, 2016, at 12:09 AM, Ryan Sleevi <[email protected]> wrote:
>
> On Fri, Apr 8, 2016 at 9:44 PM, Peter Bowen <[email protected]
> <mailto:[email protected]>> 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
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
