Signature calculation language

[[e-mail] ("Hal Finney")]

Some of the language in the draft about signature calculations is
confusing and misleading.  The brief descriptions in 5.2.1 Signature
Types are contradicted by 5.2.4 Computing Signatures.

We should make clear that 5.2.4 is authoritative.  I suggest that we add
to the beginning of 5.2.1, "See section 5.2.4 for detailed information
on how to compute and verify signatures of each type."

Particular problems:

    0x18: Subkey Binding Signature
        This signature is a statement by the top-level signing key that
        indicates that it owns the subkey. This signature is calculated
        directly on the subkey itself, not on any User ID or other
        packets. A signature that binds a signing subkey also has an
        embedded signature subpacket in this binding signature which
        contains a 0x19 signature made by the signing subkey on the
        primary key.

The signature is actually calculated over both the primary key and
subkey packets, although here it says it is not calcualted over any
other packets.

(A separate issue is that the last sentence here should have a SHOULD:
"A signature that binds a signing subkey SHOULD have an embedded...")

    0x19 Primary Key Binding Signature
        This signature is a statement by a signing subkey, indicating
        that it is owned by the primary key.  This signature is
        calculated directly on the primary key itself, and not on any
        User ID or other packets.

Same issue here, the signature is calculated over both the primary key
and the subkey packets.

    0x28: Subkey revocation signature
        The signature is calculated directly on the subkey being
        revoked.  A revoked subkey is not to be used.  Only revocation
        signatures by the top-level signature key that is bound to this
        subkey, or by an authorized revocation key, should be considered
        valid revocation signatures.

This is actually correct, I guess (I don't think PGP supports subpacket
revocation signatures).  According to 5.2.4 the hash is over just the
subkey packet and does not include the primary key packet, unlike ordinary
subkey signatures.  That seems a little inconsistent to me - is this how
other people have implemented it?

A couple of comments on section 5.2.4:

    When a signature is made over a signature packet, the hash data
    starts with the octet 0x88, followed by the four-octet length of the
    signature, and then the body of the signature packet. The unhashed
    subpacket data of the signature packet being hashed is not included
    in the hash and the unhashed subpacket data length value is set to
    zero. (Note that this is an old-style packet header for a signature
    packet with the length-of-length set to zero).

The parenthetical note at the end should go after the first sentence.

For consistency with other descriptions in this section, we should refer
explicitly here to the Third-Party Confirmation Signature, type 0x50,
which I think is the only one for which this description applies.

One thing that is missing in these two sections is a clear statement that
certificate revocation signatures are calculated over the same data as the
certificate being revoked.  5.2.1 just says:

    0x30: Certification revocation signature
        This signature revokes an earlier User ID certification
        signature (signature class 0x10 through 0x13) or direct-key
        signature (0x1F). It should be issued by the same key that
        issued the revoked signature or an authorized revocation key.
        The signature should have a later creation date than the
        signature it revokes.

with no comments about what it is computed over, and 5.2.4 doesn't clearly
describe this case either.  We could change that last sentence to say,
"The signature is computed over the same data as the certificate that
it revokes, and should have a later creation date than that certificate."

I am also not in love with the classic description of document signatures
in 5.2.4:

    The signature data is simple to compute for document signatures
    (types 0x00 and 0x01), for which the document itself is the data.

First, it is presumptuous and uninformative to say something is simple.
"The document itself is the data" has a certain Zen koan quality but does
not plainly say what it means.  And this fails to distinguish between
text and binary signatures; for text signatures, the document itself is
not the (hashed) data, but rather the canonicalized document.

How about this:

"For binary document signatures (type 0x00), the document data is hashed
directly.  For text document signatures (type 0x01), the document is
canonicalized by converting line endings to <CR><LF>, and the resulting
data is hashed."

Hal Finney