ietf-smime
[Top] [All Lists]

Re: Encrypted mail in Limbo

2003-01-30 04:36:51

Peter,
Actually I have some doubts about encrypted mail as a mass-
activity in general.  It far too complex to handle.  DOMSEC
would have been much better for the majority of messages.

Anyway, in order to aquire encryption keys in a reasonable
way from somebody you only have (an hopefully working)
e-mail address to, you should be able to search pre-defined
places using CertStore or go through DNS.

But I don't think that this will be a killer due to the privacy
issues, as well as to the fact that the user may have a TTP-
issued certificate.  Therefore I suggest a number of possible
additions:

1. a new URL-type: signed internet mail address (SIMA)
2. a new optional SMTP header: SIMA
3. a new SubjectAltName OtherName: SIMA

Then you have three ways of distributing (indirect) keys, 
automagically in ordinary mail, as explicit URL text in mails etc., 
and automagically through digitally signed messages.

Without any _MAJOR_ improvements in this area, I feel that
encryption certificate lookup will never become mainstream
exactly in the way as encrypted mail is not today.

Anders

----- Original Message ----- 
From: "Peter Gutmann" <pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz>
To: <anders(_dot_)rundgren(_at_)telia(_dot_)com>; 
<ietf-pkix(_at_)imc(_dot_)org>; <ietf-smime(_at_)imc(_dot_)org>; 
<pbaker(_at_)verisign(_dot_)com>; 
<pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz>
Sent: Thursday, January 30, 2003 11:28
Subject: Re: Encrypted mail in Limbo


"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>