> 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(_dot_)Hodges(_at_)kingsmountain(_dot_)com> 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