Subject: Re: LC comments on draft-laurie-pki-sunlight-05 - "acceptable root certificates" ?

From: =JeffH <[email-masked]>
Date: Mon, 28 Jan 2013 14:41:28 -0800

> Apologies for responding to recent comments in random order: I'm
 > travelling and have accumulated something of a backlog.

no worries :)

thx again for your thoughts.

BenL replied:
 > On 22 January 2013 03:11, =JeffH <[email-masked]> wrote:

<snip>
 >>>  - is there a
 >>> standard reference for that? I've refereced HTML 4.01, but perhaps
 >>> there's a better one?
 >>
 >> hm, AFAICT, there is not a standard for URI query component formating and
 >> thus parameter encoding, so this spec will have to explicitly specify
 >> something. Section 3.4 of RFC3986 gives allowed chars for the query
 >> component, but that's about it.
 >>
 >> Have you mocked up code that parses the log client messages? If so, what
 >> query component syntax does it handle?
 >
 > I have specified the "standard" format via HTML 4.01.

ok, i assume you're referring to section 17.13 "form submission" of HTML 4.01, 
and using the  application/x-www-form-urlencoded  content type, with the 
parameters appended to the url encoded according to S17.13.4 ?

 >
 >>>> 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.
 >>
 >> That should be made very clear. Is the reason for doing so to obtain
 >> operational experience wrt the three defined methods such that they perhaps
 >> can be narrowed down in the future, or is the expectation that TLS-CT
 >> clients will need to support all three methods in perpetuity?
 >
 > I think I made that clear.
 >
 > The reason three methods exist are as follows (I don't intend to get
 > into this in the RFC, but for your edification):
 >
 > 1. TLS extension is the right way to do it, but requires a server s/w
 > change - this adds many years to full deployment.
 >
 > 2. So, alternatives must be provided. One is to put the stuff in the
 > certificate, but...
 >
 > 3. ... some CAs have said they'd rather not gate issuance on the log,
 > so alternatively, wedge the stuff in an OCSP response (which must be
 > stapled - servers exist that support this option already).

ok, thx for elucidation.

<snip>
 >>>> 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.
 >>
 >> Hm, it was sort of a gut feel that it might be useful, but perhaps not.
 >>
 >> S5.2. Auditor says..
 >>
 >>    A certificate accompanied by an SCT can be verified against any STH
 >>    dated after the SCT timestamp + the Maximum Merge Delay by requesting
 >>    a Merkle Audit Proof using Section 4.5.
 >>
 >> S4.5 get-proof-by-hash stipulates tree_size as an input,  but
 >> if a log auditor doesn't already have tree_size, then I suppose it first
 >> calls S4.3 get-sth, which will return a timestamp and a tree_size, which if
 >> generated max merge delay (MMD) after the SCT was gen'd, ought to be
 >> sufficient, yes?
 >
 > Yes.
 >
 >> I don't see in the spec where/how MMD is published.  Does MMD vary per log
 >> service?  The latter isn't stipulated in the spec it seems AFAICT ?
 >
 > We have not really figured out how MMD is specified. I suspect it is
 > something that will be agreed between browser vendors and logs.

ok, tho specified in terms of an operational value agreed between browser 
vendors and logs is different than whatever mechanism a log service uses to 
"publish" its chosen MMD value, and log monitors/auditors will want to get the 
MMD value(s), yes?

 >>>> 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.
 >>
 >> I guess what I was getting at is that CT-conformant TLS clients should be
 >> differentiated from non-CT-conformant ones. Stipulating a name for
 >> CT-conformant TLS clients would clarify this (seems to me), e.g. "TLS-CT
 >> client" or something similar.
 >
 > I understand what you're getting at, but not why.

well, its a minor item, but the "why" is that when folks come across this spec 
(eg in searching for TLS specs), and in discussions in various fora, that 
there's a name for ct-capable TLS clients, since not all tls clients will be so 
capable.

<snip>
 >> The differences between the spec and [CrosbyWallach] doesn't seem to be that
 >> large, and so if there aren't more closely matching paper(s) to cite (?), it
 >> may be worth summarizing the differences between the spec and
 >> [CrosbyWallach] e.g. in an appendix.
 >>
 >>
 >>> "commitment" is a term of cryptographic art.
 >>
 >> so it is, but its definitions in the literature seem to vary somewhat
 >> depending on context.  IIUC, the spec uses "commitment" to refer to the hash
 >> labels of intermediate nodes ('interior nodes' in [CrosbyWallach]) as well
 >> as the root hash, yes?
 >>
 >> In S2.1.1, where it says..
 >>
 >>          We prove that the left subtree entries D[0:k] are consistent
 >>    and add a commitment to D[k:n]:
 >>
 >> ..it's not clear just what "add a commitment" means. add it (an
 >> intermediate-node hash?) to the list of hashes that the recursive algorthm
 >> is constructing?
 >>
 >> Overall, I'm finding S2.1.1 pretty difficult to parse and sort out.
 >>
 >> E.g., it isn't clear to me how/why/when the apparently boolean 3d parameter
 >> of SUBPROOF is either true or false, and whether there's an implied "if b
 >> then ... else ..."  in there somewhere.
 >
 > Its reasonably hard to define this thing rigorously, and so I'm not
 > surprised you find it hard to follow - but as I think I've said
 > before, we did try various different phrasings and did not find an
 > easier one. Suggestions welcome.

