Re: LC comments on draft-laurie-pki-sunlight-05

[Ben Laurie <[e-mail]>]

On 1 January 2013 21:50, =JeffH <[e-mail]> wrote:
> Hi,
>
> Here are some last call comments on draft-laurie-pki-sunlight-05.
>
> Overall the spec is in basically overall reasonable shape but I do have some
> substantive comments that if I'm not totally misunderstanding things (which
> could be the case) ought to be discussed and addressed in some fashion.
>
> The plain overall comments are to some degree "take 'em or leave 'em"
> depending upon folks' sense of urgency to get the spec through the IETF
> pipeline, but the degree likely depends upon the observer.
>
> I hope this is helpful,

It is indeed,  thankyou.

> =JeffH
> ------
>
> comments on draft-laurie-pki-sunlight-05
>
> substantive comments (in somewhat arbitrary order)
> --------------------------------------------------
>
> 1. The client messages S4 don't explicitly lay out the syntax for request
> messages or responses. E.g., for S4.1 "Add Chain to Log", is the input a
> stand-alone JSON text array, or a JSON text object containing a JSON text
> array?
>
> The term "JSON object" as used in the first paragraph is ambiguous and
> perhaps what is mean is simply "JSON texts" or "JSON text objects or JSON
> text arrays". RFC4627 clearly defines "JSON text", and should be cited. But
> RFC4627 is a little ambiguous itself regarding "JSON object" and so I
> suggest these definitions:
>
>     JSON text object:   A JSON text matching the "object" ABNF production
>        in Section 2.2 of [RFC4627].
>
>     JSON text array:   A JSON text matching the "array" ABNF production
>        in Section 2.3 of [RFC4627].

I agree that RFC 4627 should be cited and I will correct that. The
rest of this confuses me: JSON is a textual representation of
structured data, as it states in the RFC. It defines an object quite
clearly

" An object is an unordered collection of zero or more name/value
   pairs, where a name is a string and a value is a string, number,
   boolean, null, object, or array."

Defining a "JSON text object" seems pointless to me - clearly a JSON
object is an object as defined by JSON, surely? Introducing another
term seems like to add confusion rather than remove it.

>
> Also, the syntax for GETS isn't fully specified. Are the URL parameters to
> be encoded as (order independent) key-value pairs, or just as
> order-dependent values?  Which separator character is to be used between
> parameters? RFC3986 should be cited.

RFC 3986 says nothing about parameter format, though - is there a
standard reference for that? I've refereced HTML 4.01, but perhaps
there's a better one?

> Examples for both JSON text inputs and outputs, as well as URL parameters
> would be helpful.

Yes, we will provide some.

> 2. "4. Client Messages" doesn't define error handling, i.e., responses to
> inputs the log service doesn't understand and/or is unable to parse, and/or
> have other errors. If the log service is to simply return a 4xx or 5xx error
> code, this should at least be mentioned.

For now, I will specify 4xx/5xx. We may have more to say once we've
gained some experience.

> 3. There appear to be three defined methods for TLS servers to provide TLS
> clients with CT data, in S3.2.  For this experiment, which approach is
> mandatory to implement for servers and clients?  Or, is it the case that
> participating TLS clients (ie web browsers etc) implement all three methods,
> and TLS servers can choose any of them?

The latter.

>
> Also, S3.2 probably doesn't belong in S3 and perhaps should be a separate
> top-level section on its own, and have three subsections, one for each
> method.

Maybe.

> 4. "Leaf Hash" as used in S4.5 appears to be formally undefined. It
> apparently would be:
>
>       SHA-256(0x00 || MerkleTreeLeaf)
>
> ..it should also be noted in S3.3.

You are right.

> 5. The recursive equations in S2.1 describe how to calculate a Merkle Tree
> Hash (MTH) (aka "root hash"), and thus as a side effect generate a Merkle
> Tree, for a given set of input data. However, there doesn't seem to be a
> defined algorithm (or even hints, really) for adding further inputs to an
> existing tree. Even though this may be reasonably left as an exercise for
> implementers, it should probably be discussed to some degree in the spec.
> E.g., note that leaf hashes are "frozen" and various interior tree node
> hashes become "frozen" as the tree grows. Is it not sub-optimal to employ
> the obvious default brute-force mechanism of rebuilding a tree entirely from
> scratch when new inputs are available?  Would not a recursive algorithm for
> adding new inputs to an existing tree be straightforward to provide?

