On Thu, 26 Mar 1998, Hal Finney wrote:
tzeruch(_at_)ceddec(_dot_)com writes:
This is not a legal OP message, according to the grammar in section 10.2.
Signatures can only go at the end if there is a 1psig packet at the
beginning, and there cannot be two OP messages between the 1psig and sig,
only one.
But it also says
OPSM := OPSK, opM, SP
Abbreviations for: One Pass Signature Message pacKet. oPENpGP
The implication is that the SP is over the opM. When nesting this would
not be true, the signature can be over something inside the opM.
Generalizing this to the one pass signatures, we allow any legal PGP
message to be signed by putting a 1pass packet in front of it and a
signature packet behind it.
However at the same time the "nested" flag was introduced in the 1pass
packet. This is intended to allow multiple signatures to be on the
same data. You could not do that with the old PGP 2.X format, as each
signature packet applied to the entire following message.
If you have a case like:
1psig(k1,nest),1psig(k2,nonest),literal,sig(k2),sig(k1)
then both the signatures by k1 and k2 are on the literal data, or more
generally, on whatever OP message lies between the last 1psig and the
matching sig packet. With the opposite setting for the nest flag:
1psig(k1,nonest),1psig(k2,nonest),literal,sig(k2),sig(k1)
then the signature by k1 is on the three-packet signed message by k2.
(Note that I reversed the order of the sig packets from your example,
so that they are paired appropriately.)
I didn't understand the correct sense of the "nest" flag until now.
Setting the nest byte means that you *DON'T* want the signature to be on
the whole following message which I would describe as NOT nesting.
Another point which I see here, but couldn't find stated clearly is that
things should (must?) be positionally nested, i.e. 1psigs in order of
ABCDE would have sigs at the end in EDCBA order.
My interest here is to prevent a complex interpretation of what is part or
not part of what is being signed. There should be no combinations of nest
and nonest that are ambiguous. And I can see there can be if the end sigs
were not in reverse order of the 1pass sigs.
Assuming reverse order, any adjacent pair must be one of the following:
BeginSig(A);BeginSig(B);{data};EndSig(B);EndSig(A);
or
BeginSig(A);{BeginSig(B);{data};EndSig(B);};EndSig(A);
Something like BS(A){BS(B);{data};ES(A) [or ES[X]!] is a nightmare.
Another fun, but maybe legal is mixing normal and 1 pass signatures.
1PS(A);S(B);literal;S(A) - syntactically legal if I understand.
1PS(A,SHA);S(A,MD5);literal;S(A,SHA) - also legal but more fun,
or even:
1PS(A,SHA);(S(A,SHA on literal);literal);S(A,SHA on first S and literal)
Signed Message = OP message, Signed
Signed message is a valid OP Message.
OPSM = 1PSP, OP Message, SP;
Someone should say NO to these types of things.
I believe you are suggesting eliminating the nest flag and assuming that
we always use the first interpretation, where multiple 1psig packets
all apply to the same signed data. Then, when we want to express the
second, we would do:
1psig(k1), literal( 1psig(k2),literal,sig(k2) ), sig(k1)
wrapping the signed message by k2 in a literal packet.
Yes,
The main problem I see is that the unwrapping process described above
would not work smoothly. We would either stop when we see the literal
packet, and not report the k2 signature, or else we would have to have
a policy of always peeking inside literal packets and seeing if the data
looks like PGP data, and perhaps proceeding to decode it. The literal
packets then lose their useful function as a known stopping point.
Or the nesting flag belongs in the literal packet (you already define text
and binary and have 254 other values to choose from, maybe 'p').
Derek Atkins was the designer of the one-pass signature packets, back
before PGP, Inc. existed. He told me that he was not completely satisfied
with the design, that he thought the grammar still had some ambiguities,
and that a three state nesting flag was necessary to cover all possible
cases. I have never gone back and looked into this area thoroughly.
Before finishing the official Open PGP spec, this should be done.
--- reply to tzeruch - at - ceddec - dot - com ---