Standards and PGP wraper
D.M.Pick at qmw.ac.uk
Wed Nov 11 18:54:44 CET 1998
> >>>>> "dp" == David Pick
> >>>>> "Re: Standards and PGP wraper "
> >>>>> Wed, 11 Nov 1998 11:13:53 +0000
> >> >>>>> "dp1" == David Pick "Re: Standards and PGP wraper "
> >> >>>>> Tue, 10 Nov 1998 18:37:41 +0000
> >> Is there a problem with using a sign-only key for normal
> >> signatures and using the signing key of a sign-and-encrypt pair
> >> only in conjunction with encrypting?
> dp> I'm not sure I understand you here. What do you mean by "using
> dp> the signing key of a sign-and-encrypt pair only in conjunction
> dp> with encrypting"? Surely, when encrypting you'd use the
> dp> encryption key of the sign-and-encrypt pair and not touch the
> dp> signing key. (If by sign-and-encrypt-pair you mean a sign-only
> dp> key and an encrypt- only subkey.)
> I mean to do signing alone with a sign-only key and use the sign part
> of the sign+encrypt combo when doing sign and encrypt.
Ah. I've seen something like this as well, but in the case I saw it
was a sign-only key for signing *keys* and a sign-and-encrypt key
for signing (and decrypting) messages.
> Isn't the motivation of signature-only keys served this way?
In one way, but this isn't where I started. I started by wanting to
be able (but only if forced by a search warrant) to be able to
reveal my secret decryption key *without* compromising my
signature key(s). Obviously I would not need to be able to reveal
a secret signature-only key, but when the signature and decryption
keys are bound together by a key/subkey relationship I can't
reveal (either) one without the other because both keys have the
If my machine has been either siezed or an disc image has been taken, I
cannot reveal the passphrase to one of the bound keys without revealing
the other. If the bound pair of secret keys could have different
passphrases I could reveal one without the other. Or if I could
export one without the other I could produce a subkey only with
no passphrase. But I can't do either. Not with PGP5 either (as far
as I can tell).
> dp> Certainly it's possible to set up two top-level keys and use
> dp> one (probably sign-only) for signing, and the other (just
> dp> possibly encrypt-only) for encryption (and decryption!).
> dp> But it's a lot less convenient because they look like two
> dp> different keys to things like keyservers, import and export
> dp> operations, and the like. And that can lead to confusions
> dp> especially with less experienced users of PGP or GnuPG, they
> dp> mightend up with only one of my keys on their keyring because
> dp> they don't realise there's two of them.
> dp> And it also probably forces me to tell my mailer that I always
> dp> want to select the key to use for any operation because it
> dp> won't have the ability to set *two* different keys as the
> dp> defaults for the two different types of operation.
> Teach your mailer new tricks. Easy for Emacs mailers. :-)
Or TCL/Tk mailers.
> I see a number of people with sign-only keys apart from their
> sign+encrypt keys on the servers.
Yes, but are tey used as I described above or not.
> A single one size fits all key seems to be a thing of the past.
But it need not be - the OpenPGP standard (section 22.214.171.124) allows
for keys to be flagged to say that:
0x01 - Key can be used for certifying (signing) other keys
0x02 - Key can be used for signing data
0x04 - Key can be used for encrypting communications
0x08 - Key can be used for encrypting data storage
0x10 - Key (secret) may have been split by a secret-sharing mechanism
0x80 - Key (secret) my be in the possesion of more than one person
(probably for corporate keys)
or any combination of the flags.
Now, GnuPG doesn't handle these flags at the moment, even if present;
but comments in the code indicate it *might* in due course. The idea
would be that the set of bound (sub)keys would be searched to find
the (sub)key with the appropriate flags for the operation to be
performed (and then the passphrase would be got from a cache or
by prompting the user).
So individual keys can still be bound together and handled as a
single entity as far as distribution and key-servers are concerned
but different keys used for different purposes (perhaps different
lengths, &c, &c).
> I agree it is inconvenient.
D.M.Pick at qmw.ac.uk
More information about the Gnupg-devel