On Thu, Jan 8, 2015 at 7:49 PM, Stephen Kent <[email protected]> wrote: > I have a few questions/comments about the set of proposed ticket closures: > > > #37 - Are the gossiping clients discussed by this ticket just Auditors and > Monitors, or > does it apply to TLS clients as well?
Yes. Do you find it necessary to explicitly state that? > Also, if gossiping is addressed in a separate set > of docs, does that mean that 6962-bis will make only minimal mention of > it? That seems > appropriate since until those specs are completed and approved, on cannot > attribute > any security features to gossiping, right? > Correct - let's break this to two: (1) How clients can compare instances of Signed Tree Heads. (2) The security features that are achieved by comparing instances of STHs. 6962-bis makes only minimal mention of gossip in relation to (1). Regarding (2), rfc6962-bis can only point out the overall benefit of comparing STH instances (and it does), but the exact security benefits depends on the mechanism used for (1). FYI, the text diff is here: https://github.com/google/certificate-transparency-rfcs/commit/52b15187c291a9a9e4aa2fa7146693d7487899f4 > > #15 + #38 - For what range of clients is behavior not being specified? My > recollection from > the IETF meeting was that the discussion focused on TLS clients, not > Monitors or > Auditors, but the ticket closing comment is not clear on this point. Also, > is it useful > (vs. confusing) to discuss possible client behaviors in this doc, yet > mandate none? I don't > recall this issue (what to say about client behavior if we mandate none) > being discussed > ion detail on the list. > (1) Client behaviour is mostly not specified for TLS clients, which, as you correctly point out, was the topic discussed during the IETF meeting. Regarding monitors, given that there's benefit to the community even from partial monitors, I do not think it's reasonable to require a monitor to do *all* the things described in 6962-bis to be compliant, but point out the useful operations a monitor can perform and how it can do them. (2) I think it's useful to point out the possible situations a TLS client my find itself in, so we have common terminology when we discuss client behaviour. It was not discussed on detail on the list but different aspects have been brought up in the last IETF meeting and on several tickets. > > #40 - I don't recall seeing an explanation by the editors about why they > have decided > that "stand-along auditing isn't likely to happen." Absent such an > explanation, and WG > concurrence, it seems that closing this ticket is premature. > Is "based on experience from deploying RFC6962" a valid explanation? :) In my opinion this section in RFC6962 was not clear and Ben added (in-person) that his intent was never to have a stand-alone entity that only does auditing, but that it is something that each participant in CT could do. The original section in RFC6962 contained a bit of both, so we cleared it up to indicate what are the auditing operations each participant can do. > > #42 - Since this is a ticket I submitted, let me say that I don't think the > adverb "overly" is appropriate ;-). My concern is that the text didn't > provide an > algorithmic way to determine when a submitted (pre-)cert with a redacted > SAN was > "dangerous" and ought not be accepted. Also, the issue was not whether a > single entity > controls the name space covered by the redacted name; it's whether the CA > submitting the > pre-cert controls that space. Finally, if we are not specifying how any > client (TLS or Monitor) > makes use of this feature, why is it part of the spec? Unless we have an > agreed-upon set of > rules for how to use redacted certs, we are adding complexity to 6962-bis > without identifying > any benefits. > (1) to the best of my knowledge, detecting when a wildcard in a SAN is "too wild" is not specified anywhere, other than the CA/Browser Forum BR, and that is an equivalent problem. That's why I don't think it's appropriate to try and specify it here. (2) This falls into the TLS client behaviour specification - we'll point out this situation but it's up to the client to decide what to do with such a certificate. > > #43 - If key rollover is not supported, then the "freeze and begin a new > one" process > needs to be documented in detail. This description must describe how > clients of the old > log become aware of the transition to a new log (to avoid false positives). > Acknowledged - this will be described in the metadata section I intend to add. > > 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
