Subject: Re: S/MIME key distribution proposal

From: [email-masked] (Peter Gutmann)
Date: Fri, 23 Nov 2007 21:53:17 +1300

[Replying to several messages at once]

"Tony Capel" <[email-masked]> writes:

>and also recommended to include current CRL (especially for parties who have
>not gotten around to making them available publicly!)

That's *way* outside the scope of the proposal.  The point is that if the user
has an email key then chances are the MUA will already have it available,
since it needs to use it to process incoming mail.  In that case it's a
relatively trivial step to send it out in response to a "gimme your key"
request.  Things like CRLs are an entirely different matter, you go to a CA
for those (or wherever you choose to get them from).

Conversely, if you want [email-masked]'s public key, the best way to get it
is to go straight to the horse's moutn and ask [email-masked], or in this
case a proxy, his MUA.

Peter Sylvester <[email-masked]> writes:

>One has to think a bit what to do if a user has multiple keys, well, open the
>same dialogue as with SSL client keys for example. Should requester be able
>to send a list of trusteworthy CA DNs?

I'd prefer to avoid building an entire email-key-request protocol for this.
It's more an official record of a convenient convention, "If you get email
with a key request in the subject, respond with the public keys that you hold
for the user" (so it'd be a purely informational RFC, not a standards-track
one).  It's up to the recipient what they do with them, whether they trust
them, whether they do a CRL lookup, ...

At most I'd go for:

  GETKEYS protocols addresses

  protocols := SMIME, OpenPGP, ...
  addresses := <optional email addresses to get keys for>

  mesage-body = <human-readable message to say something like "Your mailer
  doesn't understand this message, please reply with your public key if you
  can">

I'm not sure about the ability to include an optional email address, on the
one hand it makes things more flexible, but then you're starting to bloat it
up into a general-purpose key-server protocol, which it absolutely isn't meant
to be.  It's just a request to the MUA for the public key(s) that it holds for
the user/owner of the email address, in a manner that doesn't require manual
user processing if the MUA understands the request.

(To put it another way, let's see if the basic GETKEYS gets adopted.  We can
always bloat it up in version 2 if there's a demand for it).

"Anders Rundgren" <[email-masked]> writes:

>If this is good or not depends on what you want to achieve.
>
>If the goal is establishing confidential communication between a limited
>number of parties it seems that on-line based schemes (IM, Skype) tailored
>after TLS could also be a viable alternative.

That's too complicated, I'll leave it to someone else.  The point of this is
to automate the current manual process of "Hey, could you send me your key so
we can talk", replacing the need for tedious manual processing with an
automated method.  If the MUA knows the user's key, they can send it out.  If
not they can notify the user as per the current situation (or whatever the MUA
author decides to do in response to the message).

Peter.

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 24 Nov 2007 10:46:44 +0100

>Conversely, if you want [email-masked]'s public key, the best way
>to get it is to go straight to the horse's mouth and ask [email-masked],
>or in this case a proxy, his MUA.

If MUA means mail-client this introduces a noticeable latency as well as
only working when the MUA is on-line.   This alone makes this proposal
a rather handicapped scheme IMO.

It seems that interrogating a Web Service associated with the target
domain (like __mail_encryption.example.com) would be fairly simple to
get going and facilitates immediate responses.  If the acquired certificate
is issued by a known party and conforms with the mail-address, it seems
that you can automate this.  Using a TLS connection to the service you
might even accept any e-mail certificate issuer by "reusing" the trust in the
server certificate.  For encryption purposes this should be satisfactory.

Using the most current key is also a factor that were missing in Ian's
proposal.

A security implication with using DNS + a WebService is that a bad
provider could replace your encryption key with something that would
allow it to read incoming messages in clear.  OTOH, that is what they
already do today 99.9% of the time.  In fact, this scheme allows an
enterprise to add content control by performing the decryption on the
server.  For outgoing messages I believe Outlook already supports
some kind of message "escrow" mechanism...

Anders

---

From: Jörg Schwenk <[email-masked]>
Date: Tue, 27 Nov 2007 13:49:35 +0100

I'd think that since email is asynchronous communication anyway, the delay
in the MUA's response does not matter.

Also in contrast to a DNS or Web Service based solution, you will reach the
only entity that EXACTLY knows where the certificate is from only by email.

CRLs can later be retrieved by the requesting MUA from the URL given in the
certificate.

Jörg

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im
Auftrag von Anders Rundgren
Gesendet: Samstag, 24. November 2007 10:47
An: Peter Gutmann; [email-masked]
Betreff: Re: S/MIME key distribution proposal

might even accept any e-mail certificate issuer by "reusing" the trust in
the

Anders

---

From: "Timothy J. Miller" <[email-masked]>
Date: Wed, 28 Nov 2007 10:13:47 -0600

> for those (or wherever you choose to get them from).

And it may be too large to email, anyway.  DoD CRLs currently stand  
at about 120MB in the aggregate, averaging about 12MB per CA.

Everyone should be using OCSP anyway.  Do we have OCSP stapling for S/ 
MIME?

> user processing if the MUA understands the request.

My concern would be with email address mismatches.  This is common in  
the DoD, where currently email addresses are assigned by location  
(this is changing, slowly, to permanent email addresses), but  
locations change frequently.  With the additional wrinkles of  
organizational mailboxes and XOs doing sent-on-behalf-of, the current  
RFC and implementation requirement of matching the rfc822Name  
extension with the originating email address causes us real  
significant operational pain.

In short, if you send a GETKEYS to the CO's email and the XO is  
running the MUA when it gets received, whose encryption cert should  
be returned?

-- Tim

---

From: "Timothy J. Miller" <[email-masked]>
Date: Wed, 28 Nov 2007 10:23:52 -0600

> server certificate.  For encryption purposes this should be  

Depends on your needs.  DoD encrypted S/MIME is intended for end-to- 
end message privacy.  How do you get this by reusing a web service  
TLS certificate?

In addition, how do you get by the rfc822Name matching requirements?   
As far as I know *only* Microsoft Outlook can be configured to ignore  
the required match between the recipient's email address and the  
rfc822Name extension when encrypting a message.

> Using the most current key is also a factor that were missing in Ian's

This is a problem for all distribution methods *except* direct end  
user to end user exchanges.  Publication *always* lags issuance, and  
often enough fails completely.

> allow it to read incoming messages in clear.

Not just a bad provider.  This exposes the key distribution mechanism  
to DNS hijacking as well.

> 						OTOH, that is what they

If the goal is end-to-end message privacy, then server-side  
decryption is a major violation.  If you allow *either* server-side  
decryption or end-user decryption, you've just made the protocol even  
more complex than it currently is (and now you have the problem of no  
knowing the complete security profile of your S/MIME deployment--are  
messages decrypted at the server or not, who chooses, and in what  
instances?).

-- Tim