ok. I suppose clarifying the use of the boolean 3d parameter of SUBPROOF is a 
place to start, tho I'm not sure of its use at this time, so don't feel able to 
suggest text :(      (i haven't grokked the code on this point either..)

 >> I don't know if it would be better (I've compiled it and am poking through
 >> the code). I sorta think pseudo code in an appendix that would generate the
 >> trees in S2.1.3. would be helpful.
 >
 > I suspect this is more relevant to a non experimental RFC -

I spose.

 >  right now
 > I have no evidence that anyone is planning to actually write code
 > other than us - AFAIK, so far everyone who has played with it has used
 > our code.

ok.

<snip>
 >>>> 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?
 >>
 >> well, yes (i prefer the former), but i think it's also important to
 >> explicitly state 0 <= i < n
 >
 > Why? Its weird! its also not generally true - e.g. n=2 and i=1.

ok, what i was getting at is that in the latter statement..

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

..shouldn't the range of "i" also be specified? especially that it's lower bound 
is 0 <= i ?   (i haven't stared at math texts for a while and don't recall 
whether they'd leave "i" only tacitly specified..)

For n=2, k=1, i=0   yes?

<snip>
 >>>>>    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.
 >>
 >> well, the way it's presently said in the spec is (to me) pretty darn hard to
 >> understand.
 >>
 >> which concerns are missed in the suggested reformulation?
 >
 > I said "mixes" :-)

doh :)

 > That is, it mixes the hashing up with the definition of the list.
 > Other than that, I'm OK with the rephrasing.

oh, well, perhaps just saying..

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

..to supplant..

  "D[k1:k2] denotes the length (k2 - k1) list {d(k1), d(k1+1),..., d(k2-1)}"

?

and placing "When (k2 - k1) is 1, a leaf hash is calculated." (or something 
akin) elsewhere appropriate?  (sounds like from your various msgs you might have 
already done the equivalent)

HTH,

=JeffH

---

From: Ben Laurie <[email-masked]>
Date: Tue, 29 Jan 2013 11:16:25 +0000

On 28 January 2013 22:41, =JeffH <[email-masked]> wrote:
> ok, i assume you're referring to section 17.13 "form submission" of HTML
> 4.01, and using the  application/x-www-form-urlencoded  content type, with
> the parameters appended to the url encoded according to S17.13.4 ?

Yes.

> "publish" its chosen MMD value, and log monitors/auditors will want to get
> the MMD value(s), yes?

As I said, not clear on that: seems obvious that the MMD can't just be
fetched from the log.

> well, its a minor item, but the "why" is that when folks come across this
> spec (eg in searching for TLS specs), and in discussions in various fora,
> that there's a name for ct-capable TLS clients, since not all tls clients
> will be so capable.

"Conforms to RFC xxxx"? "Is CT capable"? Not sure the RFC is the place
to decide what people say!

> ok. I suppose clarifying the use of the boolean 3d parameter of SUBPROOF is
> a place to start, tho I'm not sure of its use at this time, so don't feel
> able to suggest text :(      (i haven't grokked the code on this point
> either..)

I don't get you - the use is defined entirely by the algorithm. It
possibly doesn't help that the first step of the algorithm is buried
in text instead of having a line to itself, so I've corrected that.

> ..shouldn't the range of "i" also be specified? especially that it's lower
> bound is 0 <= i ?   (i haven't stared at math texts for a while and don't
> recall whether they'd leave "i" only tacitly specified..)

i is specified entirely by the text (i.e. there is only one i that
satisfies 2^i < n and 2^(i+1) >= n, for all n > 1).

> For n=2, k=1, i=0   yes?

Sorry, yes, you are correct.

>  "D[k1:k2] denotes the length (k2 - k1) list {d(k1), d(k1+1),..., d(k2-1)}"

I did something like this.

> akin) elsewhere appropriate?  (sounds like from your various msgs you might
> have already done the equivalent)

Yes.