[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Signature calculation language
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."
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
The signature is actually calculated over both the primary key and
subkey packets, although here it says it is not calcualted over any
(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
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."