I dunno about straightforward. I'll think about it.

> 6. Signed tree heads (STHs) are denoted in terms of "tree size" (number of
> entries), but SCTs are denoted in terms of a timestamp.  Should there be a
> log client message supporting the return of the nearest STH (and thus tree
> size) to a given timestamp?

I'm not sure why? Any STH (that includes that SCT) will do.

> 7. S3 paragraph 2 states that "TLS clients MUST reject certificates that do
> not have a valid SCT for the end-entity certificate" (i.e., hard-fail).
> Presummably this requirement is only for TLS clients participating in the CT
> experiment and that understand this protocol.

Of course - what other way could it be? In other words, all RFCs can
only say what implementations that conform with them do.

> This, or whatever the
> requirement actually is, should be further explained.

?

> For example, does the simple presence of SCT(s) in the TLS handshake serve
> to signal to participating TLS clients that hard-fail is expected if there
> are any issues with CT validation?

We are not saying what action a client should take when it rejects a
certificate, as is, I believe the usual practice.

> 8. The spec implies, but doesn't clearly describe, especially in S3.1, that
> the hashes are "labels" for tree entries, and that given a leaf hash, the
> log implementation should be able to look up and present the LogEntry data
> defined in that section.

We actually only require an entry to be retrievable by hash (in
effect) for the message in 4.7, which we (at least currently) label as
a debugging message - so I am not sure that logs really are required
to be able to do that - certainly the system would work fine if they
couldn't, I believe (other than being unable to provide the debugging
data).

> 9. Validating an SCT presummably requires having the Log Service's public
> key, yes?  This isn't clearly discussed, and also the mention of how one
> obtains a log service's public key is out of scope is buried in 2nd para of
> S4 -- it should be discussed in a separate clearly entitled subsection.

Good point.

>
>
> 10. Unless I'm totally missing it, there isn't an explicit description of
> how one (eg a TLS client) goes about validating/verifying an SCT.

Indeed, fixing that also fixes the above point.

> Various overall comments:
> --------------------------
>
> O-1. The phrase "this experiment" is used in S2.1 -- should describing this
> as an experiment be more explicitly done in the abstract and introduction
> sections?  What about the document title?

The plan is this will be an Experimental RFC, which seems clear enough to me?

> O-2. Should explicitly say in abstract and introduction that operationally,
> the logs are to be materialized as (experimental?) network services having
> the protocol operations for submissions and queries that are defined in this
> spec.

Seems a little redundant, but I have added something anyway.

>
>
> O-3. The bare term "client" is used in various places where either the term
> "log client" or "TLS client" is being implied -- these should be made
> explicit. Also the roles of log clients and TLS clients should be more
> thoroughly presented/explored, in part because they can intersect.

Section 5 "Clients" is an attempt to document the various client
roles, one or more of which may be embodied by any particular client
implementation, rather than try to deal with this intersection.

I have gone over mentions of "client" elsewhere to try to deal with
your point, though. Sometimes it just means "any client" so not all
instances have been changed.

>
>
> O-4. These things seem to be duplicate names:
>
>      "root hash" and "Merkle Tree Hash (MTH)"

Yes,

>
>      "Tree Head Signature" and "Signed Tree Head (STH)"

These are not the same - you are probably confused by the
digitally-signed struct, which is only used as input for a signature
and never appears in its own right. However, we haven't been super
clear about what's going on here and I've tried to clean that up.

>
> ..which makes parsing the spec more difficult than if one name is used
> consistently for each.
>
>
> O-5. The terms "leaf certificate" and "final certificate" appear to be used
> where..
>
>   End Entity certificate
>
>   final End Entity certificate
>
> ..would be clearer and more consistent with TLS and PKIX terminology, and
> perhaps less confusing with the terms "leaf" and "leaf node" which are used
> when discussing the Merkle trees and their components.

Good point.

