Having reviewed Rob's changes that moved the text relevant to each component to a separate section, I can attest it makes 6962-bis much simpler to read. 6962-bis is long, but my opinion it is due to features added to the protocol we've found necessary when deploying RFC6962.
There's also mention of issues (for non-log components) that 6962-bis doesn't cover. Can these issues be explicitly stated? The only issue I can think of is the methods TLS clients, monitors and auditors exchange information gleaned from the log, and that is addressed by the Gossip draft. The threat analysis document does an excellent job of describing the dependency between gossiping mechanisms and the overall security properties of the protocol, and it is all properly separated from 6962-bis. >From an implementation perspective, based on a colleague's experience, having the specification for all components in one place is handy as the same data structures are used in the TLS client, log and on the CA side (e.g. both logs and CA client software have to process precertificates).In particular, moving the name redaction mechanism to a separate document means it won't be tested as a part of 6962-bis implementation, which is a bad idea, given it's a completely new functionality in 6962-bis that pertains to CAs, logs and TLS clients. I strongly support Melinda's request for comments from people who've got implementations - at this stage I believe insights from implementations of 6962-bis should guide further changes (aside from the issues already captured in the issue tracker). On Tue, Jan 19, 2016 at 5:52 AM, Melinda Shore <[email protected]> wrote: > On 1/18/16 8:03 PM, Karen Seo wrote: > >> 3. Could the WG please review/consider the drafts on CA/Subject, >> Browsers, and Monitor/Auditor? These "backfill" many of the missing >> pieces. Also, putting all the text on a given topic in one place >> should make things easier for the reviewer and eventually for the >> implementer. >> > > If people who've got implementations underway could weigh in > on this, we'd be grateful. That would include BBN, if you've > got one in development. > > Thanks, > > > Melinda > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
