ietf-smime
[Top] [All Lists]

Re: Encrypted mail in Limbo

2003-01-30 03:34:34

"Anders Rundgren" <anders(_dot_)rundgren(_at_)telia(_dot_)com> writes:

As you probably have noticed, "authenticated" URLs are very common in many
places like for verifying e-mail addresses, often in connection to a certain
registration event.

In order to use other peoples' public keys for e-mail encryption, I claim
that none of the proposed systems [1] work well except in very local (or very
open) places due to privacy issues [2].

The problem is how to distribute "semi-secret" information in a simple way.
It seems like a signed mail-address MIME-type could be required for out-of-
band distribution using a client "click" only.

 566655fe76adr5fyyeed655:bob(_at_)bobcorp(_dot_)test

Oh, I see what you mean now.  Hmm, I thought I had something in the text about
people using the HTTP-access thing as a static URL to identify a cert, but I
can't find any trace of it.  What I mean here is that a CA or helpdesk could
mail a user their cert URL (say certificates.blah.com/search.cgi?email=
luser%40blah.com) and all they have to do is click on it and they're done,
rather than hunt around some CA's web pages for it.  Since every browser and
most mail software can do an HTTP GET, this gets them their cert
automatically.  What you're proposing could easily go in the implementation
notes as another suggested way to do things, it's a nice variation on the
mailed-URL idea.  Or you could do your own RFC if you preferred that.  

I assume what you're proposing is that the user gets told to fetch:

  certificates.blah.com/search.cgi?x-certMAC=qwertyuiop

(using the 'x-' extension mechanism) by the CA, and the CA can map that to the
required cert, thus providing the privacy/authenticated-URL feature.  Or:

  certificates.blah.com/search.cgi?x-encryptedCertID=qwertyuiop

That's a cool idea, thanks for suggesting it.

Peter.

<Prev in Thread] Current Thread [Next in Thread>