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

From: Eran Messeri <[email-masked]>
Date: Wed, 3 Feb 2016 17:14:38 +0000

Thanks for addressing all of my comments.

On Wed, Jan 13, 2016 at 5:24 PM, Stephen Kent <[email-masked]> wrote:

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

I agree that we should have more discussion in the WG about the behaviour
expected for all elements of CT - I don't think it should hold up 6962-bis,
though, which describes the protocol these elements use to exchange
information they have about certificates and logs.
I very much like to see CT evolve and there are definitely areas for
clarification on what monitors / clients  should do with observations about
certificates / CT logs they obtain. I just think that without implementing
and deploying the basic protocol described in 6962-bis it will be very hard
to gain the insight on what clients and monitors should do. I find the
documents you and your team produce explore very well the actions each
entity can take and 6962-bis is (IMHO) designed in an extensible way to
enable exchanging more information, should we discover the original
specification lacked it.

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

My proposal is along the lines of "The Gossip protocol described in
<reference to Gossip I-D> is one of the mechanisms that may be used to feed
the information back to log operators."

>
>
>> 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-masked]
> https://www.ietf.org/mailman/listinfo/trans
>