Protecting IDs at a key signing party
mailinglisten at hauke-laging.de
Wed Dec 8 23:35:04 CET 2010
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
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
- 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
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
A bit off-topic. Sorry. :-) But I really hope there are a few people out
there who see the same need...
PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 555 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-users