Protecting IDs at a key signing party

[Hauke Laging]

Am Mittwoch 08 Dezember 2010 22:54:02 schrieb Robert J. Hansen:

> For me, I bring a passport and a driver's license.  If anyone tells me
> "that's not enough for me!", well, okay: it's not enough for them.

That should not be a question of personal attitude but of the signing policy 
for the respective key. As there are different scenarios in real life there 
should be different keys or at least signing descriptions available for 
everyone.

As reading prose policys does not scale well I would like to have a standard 
for that. I have mentioned that on this list before.

The very simple certification level scheme could be extended be e.g. 
standardized notations. There is a IETF reserved notation namespace but there 
aren't any IETF notations yet. I suggest a standard for at least these pieces 
of information:

- key owner has been personally known for x years
- frequent contact with the key owner for x years
- x family members of the key owner have been personally known for y years
- identity has been checked by looking at document of type x
- identity has been checked by electronic means (of type x)
- email address has been checked
- key is on a smartcard
- key has been created on a smartcard with no backup
- key has been created on a smartcard with a secure offline backup only
- main key has been created in a secure environment
- key is intended for usage in an unsecure environment (e.g. Webmail)
- key is intended for usage in a secure environment only
- other keys of this key owner: ... (for better trust calculations)
- key is (not) intended for signing (small / high amount) treaties

The result would be a machine readable signature policy. And you could certify 
any key. GnuPG could be configured how to translate this detailed data into 
the current three levels of checking effort.

Today you have signature policies for some keys. But what are they worth? 
Imagine you have a rather insecure key for spam (filter) protection and the 
like. This key gets compromised. The attacker can easily write a signing 
policy which claims this key to be a high security smartcard key and sign it. 
Worth nothing. Trustworthy signature policies have to be signed by the people 
who sign the key itself, too. This would be achieved if you had a kind of 
signature policy within the signature notations.

The document types should contain both general entries and national 
extentions.

This way an important feature could be added: Signing subkeys. The 
impossibility to do this makes GnuPG incompatible with at least the German law 
for digital signatures (unless the CA would destroy the secret main key and 
give only the subkeys to the customer which is not the idea of GnuPG I think). 
The subkeys would not be signed directly but their fingerprints would become 
signature notations.

A bit off-topic. Sorry. :-)  But I really hope there are a few people out 
there who see the same need...


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/20101208/cd001945/attachment.pgp>