"No-Keyserver" (and other) flags on keys

[John Clizbe]

Dan Mahoney, System Admin wrote:

> The ones I've seen have enough awareness of what's in a key to pull a key 
> apart and determine who's signed it, when, and when it's expired.  Is 
> there more than that to read these bits?  Again:step zero may be to 
> determine what the internal format is.

That's no more than reading base 64 in, convertingh it to binary and following
the packet formats. The internal format is well documented in RFC 4880.

That is a far cry from the keyservers being able to do verifications

> However, you raise another question: How does a keyserver know who is 
> uploading the key?

At present, they don't. The owner would need to sign the submission to certify
he is doing the submission, hence the need for crypto.

> (Note that this doesn't apply to my original question, since that was 
> simply a "keyservers should throw this away" flag, where a user might 
> choose to publish on his website, his .plan file, on his business cards, 
> in DNS, or via LDAP or S/Mime autodiscovery.)

That step would also need crypto as the keyserver would need to verify the
signature on the packet containing the flag.
-- 
John P. Clizbe                      Inet: John (a) GingerBear DAWT net
You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net  or
     mailto:pgp-public-keys at gingerbear.net?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 499 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20100627/35124f6c/attachment.pgp>