Subject: Public-key distribution via HTTP

From: [email-masked] (Peter Gutmann)
Date: Sat, 12 Jan 2008 21:17:40 +1300

[CC'd to various lists who might be interested]

Someone recently asked on a security list whether there was a simple way of
putting your public key on a web server based on "a set of goals, hopefully
sufficiently unambitious, so one knows what one wants to do very precisely.
Given those, I suspect a decent spec replacing hundreds of pages of currently
'standard' and useless mechanism could be crafted in about 10 to 30 pages)".
My response was "You've just described RFC 4387 :-)".  The list reaction was
that no-one had known until then that this document even existed, so I'm
posting this to a couple of lists where people might find it useful.

Don't be mislead by the title (http://www.ietf.org/rfc/rfc4387.txt), it was
published under the auspices of PKIX but it's really "a simple, fairly
universal means of publishing your public key via HTTP".  The CACert folks
have set up a Wiki page to cover implementation info, feedback, and comments:
http://wiki.cacert.org/wiki/RFC4387.

(Please, no religious arguments over this: If you think it's useful, implement
it.  If not, ignore it).

Peter.

---

From: "Timothy J. Miller" <[email-masked]>
Date: Mon, 14 Jan 2008 08:27:50 -0600

> (Please, no religious arguments over this: If you think it's  

Peter--

Very timely; we were just discussing something essentially like this  
around my office last week.  I see you've got cryptlib support, but  
are there any other implementations in the pipeline?

-- Tim

---

From: Jon Callas <[email-masked]>
Date: Fri, 18 Jan 2008 14:48:21 -0800

> http://wiki.cacert.org/wiki/RFC4387.

I like it.

The only complaint that I have is that the OpenPGP attributes are a  
bit behind the times. I would like to see it updated for 4880 and  
generalized. I think there are some similar issues for X.509, too.

(Actual technical details -- a key fingerprint there is defined to be  
a binary 160 bits. It ought to be a string because we very well may  
come up with a generic way to compute a fingerprint with an arbitrary  
hash. Given that a fingerprint in this context is really just a  
database retrieval handle (note the way I skillfully avoid the word  
"key"), having it be just text is a good thing. Also, in 4880, we  
deprecate the old-style keys. In the new-style keys, a key ID is just  
a truncation of a fingerprint.)

	Jon