On 24/10/16 00:28, Ryan Sleevi wrote: <snip> > Either we accept CT compliance is locally defined - which suggests > optionality - or it's an unnessecary constraint on policy inconsistent > with existing 6962 implementations.
RFC6962 and 6962-bis specify the technical mechanisms of CT. Therefore, it seems entirely appropriate for these documents to define what constitutes basic CT compliance. This doesn't prevent TLS Clients from adding extra/stricter requirements via their own CT Policies though. For example, 6962-bis draft 19 section 10.2.5 says... "To be considered compliant, a certificate MUST be accompanied by at least one valid SCT." ...but section 8.1 recognizes that... "TLS clients may have policies related to the above risks requiring servers to present multiple SCTs. For example, at the time of writing, Chromium [Chromium.Log.Policy] requires multiple SCTs to be presented with EV certificates in order for the EV indicator to be shown." Similarly, I think a future Chrome CT Policy could conceivably state that Chrome will only accept SCTs that correspond to end-entity certs, even though 6962-bis specifies the option of SCTs for name-constrained intermediates. That said, if you're certain that Chrome won't accept SCTs for name-constrained intermediates as currently defined in 6962-bis, then I'd be in favour of moving this feature to the Redaction draft. Since we've completed WGLC for 6962-bis, I presume this possible course of action would be a matter for the WG chairs and/or Area Directors to consider. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
