|
Re: LC comments on draft-laurie-pki-sunlight-05 - "acceptable root certificates" ?
2013-01-29 05:16:44
On 28 January 2013 22:41, =JeffH
<Jeff(_dot_)Hodges(_at_)kingsmountain(_dot_)com> 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(_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 ?
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
|
|