[cabfpub] Ballot 184 - SRVnames

[Ryan Sleevi]

On Wed, Nov 15, 2017 at 2:26 PM, Gervase Markham <gerv at mozilla.org> wrote:

> On 15/11/17 10:00, Ryan Sleevi wrote:
> > Could you clarify what you view "enabling SRVNames" as?
> >
> > - Browsers/client software: In supporting them
> > - The CA/Browser Forum: In dictating validation rules
>
> This one...
>
> > - (Unconstrained) CAs: In issuing them
> > - TCSCs: In issuing them
>
> ...which allows these two. Without issuance, it seems unlikely client
> software will support.
>

I would actually suggest the inverse - without client desire/support with
appropriate protections, then allowing issuance seems like it will further
salt-the-field and prevent SRVnames from being safely deployed in the
future.

As it stands today:
TCSCs can issue SRVNames in violation of the BRs, but that's "ok" because
no one trusts them

As it would stand with Peter's proposals:
TCSCs can issue SRVNames in violation of the BRs, but as long as no one
trusts SRVNames, that's "ok"


However, it would seem unwise for any browser software (or any software,
for that matter) to support SRVNames under either scheme, because of the
risk posed by TCSCs having global issuance capability, and no appropriate
supervision.

So one option is require that TCSCs include SRVNames - and that requires
revoking all existing TCSCs and issuign new ones with new constraints.
That's... unappealing. For everyone.
Another option is to introduce some further signal to indicate that 'this'
SRVName is safe to trust. This was the proposal I sketched out for you.
  - It means that existing software that supports SRVNames is unaffected
(and, for the record, also arguably insecure)
  - It means that future software wanting to consider SRVName support can
minimize the risk of TCSCs being unconstrained, and have some degree of
assurance re: what the CA has issued

Can we add to the BRs SRVName validation? Absolutely.
Is it meaningful/sufficiently secure without addressing the TCSC loophole?
Nope
Should client software support w/o addressing that loophole? Heck no.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171115/906a3f6a/attachment-0003.html>