ietf-openpgp
[Top] [All Lists]

Re: Nesting different signatures

1998-03-26 16:09:38
tzeruch(_at_)ceddec(_dot_)com writes:
On Thu, 26 Mar 1998, Hal Finney wrote:
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.

Actually, it is more complicated than this, and we need to clarify how
this works in the spec.  What it says now, in section 5.2.4, is:

   The signature data is simple to compute for document signatures (types
   0x00 and 0x01), for which the document itself is the data.  For
   standalone signatures, this is a null string.

While this is true, "the document itself" is not clearly defined in the
context of the OP grammar.

What actually happens is that the signed portion consists of an OP
message, as described in section 10.2.  The data which is actually hashed
depends on the nature of the signed OP message.

There are two steps: first identifying what OP message is signed, and
then determining what part of that OP message is hashed.

In a One-Pass Signed Message, if the nested flag is set in the One-Pass
Signature Packet, then the OP message which is sandwiched between the
one-pass packet and the signature packet is what is signed.  If the
nested flag is not set, the sandwiched OP message MUST be another
One-Pass Signed Message.  In that case the signed data of the outer
OPSM is the same as the signed data of the inner OPSM.

[We could change the grammar in 10.2 to distinguish between the two
kinds of OPSM packets, nested and non-nested, in order to clarify what
is legal here.]

In a regular Signed Message, the signed data is the OP message which
follows the signature packet.

Once we have identified the signed OP message, the hashing rules are
as follows.  If the signed portion is anything but a Literal Message,
then the entire signed OP message is hashed, including packet headers.
However, if the signed portion is a Literal Message, only the "literal
data" portion of the literal packet body is hashed.  The literal packet
headers are not hashed, nor are the formatting octet, filename, and
creation time fields within the literal packet body.

The part about one-pass packets is new to PGP 5.X, but the special
behavior with respect to hashing literal messages goes back to PGP 2.X.

I didn't understand the correct sense of the "nest" flag until now.

Actually, I had it backwards in my earlier message.  If the nest flag
is set in the one-pass packet, that means the signed portion starts with
the very next packet.  If the flag is not set, the next packet must be
another one-pass packet, and the outer signature's signed portion is
the same as that of the inner signature.

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.

No, setting the nest byte means you DO want the signature to be on the
whole following message.  I agree though that the terminology is a bit
confusing.

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. 

This is implied by the grammar in 10.2.  Each one-pass packet is paired
with a signature packet.  Constructing more elaborate messages using
this rule will cause ABCDE one-pass packets to automatically have EDCBA
sig packets at the end.

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.

We may want to add a note to the One-Pass Signed Message grammar in
10.2 to clarify that the end signature must be by the same key as the
one-pass packet.  That will insure that they can be paired up properly.

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.

As long as the grammar is unambiguous there should not be problems.
I think all the cases you have given here are legal and handled by
PGP 5.X.

Hal

<Prev in Thread] Current Thread [Next in Thread>