Series of minor questions about OpenPGP 3

[David Shaw]

On Jan 27, 2009, at 7:46 AM, Peter Thomas wrote:

> Hi again.
>
> Ok this is a first bunch of questions on signatures (again both
> specific for gnupg but perhaps also common for OpenPGP).
> Would be glad if someone could help me with answering these (David?!  
> xD).
>
> 1) For the 0x11 signature the RFC says "...has not done any
> verification of the claim that ..." which as far as I understand means
> "The signer simply signed the key without checking the keyholders
> identity".

Pretty much, yes.  It's "the keyholder claims to be X and I believe  
them, but didn't check."

> Does gpg include this signature type in its trust-calculations or is
> it simply ignored (no matter whether I directly signed another key
> with a 0x11 or whether its "in the middle" of a trust-path between me
> and someone else?

In GPG, by default, it is simply ignored.  A 0x11 signature has no  
value anywhere in a trust calculation.  You can change the default if  
you like (or even make it more strict, by, say, ignoring 0x12  
signatures as well) with the --min-cert-level option.

> And if so, is this generally claimed by the RFC? I mean will every
> implementation behave like this (ignoring 0x11s) when it follows the
> RFC?

The RFC is really a file format document more so than a "how to use  
trust" document.  Every now and then it is suggested that a trust  
document or something like an OpenPGP best practices document should  
be written, but nobody has taken up the suggestion yet.  So the RFC  
that we have (4880) does not specify or deny this behavior: it simply  
lists the signature types for reference.  So all that said, I don't  
know if any other products ignore 0x11 signatures.  Keep in mind that  
few products draw any distinction between 0x10, 0x11, 0x12, and 0x13  
at all.  They treat all of the types identically and issue only 0x10  
signatures.

> 2) Why are the 0x19 signatures only used as embedded signatures? I
> mean wouldn't it be the same to simply add them as another "top level"
> signature packet?

0x19 lives inside a signature subpacket on a signature that the 0x19  
is making a statement about.  This makes it easy to find (it's always  
on the subkey binding signature), and makes it naturally travel along  
with the subkey that it is issued by (if you delete the subkey, the  
0x19 vanishes along with it).  Semantically, it could be a top-level  
signature.

> 3) I've understood why we need a "backsignature" (the 0x19) for
> signature subkeys, but why don't we need one for encryption subkeys?

The purpose of the back signature is to prevent "stealing" a signature  
subkey.  For example, say Alice has a key with a signing subkey (but  
no back signature).  She signs a document with her subkey and later  
tries to prove that it is her work.  Baker, however, takes Alice's  
subkey and attaches it to his key.  He can now try and prove that it  
is his work.  To be sure, he doesn't have the passphrase for the key  
and can't make more signatures, but he can verify signatures, and  
verifying signatures would look like they were verified by  
"his" (really Alice's) subkey.

One fix for this attack would be to ask both Alice and Baker to sign  
something for you as only Alice could, but back signatures avoids the  
whole shebang by having the subkey sign the primary key, making it  
obvious which primary "owns" the subkey.

This attack isn't meaningful for encryption subkeys.  Baker can choose  
to steal Alice's encryption subkey, but without the passphrase he  
can't decrypt anything with it, and he can't claim anything in  
particular after he has stolen it.  In any event, you couldn't make a  
back signature with, say, an Elgamal encryption-only key.

> 4) I've looked at the different revocation signature types. It seems
> that it's not possible to revoke 0x00, 0x01, 0x02, 0x40 and 0x50
> signature types?
> Is this desired? I mean I understand that these signature types can
> also be applied to casual data (and not just keys) but one could think
> of "revocation servers" like keyservers that could be asked whether
> some signature is still considered to be valid.

There is no current means to do this in the standard.  There is no  
reason for this beyond that nobody, as yet, has needed the ability.

> 5) I've looked at the layout of v4 signatures, which lead me to two  
> questions:
> a) What does gnupg put in this unhashed area. I mean which subpacket
> types (at maximum).

The basic rule for this is put it in the hashed area unless there is a  
reason not to.  The only subpackets that can safely live in the  
unhashed area are those where, if they are modified, the security  
semantics of the signature do not change, or the signature is broken.   
Note that some programs put some things in one area that other  
programs would put in the other.  All that said, GPG puts the Issuer  
and Signature subpackets in the unhashed area.  These are the two  
subpackets that are naturally tamper-proof.  Sure, an attacker can  
tamper with them - but all they would accomplish is make the signature  
not work (either because the signing key could not be found if they  
mess with the Issuer, or invalidate the backsig for the Signature).

> b) This two octet field containing the left 16 bits of the signed
> hash, doesn't this allow some kind of DoS attack? In the sense that
> someone that captures and modifies the OpenPGP message can change
> these two octets and an implementation that looks at these would
> immediately say "invalid signature"?

Yes and no.  Sure, if someone has the ability to modify the message  
they can mangle the 16 bit "quick check" field.  But then, if they  
have the ability to modify the message, they can mangle anything they  
like.  Why restrain themselves to those particular 16 bits?  Mangling  
- of any part of a signature - should cause the signature to be invalid.

David