On 5 Oct 2005, at 2:11 PM, Hal Finney wrote:
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."
Added.
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...")
Done.
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.
Done.
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.
Done.
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."
Done.
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."
Done.
Jon