Series of minor questions about OpenPGP 3

[Peter Thomas]

On Tue, Jan 27, 2009 at 4:48 PM, David Shaw <dshaw at jabberwocky.com> wrote:
> 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.
Ok,.. so this means basically that I, as an end user, must expect that
some (stupid) implementation may take my 0x11 and fully trusts it,
right?
And the "descriptions" from chapter 5.2.1 on page 20 are just
"informal" and not strictly normative, right?
(If so, then perhaps this should be added as a kind of "rationale" in
a future revision of the RFC.)
btw: As you're one of the RFC authors: If the meaning of the 0x10-0x13
will ever be specified more normatively and strictly it should be
noted, that the 0x10-0x12 (especially the 0x11) may no longer make
sense to be used as self-signature (which seems to be allowed right
now) :-)

>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.
Ok,.. that's not a question but: I'm very sad about this. Would like
to see that people have their policies and give 0x10-0x13 according to
their personal policy :-)


> 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.
That's what I wanted to know xD


> 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.
Lol I'm so stupid! It's so obvious...


>> 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.
Perhaps this can be suggested in a future version of the RFC? Not that
I'd need it, but I think it's not the worst idea, and we also have
already some other stuff (like signature types) that are probably
unused.


>> 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.
Yes...

> 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.
The first one, Issuer (16), is it only kind of a hint? I mean the
signing key follows from that hashed/and encrypted data and not from
the Issuer subpacket right?
If so why does it exist? To speed up validation?

And which one did you mean with the second?


> 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).
Yeah, that's clear,.. so all an attacker could do is some kind of
denial of service or better said, denial of validation,.. but he could
do this in any case.


> 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.
Yeah,.. you are right,... it's actually obvious but sometimes one
doesn't see those things when writing about.
Ok so I assume the Issuer (16) subpacket is a hint that tells which
public key should be used for verification, and the 16 bits are the 16
leftmost bits.
So to speed up things, an implementation uses the public key from the
Issuer subpacket for calculations, makes a first check after the 16
bits of the signature hash, and only if these are equal, checks the
remaining ones.
Is this correct?


Thanks again so far :-)