Eran,
Thanks for the careful reading of the architecture doc, and the
comments. Response below, in-line.
Overall the relationships between the different entities that
participate in CT are well described in this document. The diagrams
and concise description of the roles of each entity make it easy to
read and understand. It should serve well to establish common
terminology around CT.
thanks.
Most comments I have are nitpicks - I realize there's a trade-off
between accuracy and conciseness and tried only pointing out where (I
think) it's significant.
Issues filed:
Ticket #148 - Architecture document: Spelling/improvements to Introduction
Ticket #149 - Architecture document: Figure 1: Finer-grained
distinction between entities
Ticket #150 - Architecture document: Indicate missing SCT is
equivalent to invalid one.
Ticket #151 - Architecture document: Only the leaf cert + timestamp
are in the SCT.
Ticket #152 - Architecture document: CT-aware TLS clients may require
SCTs for all certs.
I have responded to each ticket, using the issue tracker, so I won't
repeat those responses here.
Other comments and suggestions:
On section 3, The elements of CT architecture:
Figure 2:
- Browsers also need to get fresh STHs and consistency proofs between
STHs to use the output of get-proof-by-hash.
I would say that somewhat differently; browsers may choose to get this
info so that
they can have higher confidence that an SCT really corresponds to a log
entry. But saying
that browsers "nee" to get this info seems a bit too stringent, at this
time. This is a topic
for the browser spec, an initial version of which was posted by David
Mandleberg late last year.
- Suggesting to drop the "Browser Vendor" component as it's arguably
redundant - a browser vendor would care about the output of the auditor.
We included BV as a separate component because of its role in providing
log metadata to browsers
and as a source of revocation status data. I agree that a BV cares about
Auditor info. I think
we said that explicitly
- Suggest adding a footnote that "An auditor can actively verify MMD
compliance by submitting new entries to the log and checking when
they're appended to the tree.".
good point. We might mention that here, but it's primarily a topic for
the Auditor spec.
Figure 3:
- Nitpick, but subjects may request revocation from CAs - Is it more
common for browsers to accept revocation requests from subjects or
base their blacklists on CRLs issued by CAs? if the latter, than the
figure may be less surprising if that's the path stated there.
yes, in general, a Subject requests a CA to revoke its own cert, or one
issued in the name of
the Subject. Sorry that we omitted that line. We'll add it. the Figure
does not show a browser
requesting revocation of a cert, just getting revocation status data
from ether a CA or a BV,
Figure 4, repeating later in section 3.3 Monitors:
- The acceptable public keys may be optional - a monitor may simply
notify a Subject of each new certificate it observes. While I don't
think this option should be mentioned everywhere monitors are
mentioned, it's worth noting there may be other operation modes for
monitors.
I agree that a Monitor could do that, but such behavior is not mentioned
in 6962-bis, nor in the
Monitor/Auditor spec we posted. This is a good example of why we need to
have more discussion
in the WG about what behavior we expect for all elements of CT, not just
the log.
3.5. CT-aware TLS clients:
- One paragraphe before the end, mentioning feedback to log operators
via subjects - suggest adding an explicit reference to the section in
the Gossip draft that describes this reporting mechanism (or at least
explicitly state the Gossip document describes such a mechanism).
The architecture doc is focused on what CT standards call for, and the
Gossip doc is currently
designated as Experimental. So I am reluctant to cite it. However, if
you propose a sentence
or two to add to this section, we can see if it fits.
3.6. Auditors:
- For MMD monitoring, I suggest indicating that an auditor can check
MMD actively by submitting new entries to the log (either by issuing
them or by gathering them from the internet and feeding them to the
log). That's what Google's monitor does, for example.
As I said above, this is primarily a topic for the Auditor spec, but I
will add the following text after the first sentence in the paragraph:
For example, an Auditor might submit an certificate to a log and request
an STH after the indicated MMD, to verify that the log is meeting its
advertised MMD.
Regarding the TBD parts (Monitor-auditor, CA-subject,
browser-vendor), what prevents writing them? Shall I have a go at
contributing text?
The architecture doc was posted on 12/17, before we posted the I-Ds for
each of TBD references you noted above. Those I-Ds were posted on 12/19,
12/23, and 12/24. Comments/contributions are welcome for these documents
too.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