> O-6. I found the "history tree" paper (aka "[1]", cited here as
> [CrosbyWallach]) helpful in understanding how such trees are constructed,
> perhaps it should be more prominently mentioned. Plus the differences
> between the two algorithms should perhaps be more explicitly mentioned. E.g.
> in [CrosbyWallach] version-n tree stores n+1 inputs, while in CT a version-n
> tree (D[n]) stores n inputs.
>
> [CrosbyWallach]  <http://tamperevident.cs.rice.edu/Logging.html>
>
>
> O-7. The note mentioning "dummy leaves" in [CrosbyWallach] seems misleading.
> The difference is AFAICT that in [CrosbyWallach] all nodes at layer 1 and
> above (leaf entries are at layer 0), are "interior nodes", and have hashes
> created using 0x01. Thus in a tree with an odd number of entries (ie leaf
> nodes at layer 0), there will be one leaf node under an interior node having
> only that one child. It's not that there is a "dummy leaf", it's that such
> an interior node's hash is constructed from just one child rather than two.

Not sure I really agree with this, but in any case I have reworded it
slightly. I've also changed the reference to be a "proper" one, shown
at the end of the I-D.

> While in CT, if the input set is an odd number of entries, then the hash of
> the final single leaf is at layer 1, and is calculated as a leaf hash using
> 0x00. Thus CT "interior nodes" always have two children, but if the tree has
> an odd number of entries, the rightmost hash at layer 1 ("j" in the "binary
> Merkle tree with 7 leaves" figure) is a leaf node hash rather than an
> interior node hash.
>
>
> O-8. [CrosbyWallach] discusses auditing and gossiping and could be cited as
> a source for further discussion on those topics.
>
>
> O-9. The notion of "commitments" isn't well defined, and where "add a
> commitment to D[k:n]"  couldn't  "add an interior/intermediate node to
> D[k:n}"  be used?
>
> Is not the term "commitment" used in [CrosbyWallach] equivalent to the
> sha256_root_hash (an STH component) in the spec?
>
> [CrosbyWallach] uses the term "interior node(s)" while the spec uses
> "intermediate nodes" (in one place).

CT is not actually derived from [CrosbyWallach], we just mention it as
a useful reference.

"commitment" is a term of cryptographic art.

> O-10. The recursive algorithms in S2 are dense and take effort to work
> through, perhaps adding simplistic example code (in an appendix) which
> implements, and/or actually working through the algorithms to arrive at some
> of the audit paths and consistency proofs in S2.1.3, would be helpful.

We have actual working code - would a reference to that be better?

> I desk-checked S2.1, and it seems correct, but didn't do S2.1.1 or S2.1.2.
> The examples in S2.1.3 appear nominally correct but I didn't desk check
> them.
>
> Should there be a reference to
> <https://code.google.com/p/certificate-transparency/> ?   And/or a note
> regarding available code and to contact the authors for more information?
> (as is done in RFC 2154)

I couldn't find such a thing in RFC 2154. My only concern about such a
reference is whether it would live as long as the RFC does :-)

> O-11. S3.3 should mention the Maximum Merge Delay MMD where it says
> "periodically append". Also, in S3.3, "Signed Merkle Tree Update" should be
> a "Tree Head Signature" aka "signed tree head (STH)"?

I just removed that, as it is immediately repeated in the next section.

>
>
> O-12. S3.3, S3.4, S4.4, S4.5, and S4.7 mention the notion of logs
> "publishing" STHs, but no mechanism is described for explicitly
> "publishing". Is this meant to mean only that a "published" STH is available
> for retrieval by clients using the "Retrieve Latest Signed Tree Head" log
> client message?
>
> Or, would there be a use case, eg introducing an existing log service to a
> log monitor, for requesting (or being able to enumerate) all published STHs
> from the log?

I don't believe there is: the latest STH tells you everything you need
to know at that point. I have removed mention of publishing.

>
>
> O-13. signed tree heads (STHs) are denoted in terms of "tree size" (number
> of entries), but SCTs are denoted in terms of a timestamp.  Should there be
> a log client message supporting the return of the nearest STH (and thus tree
> size) to a given timestamp?

I don't believe this is needed.

