Re: Signature calculation language

[Jon Callas <[e-mail]>]

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