On 28 January 2013 22:41, =JeffH <Jeff.Hodges@xxxxxxxxxxxxxxxxx> wrote:
>> 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 <Jeff.Hodges@xxxxxxxxxxxxxxxxx> 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 ?
Yes.
>>>>> 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?
As I said, not clear on that: seems obvious that the MMD can't just be
fetched from the log.
>>>>> 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.
"Conforms to RFC xxxx"? "Is CT capable"? Not sure the RFC is the place
to decide what people say!
> <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 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.
> <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..)
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.
>
>
> <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)}"
>
> ?
I did something like this.
> 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)
Yes.
>
>
> HTH,
>
> =JeffH
>
>