>
>
>
> O-14. Detailed comments on S2...
> ------------------------------
>
>> 2. Cryptographic components
>>
>>
>> 2.1. Merkle Hash Trees
>>
>>
>>    Logs use a binary Merkle hash tree for efficient auditing.  The
>>    hashing algorithm is SHA-256 (note that this is fixed for this
>>    experiment but it is anticipated that each log would be able to
>>    specify a hash algorithm).  The input to the Merkle tree hash is a
>>    list of data entries; these entries will be hashed to form the leaves
>>    of the Merkle hash tree.  The output is a single 32-byte root hash.
>>    Given an ordered list of n inputs, D[n] = {d(0), d(1), ..., d(n-1)},
>>    the Merkle Tree Hash (MTH) is thus defined as follows:
>>
>>    The hash of an empty list is the hash of an empty string:
>>
>>    MTH({}) = SHA-256().
>
>
> This MTH({}) construct doesn't appear to be used anywhere else in the spec
> (yes?), and so does it really need mentioning?

If it is not defined, then we cannot represent an empty tree.

>>    The hash of a list with one entry is:
>>
>>    MTH({d(0)}) = SHA-256(0x00 || d(0)).
>
>
> The immediately above equation is for leaf entries (yes?),

Yes.

> where in this
> notation n = 1, perhaps it should be stated explicitly:
>
>     When n = 1, a leaf entry is denoted, and D[1] = {d(0)}. The leaf hash
>     (LH) for a leaf entry is calculated as:
>
>     MTH(D[1]) = LH(D[1]) = SHA-256( 0x00 || d(0) )

Ugh. LH(D[1]) seems meaningless to me. A leaf hash is always of a "1
entry tree".

>
>
>
>>    For n > 1, let k be the largest power of two smaller than n.
>
>
> The unqualified "power of two" phrase is arguably ambiguous.

It is?

> Suggested rephrase for this where it occurs throughout section 2..
>
>     For n > 1, let k be a number which is the largest power of two
>     such that k = 2^i, 0 <= i < n, and k < n.

If we're going to go down that path, then it should say:

For n > 1, let k be the largest number such that k = 2^i and k < n.

or

For n > 1, let k = 2^i s.t. k < n and 2k >= n.

surely?

>>    The Merkle Tree Hash of an n-element list D[n] is then defined
>>    recursively as
>
>
> The above statement applies to the combination of the n = 1 equation above
> and the equation below, and so should perhaps be moved up above the n = 1
> equation.

? It says n > 1, so doesn't apply to n = 1?

>>    MTH(D[n]) = SHA-256(0x01 || MTH(D[0:k]) || MTH(D[k:n])),
>>
>>    where || is concatenation and D[k1:k2] denotes the length (k2 - k1)
>>    list {d(k1), d(k1+1),..., d(k2-1)}.
>
>
> The above phrase doesn't parse well and is somewhat ambiguous, here it is
> extracted for clarity:
>
>  "D[k1:k2] denotes the length (k2 - k1) list {d(k1), d(k1+1),..., d(k2-1)}"
>
>
> How about rephrasing it along the lines of this:
>
>     D[k1:k2] denotes a sublist {d(k1), d(k1+1),..., d(k2-1)}, having
>     (k2 - k1) elements, of the original input list D[n]. When (k2 - k1)
>     is 1, a leaf hash is calculated.

We tried lots of different ways of saying this and they were all a
little messy. Yours mixes concerns and is rather verbose, so not
convinced it is actually an improvement.

>
>
>                                          (Note that the hash calculation
>>
>>    for leaves and nodes differ.  This domain separation is required to
>>    give second preimage resistance.)
>>
>>    Note that we do not require the length of the input list to be a
>>    power of two.  The resulting Merkle tree may thus not be balanced,
>>    however, its shape is uniquely determined by the number of leaves.
>>    [This Merkle tree is essentially the same as the history tree [1]
>>    proposal, except our definition omits dummy leaves.]
>
>
> I suggest re-writing the first above Note along with the next paragraph in
> light of all above comments on S2 and [CrosbyWallach].

It was already partly rewritten as a result of above comments, so
let's see how you like the next version?

> O-15.  Some comments on S3:
> ------------------------------------
>
>> 3. Log Format
>
>
> this section isn't just about "format" of log - it's also about log
> behavior/operation

