On Wed, Nov 15, 2017 at 2:26 PM, Gervase Markham <[email protected]> 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.
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
