[cabfpub] Ballot 184 - SRVnames

[Ryan Sleevi]

On Wed, Nov 15, 2017 at 12:55 PM, Peter Bowen <pzb at amzn.com> wrote:

>
>
> > On Nov 15, 2017, at 9:46 AM, Gervase Markham via Public <
> 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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171115/7f966d2a/attachment-0003.html>