Gervase Markham <[email protected]> wrote: > RFC 6962bis (the new CT RFC) allows certs below technically-constrained > sub-CAs (TCSCs) to be exempt from CT. This is to allow name privacy. > TCSCs themselves are also currently exempt from disclosure to Mozilla in > the Common CA Database. > > If this is the only privacy mechanism available for 6962bis,
First, here's the RFC 6969-bis draft: https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-20#section-4.2. Please see my other messages in this thread, where I pointed out that Mozilla's own definition of externally-operated name-constrained sub-CAs should be improved because name constraints don't mitigate every serious concern one might have regarding technically-constrained sub-CAs. I think that's clearly true for what RFC 6962-bis is trying to do with name constraints too. I think there might be ways to fix the name-constrained sub-CA stuff for RFC 6962-bis, but those kinds of improvements are unlikely to happen in RFC 6962-bis itself, it seems. They will have to happen in an update to RFC 6962-bis. I also disagree with Google's position that it is OK to leave bad stuff in the spec and then ignore it. The WGLC has passed, but that doesn't mean that the spec can't be changed. Google's already proposed a hugely significant change to the spec in the last few days (which I support), which demonstrates this. Accordingly, I think the exception mechanism for name-constrained sub-CAs (section 4.2) should be removed from the spec. This is especially the case if there are no browsers who want to implement it. If the draft contains things that clients won't implement, then that's an issue that's relevant for the IETF last call, as that's against the general IETF philosophy of requiring running code. Cheers, Brian _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
