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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]