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? 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?
#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.
#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.
#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.
#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).
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
