proposal: signature usage for offline mainkeys (secure policy documents)

[Hauke Laging]

Hello,

until yesterday I considered the capabilities (signing, decrypting) of an 
offline mainkey irrelevant as it is usually never used for these operations 
and thus recommended to create offline mainkeys without explicit capabilities. 
This attitude has just changed. I would like to tell you why. I hope this is a 
new thought and useful to some readers (don't hesitate to let me know :-) ).

As some of you may remember I consider it important for a security 
infrastructure to know the meaning that a user gives its crypto tool(s). I can 
see that someone has e.g. a 2048 bit RSA key but I usually don't know whether 
this is an offline key (used in a highly secure environment only), a key on a 
smartcard or even a key which has been uploaded to a server for e.g. using 
crypto webmail.

AFAIK today there is no standardized way of describing the security and usage 
of keys and signatures. The best you can do is write a signature policy, sign 
it (with limited validity) and put its URL in your signatures (--set-policy-
url). But how can you be sure that the policy document is valid? Think of such 
a document for an insecure key. The document says something like "This key is 
rather insecure". The key gets compromised (without the owner noticing), the 
attacker writes a new document ("This is a very secure smartcard key."), signs 
it and replaces the old one by it.

My previous consideration was that the only solution for this problem was to 
have the others sign not only your key but your policy document, too. This 
has, of course, the serious drawback that is becomes quite hard to change this 
document. Then it came to my mind that offline storage of the mainkey usually 
creates two different levels of crypto actions which the mainky is capable of. 
By allowing a mainkey to sign (and encrypt) you get interesting new 
opportunities.

If the policy document is signed by the offline mainkey (by using 0x12345678! 
instead of 0x12345678) then its signature is very trustworthy. So you could 
create two documents: One describing the signature policy (which may change 
and easily be signed again by the mainkey) and one describing the key security 
which should never be changed (as this usually does not make much sense) and 
gets signed by those who certify the key (at best by their mainkey ;-) ).

On the other hand this offers the possibility of a higher security level for 
encryption thus reducing the need for a second key. But IMHO this introduces a 
serious risk of confusion so I do not generally recommend that.

Besides this possibility which is available by todays's tools I would love to 
see some standard there (for making this information machine readable): A 
simple XML definition and a corresponding set of signature notations which 
allow statements of useful precision about the usage and security of a key.


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/20120715/39a64afa/attachment.pgp>