Good point.

>
>
>>    Anyone can submit certificates to certificate logs for public
>>    auditing, however, since certificates will not be accepted by clients
>>    unless logged, it is expected that certificate owners or their CAs
>>    will usually submit them.  A log is a single, ever-growing, append-
>>    only Merkle Tree of such certificates.
>>
>>    When a valid certificate is submitted to a log, the log MUST
>>    immediately return a Signed Certificate Timestamp (SCT).  The SCT is
>>    the log's promise to incorporate the certificate in the Merkle Tree
>>    within a fixed amount of time known as the Maximum Merge Delay (MMD).
>>    If the log has previously seen the certificate, it MAY return the
>>    same SCT as it returned before.
>
>
> What if the submitted end entity cert is the same, but the certificate chain
> is different (yet valid)?

The purpose of the chain is to:

a) Prevent spam, and

b) Identify who to blame in the event of a misissue.

Alternate chains presumably don't actually change the direct blame,
and so I see no reason to do other than what the I-D says - i.e.
return the same SCT as before.

>>                                     TLS servers MUST present an SCT from
>>    one or more logs to the client together with the certificate.  TLS
>>    clients MUST reject certificates that do not have a valid SCT for the
>>    end-entity certificate.
>
>
> [ see comment (7) above ]
>
>
>>    Periodically, each log appends all its new entries to the Merkle
>>    Tree, and signs the root of the tree.  Clients and auditors can thus
>
>
> Should "Clients and auditors" actually be "TLS Clients, log monitors, and
> log auditors" ?

Bearing in mind that these are actually roles rather than distinct
entities, it should probably just say "auditors".

>
>
>>    verify that each certificate for which an SCT has been issued indeed
>>    appears in the log.
>
>
> Add forward reference here to S4 and S5 ?
>
>
>
>>                         The log MUST incorporate a certificate in its
>>    Merkle Tree within the Maximum Merge Delay period after the issuance
>>    of the SCT.
>>
>>    Logs MUST NOT impose any conditions on copying data retrieved from
>>    the log.
>
>
> s/copying data retrieved/retrieving or sharing data/

OK.

>> 3.1. Log Entries
>>
>>
>>    Anyone can submit a certificate to any log.  In order to enable
>>    attribution of each logged certificate to its issuer, the log SHALL
>>    publish a list of acceptable root certificates (this list might
>>    usefully be the union of root certificates trusted by major browser
>>    vendors).  Each submitted certificate MUST be accompanied by all
>>    additional certificates required to verify the certificate chain up
>>    to an accepted root certificate.  The root certificate itself MAY be
>>    omitted from this list.
>>
>>    Alternatively, (root as well as intermediate) Certificate Authorities
>
>
> Additionally?  which manner is the experiment going to operate, or is it TBD
> ?

Not sure what you mean? The log will accept either type of submission.

>>    may submit a certificate to logs prior to issuance.  To do so, a
>>    Certificate Authority constructs a Precertificate by adding a special
>>    critical poison extension (OID 1.3.6.1.4.1.11129.2.4.3, whose
>>    extnValue OCTET STRING contains ASN.1 NULL data (0x05 0x00)) to the
>>    leaf TBSCertificate (this extension is to ensure that the
>
>
> leaf == end entity ?
>
> s/leaf certificate/end entity certificate/g   ?

Yes.

>>    Precertificate cannot be validated by a standard X.509v3 client), and
>>    signing the resulting TBSCertificate [RFC5280] with either
>
>
>
>>    o  a special-purpose (Extended Key Usage: Certificate Transparency,
>>       OID 1.3.6.1.4.1.11129.2.4.4) Precertificate Signing Certificate.
>>       The Precertificate Signing Certificate MUST be certified by the CA
>>       certificate that will ultimately sign the leaf TBSCertificate
>
>
> "sign the leaf TBSCertificate"  means to say "sign the actual
> issued-to-the-customer TBSCertificate component of the End Entity
> certificate" ?

Well, it means something like that, I have added some words.

>
>>       (note that the log may relax standard validation rules to allow
>>       this, so long as the final signed certificate will be valid),
>>
>>    o  or, the CA certificate that will sign the final certificate.
>
>
> "final certificate" is the "issued-to-the-customer End Entity certificate" ?

