[cabfpub] Ballot 184 - SRVnames
pzb at amzn.com
Wed Nov 15 19:32:05 UTC 2017
> On Nov 15, 2017, at 10:00 AM, Ryan Sleevi <sleevi at google.com> wrote:
> On Wed, Nov 15, 2017 at 12:55 PM, Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com>> wrote:
> > On Nov 15, 2017, at 9:46 AM, Gervase Markham via Public <public at cabforum.org <mailto:public at cabforum.org>> wrote:
> > On 15/11/17 09:38, Ryan Sleevi wrote:
> >> I gave an option immediately preceding the text you snipped, along with
> >> the trade-offs such options come with.
> > So you are suggesting we don't enable SRVnames until someone has specced
> > such an extension and it's been implemented?
> Could you clarify what you view "enabling SRVNames" as?
> - Browsers/client software: In supporting them
> - The CA/Browser Forum: In dictating validation rules
> - (Unconstrained) CAs: In issuing them
> - TCSCs: In issuing them
By “enabling SRVNames” I mean allowing unconstrained CAs to include them in certificates they sign. We know that certain client software already support checking them, and the request here is not to have browsers check them.
> Another option is to just forbid CAs with DNS name constraints from issuing SRVname certificates unless they have SRVname constraints defined as well. That doesn’t change things compared to today — the only thing preventing them from issuing SRVname certificates is the BRs.
> I'm not sure that's entirely an accurate picture.
> That is, I think programs that use TCSCs to allow for less oversight would, effectively, be prohibited from supporting SRVNames without some degree that misissuance would not pose risk.
> The approach you describe wouldn't actually mitigate that risk, so I don't think would reasonably achieve Gerv's goal of saying that they're adequately constrained.
> It very much is a chicken-and-egg problem here.
> Browsers cannot safely support SRVNames without having assurance about how those SRVNames are validated. Because they don't support them, this isn't an issue, but if they were, it would be.
> So you need the CA/Browser Forum (or equivalent) to define an acceptable way of validating them.
> TCSCs exist, in part, because they limit the risk of improper validation. Thus, allowing a new type without adding it to the TCSC means the new type is at risk of improper validation.
> There is not an easy way, due to RFC 5280, to add a new type without granting that capability to existing TCSCs, thus introducing risk (of improper validation).
> I don't think your proposal mitigates any of that risk - it just says "that's misissuance", but doesn't minimize the (global) risk such misissuance would pose, and as a result, doesn't provide a safe way for browsers to add support.
> There's a further wrinkle that if you try to permit issuance prior to describing the mitigation issues, or prior to implementation, then there's an ecosystem concern that you may see adoption of the insecure practice prior to the development of the secure practice, or the insecure practices' existence used to drain resources from the secure practice.
I’m still confused by “mitigation”. There is client software today that supports SRVNames. The request is to allow public CAs to issue certs with SRVNames type SANs, not for browsers to look at them.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Public