I'm relatively new to the ways of the IETF, so I apologize if this discussion is out of scope for this list.
Google began the CT process by producing an Experimental RFC within the IETF. Google then asked CAs to build what's specified in that Experimental RFC. Some issues were uncovered and discussed; issues and resolutions have been tracked in the IETF issues tracker for 6962-bis. I think that's how I got confused into thinking that we should be discussing deployment concerns in the Trans working group. Up until recently, I had thought that we were expected to build 6962-bis by January, not 6962. I speak for a number of CAs when I say that many of us are confused about exactly how to build CT. We have no single reference spec to follow. Ben has said that we should follow 6962, but not 6962-bis except for Ticket #1 and the language in 6962-bis for that Ticket. But I guess we're supposed to ignore the other tickets and the rest of the -bis document. Since what we're building for January seems to be out of scope for this working group, I think it would be extremely helpful if Google would produce a single document that we can all march to. Maybe that should be circulated through the CA/Browser Forum, although not all CAs are represented there, but there seem to be more there than in the Trans working group. Finally, to paraphrase Steve, I would say I'm "reluctant to deploy an Experimental protocol that may deviate in significant ways from the eventual standard". -Rick -----Original Message----- From: Trans [mailto:[email protected]] On Behalf Of Stephen Kent Sent: Thursday, July 24, 2014 9:39 AM To: Ben Laurie Cc: [email protected] Subject: Re: [Trans] Contributing to the issue tracker Ben, > ... > But we're marching towards a flag day now. >> Google has chosen to adopt a flag day approach for its 6962 deployment. >> This WG gets to make it's own decision on this topic. But, in any >> case, 6962-bis needs to state explicitly whether it assumes a flag >> day or incremental deployment. >> >>> He also suggested trying to >>> simplify precertificates or come up with alternatives, and that's >>> captured in Ticket #26, but that's unlikely to be done in time to >>> help any CAs before January. >> Not an issue for this WG, because you're discussing a Google-centric >> activity, not the standard that this WG is developing, right? > Well, it looks like it might be a good idea to do it for -bis. What is the "it" to which you refer? a different pre-cert model? >>> I don't think it is correct to characterise what we're doing as a >>> flag day. You can absolutely deploy CT before we switch it on in Chrome. >>> What we're marching towards is a deadline, a completely different >>> thing. >> What can be deployed before this WG is done is an implementation of >> an experimental protocol, not the standards track protocol being >> developed. How is the deployment of that experimental protocol >> relevant to the discussion of what is in the standards track doc? > What I mean is that the protocol as specified so far (in 6962-bis) > does not require a flag day. Is your point that this needs to be > explicitly stated? The protocol, as currently specified in 6962-bis, does not seem compatible with incremental deployment, yet it also does not state that a flag day is required. For example, if a TLS client MUST reject a cert with an accompanying SCT, how does this work in an incremental deployment scenario? >>> On precertificates, one thing I should clarify is that Google will >>> not be adopting 6962-bis before January, even if it is done by then, >>> for the obvious reason that there's not going to be enough time. >> again, I assume our ongoing discuss is about 6962-bis. > Indeed, I am just clarifying what we're implementing. A discussion of what Google is implementing, based on an Experimental RFC, ought not be construed as relevant to what a standards track RFC will mandate. Or, are you saying that Google feels that browser vendors, CAs and log operators will be reluctant to deploy a standard that deviates in significant ways from the Experimental protocol? Steve _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