I have changed this to "issued certificate".

>
>
>>    Structure of the Signed Certificate Timestamp:
>
>
> The SCT discussion here should probably be its own subsection.

OK.

>
>
>>
>>        enum { certificate_timestamp(0), tree_hash(1), 255 }
>>          SignatureType;
>>
>>        enum { v1(0), 255 }
>>          Version;
>
>>
>>
>>          struct {
>>              opaque key_id[32];
>>          } LogID;
>>
>>          opaque CtExtensions<0..2^16-1>;
>>
>>    "key_id" is the SHA-256 hash of the log's public key, calculated over
>>    the DER encoding of the key represented as SubjectPublicKeyInfo.
>
>
> I'd place the above paragraph regarding "key_id" down below the
> SignedCertificateTimestamp definition.
>
>
>>        struct {
>>            Version sct_version;
>>            LogID id;
>>            uint64 timestamp;
>>            CtExtensions extensions;
>>            digitally-signed struct {
>>                Version sct_version;
>>                SignatureType signature_type = certificate_timestamp;
>>                uint64 timestamp;
>>                LogEntryType entry_type;
>>                select(entry_type) {
>>                    case x509_entry: ASN.1Cert;
>>                    case precert_entry: ASN.1Cert;
>>                } signed_entry;
>>               CtExtensions extensions;
>>            };
>>        } SignedCertificateTimestamp;
>>
>>    The encoding of the digitally-signed element is defined in [RFC5246].
>
>
> I would add a few words here summarizing that what happens here is that the
> digitally-signed struct here is replaced in the actual serialized binary
> structure by a struct DigitallySigned and cross-ref to S4.7 of RFC5246.

Except it isn't :-)

And we already reference RFC5246.

>> 3.2. Including the Signed Certificate Timestamp in the TLS Handshake
>
>
> This should be it's own top-level section as mentioned in comment (3).
>
>
>>    The SCT data from at least one log must be included in the TLS
>>    handshake, either by using an Authorization Extension [RFC5878] with
>>    type 182, or by using OCSP Stapling (section 8 of [RFC6066]),
>
>
> add to above sentence:
>
>   or by embedding the the SCT(s) in the presented End Entity cert,

Addressed earlier.

>>                                                                  where
>>    the response includes an OCSP extension with OID
>>    1.3.6.1.4.1.11129.2.4.5 (see [RFC2560]) and body:
>>
>>        SignedCertificateTimestampList ::= OCTET STRING
>>
>>    At least one SCT MUST be included.  Server operators MAY include more
>>    than one SCT.
>>
>>    Similarly, a Certificate Authority MAY submit the precertificate to
>
>
> s/the precertificate/a precertificate/

Yes.

>>    more than one log, and all obtained SCTs can be directly embedded in
>>    the final certificate, by encoding the SignedCertificateTimestampList
>
>
> s/final certificate/actual End Entity certificate/   ?

Addressed earlier.

>>    structure as an ASN.1 OCTET STRING and inserting the resulting data
>>    in the TBSCertificate as an X.509v3 certificate extension (OID
>>    1.3.6.1.4.1.11129.2.4.2).  Upon receiving the certificate, clients
>>    can reconstruct the original TBSCertificate to verify the SCT
>>    signature.
>
>
> This last step of "clients can reconstruct the original TBSCertificate"
> probably should be more thoroughly explained.

Yeah, it probably should.

> O-15.  Some comments on S4:
> ---------------------------
>
>
>> 4. Client Messages
>
>
> title should be "Log Client Messages" ?

Yes.

>>    Messages are sent as HTTPS GET or POST requests.  Parameters for
>>    POSTs and all responses are encoded as JSON objects.  Parameters for
>
>
> s/JSON objects/JSON texts/

I don't agree with this. See above.

