Subject: [Trans] Review of the architecture document (draft 1)

From: Eran Messeri <[email-masked]>
Date: Fri, 8 Jan 2016 09:15:21 -0800

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.

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.

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.
- Suggesting to drop the "Browser Vendor" component as it's arguably
redundant - a browser vendor would care about the output of the auditor.
- 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.".

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.

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.

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).

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.

Regarding the TBD parts  (Monitor-auditor, CA-subject, browser-vendor),
what prevents writing them? Shall I have a go at contributing text?

Again thanks for putting this document together, it's very thorough.

Eran

---

From: Ben Laurie <[email-masked]>
Date: Fri, 8 Jan 2016 10:28:45 -0800

> to use the output of get-proof-by-hash.

This is why we added get-all-by-hash.

---

From: Eran Messeri <[email-masked]>
Date: Mon, 11 Jan 2016 09:49:20 -0800

On Fri, Jan 8, 2016 at 10:28 AM, Ben Laurie <[email-masked]> wrote:

>> - Browsers also need to get fresh STHs and consistency proofs between
>> STHs to use the output of get-proof-by-hash.
>>
>
You're right.
If the Architecture document documents RFC6962-bis (rather than the
existing RFC6962),  it should be changed to mention get-all-by-hash.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 12 Jan 2016 14:32:40 -0500

yes, the arch doc is focused on the standards track CT design.

>
>
> On Fri, Jan 8, 2016 at 10:28 AM, Ben Laurie <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>     On 8 January 2016 at 09:15, Eran Messeri <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         - Browsers also need to get fresh STHs and consistency proofs
>         between STHs to use the output of get-proof-by-hash.
>
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans

---

From: Stephen Kent <[email-masked]>
Date: Wed, 13 Jan 2016 12:24:46 -0500

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 #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.
> 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.
> 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
> 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,

> - 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.
> - 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 
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