email verification as casual checking?

[Daniel Kahn Gillmor]

On 08/22/2014 09:13 AM, Nicolai Josuttis wrote:
> THAT IS, the key server would automatically certify the correctness
> of the association between the key and the email address as casual signing.

as others have noted in this thread, this behavior is what the "PGP
Global Directory" does.

I'm not convinced this service needs to be a keyserver itself: it could
just be a keysigning e-mail service, which sends its certifications back
to the requestor, who then gets to decide what to do with them (upload
them to the public keyservers, keep them local, whatever).  Such a
service could of course remember recent certifications and avoid making
new ones over a given period, so it could not be used to flood the
keyservers.

That is: this sounds like a certification service, not a keyserver
service to me.

I also don't think that such a service should mark its certifications as
"casual signing" -- cert-levels aren't actually useful in today's
environmet, as i've written before:

 https://www.debian-administration.org/users/dkg/weblog/98

if this particular service has a signing policy that just verifies the
e-mail parts but not the full name, then people deciding whether to rely
on its certifications can factor that signing policy into their
considerations.

fwiw, PGP Global Directory certifications are all "generic
certifications" (i checked by looking at Doug Barton's keys on the
public keyserver), which i think is reasonable.

> The big advantage would be to have a simple way to validate
> keys.

well, it could provide some level of validation about *something* about
the keys, for people willing to rely on a set of third-parties and networks.

> The big disadvantage beside some details (such as registering
> additional email addresses) is probably that PGP signatures
> usually sign the owner, not his/her email address,
> if I understood it correctly.

Typical OpenPGP certifications cover a primary key and a User ID.  Since
the User ID is a UTF-8 string, which is (by convention) a human-readable
name with an RFC 822 e-mail address (but can be anything).  Such a
service would clearly need to limit the types of User IDs it certifies
(and never certify user attributes).

I'm not sure i'd want to rely on this service myself, but it doesn't
seem like it would be hard to implement (though some of the anti-DoS
measures might be a bit tricky), and having a reasonably-implemented
service like this in existence wouldn't cause me any heartburn.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140823/49811db9/attachment.sig>