> see <https://tools.ietf.org/html/rfc4627>  (it should be cited)
>
>>    GETs are encoded as URL parameters.  Binary data is base64 encoded as
>>    specified in the individual messages.
>>
>>    The <log server> prefix can include a path as well as a server name
>>    and a port.  It must map one-to-one to a known public key (how this
>>    mapping is distributed is out of scope for this document).
>
>
> s/distributed/constructed and distributed/  ?
>
>
>>    In general, where needed, the "version" is v1 and the "id" is the log
>>    id for the log server queried.
>
>
>
>
>
>> 4.1. Add Chain to Log
>>
>>
>>    POST https://<log server>/ct/v1/add-chain
>>
>>    Inputs
>>
>>    chain  An array of base64 encoded certificates.  The first element is
>
>
> a JSON text array?

It is already defined to be a field in a JSON object and hence that is
all it could be.

>>       the leaf certificate, the second chains to the first and so on to
>>       the last, which is either the root certificate or a certificate
>>       that chains to a known root certificate.
>>
>>    Outputs
>>
>>    sct_version  The version of the SignedCertificateTimestamp structure,
>>       in decimal.  A compliant v1 implementation MUST NOT expect this to
>>       be 0 (i.e. v1).
>>
>>    id The log ID, base64 encoded.  Since clients who request an SCT for
>
>
> s/clients/log clients/  ?

That seems obvious, but I have added it anyway.

>>       inclusion in the TLS handshake are not required to verify it, we
>
>
> s/the TLS handshake/subsequent TLS handshakes/   ?
>
>
>
>>       do not assume they know the ID of the log.
>>
>>    timestamp  The SCT timestamp, in decimal.
>>
>>    extensions  An opaque type for future expansion.  It is likely that
>>       not all participants will need to understand data in this field.
>>       Logs should set this to the empty string.  Clients should decode
>>       the base64 encoded data and include it in the SCT.
>>
>>    signature  The SCT signature, base64 encoded.
>
>
> "The SCT signature" means a SignedCertificateTimestamp structure ?

No, the signature that is a component of the structure.

>>    If the "sct_version" is not v1, then a v1 client may be unable to
>>    verify the signature.  It MUST NOT construe this as an error.  [Note:
>>    log clients don't need to be able to verify this structure, only TLS
>>    clients do - if we were to serve the structure binary, then we could
>>    completely change it without requiring an upgrade to v1 clients].
>
>
> Does this "if we were to serve the structure binary...."  statement mean to
> say that since v1 log clients don't need to be able to verify the SCT
> signature over the various returned data items, that this operation could
> instead return an opaque binary blob?

Indeed.

> O-16.  Some comments on S5:
> ---------------------------
>
>
>> 5. Clients
>>
>>
>>    There are various different functions clients of logs might perform.
>
>
> Perhaps this section should be entitled "Log Client Roles" ?

Since you persuaded me to include TLS clients, no :-)

> this section doesn't mention the role of a (CA) log client that submits
> "certs and cert chains" to logs. Even though the latter role is mentioned
> elsewhere in the spec it should perhaps be mentioned here also.

OK.

>
>
>> 5.1. Monitor
>>
>>
>>    Monitors watch logs and check that they behave correctly.  They also
>>    watch for certificates of interest.
>
>
> "Monitor" should be "Log Monitor" ?

There's no other kind of monitor :-)

>
>>
>> 5.2. Auditor
>>
>>
>>    Auditors take partial information about a log as input and verify
>>    that this information is consistent with other partial information
>>    they have.  An auditor might be an integral component of a TLS
>>    client, it might be a standalone service or it might be a secondary
>>    function of a monitor.
>
>
> "Auditor" should be "Log Auditor" ?

And there's no other kind of auditor.

>
>
>
>> 8. Efficiency Considerations
>>
>>
>>    The Merkle tree design serves the purpose of keeping communication
>>    overhead low.
>>
>>    Auditing logs for integrity does not require third parties to
>>    maintain a copy of each entire log.  The Signed Tree Heads can be
>>    updated as new entries become available, without recomputing entire
>>    trees.  Third party auditors need only fetch the Merkle consistency
>>    proofs against a log's existing STH to efficiently verify the append-
>>    only property of updates to their Merkle Trees, without auditing the
>>    entire tree.
>
>
> The above could be explained in more detail, and S5.1 should be
> cross-referenced. Is the last sentence above essentially a summary of step
> #8 in S5.1? Or are there differences?

It is a summary of 5.1

>
>
> ---
> end
>
>