Best practice for periodic key change?

[Hauke Laging]

Am Sonntag, 8. Mai 2011, 14:50:36 schrieb MFPA:
> Mainly the key's owner, but could also protect others from relying on
> signatures from a compromised key for which they have not received a
> revocation certificate.

Right. The problem: Protection you don't know of. So seriously this additional 
protection will not be taken into account (unless you happen to have more 
information about the key handling).


> Could a modified version of "HOW TO MIGRATE A (SUB)KEY INTO A NEW KEY"
> http://atom.smasher.org/gpg/gpg-migrate.txt be used to substitute one
> of your subkeys with another of the same type and size? Or what would
> be the implications of an attacker migrating your subkeys to another
> master key?

That would be useless. The result would be that the attacked user (if he had 
imported the master key with the migrated subkey) would believe that a 
signature has been made by the attacker instead of the person whom he has 
stolen the key from. If an attacker wants somebody to believe that he has made 
a signature than he can trivially make one. No need to steal keys for that.

When encrypting  there would be no difference if you don't address the subkey 
directly but the main key or one of the UIDs.


> > And as I am dreaming: With a notation for identifying
> > all subkeys (thus extending a certification from UIDs
> > to subkeys) the first hurdle for getting GnuPG /
> > OpenPGP compliant with German signature law (at least
> > on the  theoretical level) would be taken.
> 
> Would that mean a certification of a particular UID on a key was not
> valid in conjunction with subkeys that were not present on the copy of
> the key you signed?

Yes. That were not present or not signed. Like with UIDs.


> If so, wouldn't that discourage people from using
> short-life subkeys because they would need to obtain signatures on new
> ones? Or have I misunderstood?

That is correct but there would be no need for short-life subkeys any more. 
The problem is that German / EU signature law requires a legally fully trusted 
key to be created in hardware which he can never be read from. So the so 
called qualified signatures can be made with smartcards only. Thus the 
certification authorities are not allowed so certify today's mainkeys because 
you can create valid subkeys outside smartcards with them without the CA being 
part of that.

IMHO there are only two possibilities for making (a new version of) OpenPGP 
signature law compatible:

a) The CA creates a mainkey and subkeys. The mainkey is destroyed immediately 
afterwards. That might be legally acceptable but has not much in common with 
PGP any more.

b) It is made possible to prevent the transfer of the validity of a mainkey to 
a subkey. Either my disallowing subkeys at all (in the certification) or by 
requiring explicit certifications for subkeys. When certifying a key you would 
have to decide whether you make a certification of the old type (for the 
mainkey and then the mainkey is allowed to do everything) or of the new one. 
This new type of certification would not be allowed to be backward compatible. 
if it was then old software might regard an explicit subkey certification as a 
normal one and thus accept subkeys without explicit certification.


Hauke
-- 
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 555 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20110509/c0e52551/attachment.pgp>