Keytypes and changing them

[David Shaw]

On Tue, Nov 08, 2005 at 11:41:43PM +0100, Christoph Anton Mitterer wrote:
> David Shaw wrote:
> 
> >If such a feature existed in GnuPG, yes.
> >
> >David
> > 
> >
> Uhm,.. I rethought the whole thing,... and I came to the reason that I 
> gave up too fast ;-)
> 
> Ok,.. you told me that the disadvantage of C-only keys would be that you 
> can't response to challenges. Is this the only reason?
> As far as I know a challenge/response is used by some users to verify 
> the email of an UID before they sign it. But lots of people do not 
> validate this, because they think it wouldn make sense at all. E.g. if 
> someone uses some freemail address he could lose the address after 
> validation because the provider stops his service. So signing the eMail 
> as part of an UID does not really secure that the address is under the 
> controll of the keyholder, does it?

That is not how email challenges work.  If someone loses their email
address, the signature is effectively invalid.  That's a feature, not
a flaw.  When you sign an email address, you are certifying that it is
valid at that point.  Obviously you can't certify it as valid forever.

> The only solution (in my opinion) are services like PGP Global Directory 
> Key or so,...
> But I think it is not so important to secure if the email is under 
> controll of the keyowner. The worst thing that could happen is, that an 
> encrypted message isn't received by the (private)-key owner, because the 
> email is wrong. But this can even happen when the email is correct (e.g. 
> if someone controlls part of the network).
> What it all comes down to is: In my opinion - and correct me if I'm 
> wrong - validating the email once does not make much sense. The only 
> good alternative is some service like PGP Global Directory Key.
> 
> What are the advantages of using C-only keys?
> Uhm,.. inm y opinion the stanard intends using C-only keys, if not they 
> would have created only the S-flag, that stands for both, signing and 
> certification.
> But they created the following flags:
> 
> 0x01 - This key may be used to certify other keys.
> 0x02 - This key may be used to sign data.
> 0x04 - This key may be used to encrypt communications.
> 0x08 - This key may be used to encrypt storage.
> 0x10 - The private component of this key may have been split by a 
> secret-sharing mechanism.
> 0x80 - The private component of this key may be in the possession of more 
> than one person.

Isn't this really saying you want to use a C-only key because it is
possible to use it?  I don't see you presenting a reason to use them
aside from "the standard has them, and since they exist in the
standard, clearly they're supposed to be used".  Lots of things are
possible, but not necessarily useful.  C-only keys are possible, but
not viable in the real world.

Note that it's also possible to make a CS Elgamal-E key.  It's utterly
meaningless, but physically possible to create.  Not every bit pattern
is useful.

> Another advantage is perhaps, that a C-only key shows other users that 
> the key is perhaps used in a more secure way (because it's not used for 
> signing plain data).

It doesn't say this.  You could make a CS key, sign some data, then
flip it to a C-only key.  The other user can infer exactly nothing
about the past usage of a CS key compared to a C key.

David