Series of minor questions about OpenPGP 3
dshaw at jabberwocky.com
Tue Jan 27 16:48:09 CET 2009
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?!
> 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
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
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
> 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
> 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
> 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.
More information about the Gnupg-users