G'day all.
dontspam-tzeruch(_at_)ceddec(_dot_)com wrote:
Interpretation 1 1{2,3{lit}3,2}1, i.e. sigs in reverse order of 1pass
headers is the proper one. Someone check the syntax again.
The syntax doesn't say that. As section 10.2 currently reads,
{1pass-1 1pass-2 {lit} sig-1 sig-2} is a valid sequence SYNTACTICALLY,
since the syntax doesn't say that the one-pass packet and trailing
signature packet correspond to the same signature. The semantics (see
section 5.4) don't help, because they only say that the signature packet
corresponding to a one-pass packet should be "at the end of the message"
without saying where.
The nesting is important. For a one-pass implementation, it makes it hard
if you have to check every onepass to see if it was NESTED - see the
discussion of the nested octed in 1pass sig header packets. That is the
major headache since only nonnested signatures could be moved around
anyway. The moment the signatures are nested (i.e this signature includes
the following one-pass packet through the signature at the end), order is
critical.
Not necessarily. You collect one-pass packets, compute all signatures
as you process the literal data, then as you hit signature packets,
search through the one-pass packets that you saw earlier to see what
matches, first by key id/algorithms, and in the case of a tie, by testing
the signature is actually valid or not. Yes, performance is slightly
degraded, but only in the case of duplicate key ids, which we expect
to be rare.
I'm perfectly happy with either semantics (pure nesting or free ordering),
but the spec at the moment only hints at one without ruling out the other.
If it is as critical as you suggest (and I'm not convinced that it is
based on my own private implementation in the works, though I agree it
would certainly make things easier), the spec should make the situation
clear.
I suggest adding a sentence to the end of section 5.4 such as:
Note that because multiple one-pass signatures applied to the one
message are nested, the signature packets which follow the message
should appear in reverse order to the one-pass signature packets
which declare them.
I'm not happy with my wording, but that should be the sense of it.
Syntactically, it is similar to a do { ... } while(...); in C - the do
says to look for a while.
Using the programming language analogy (I'm actually a compiler person by
trade, not a cryptographer), the hole which needs patching in the spec is
similar to "Duff's device". For those who are unfamiliar, XJ311 allows
the following C syntax:
switch (...) {
for (...;...;...) {
case ...: ...
default: ...
}
}
Many otherwise compliant implementations broke on this because nobody
realised that it was correct ANSI C.
And if you do a onepass implementation like I do (the whole reason for
having 1pass sig headers), it works better if you can create a stack and
simply note the nesting level, then pop each context off the stack as its
corresponding signature appears.
I agree that this is a neat implementation, but I have this feeling that
someone, based on the current spec, will produce the "same order" sequence
(as opposed to the "reverse order" sequence) and assume it's valid.
Further, you might have to test more than one signature - keyids aren't
guarnteed to be unique.
You may have to test more than one signature anyway, since you could have
multiple keys with the same ids on your public key ring.
Cheers,
Andrew Bromage