[Replying to several messages at once]
"Tony Capel" <capel(_at_)comgate(_dot_)com> 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 bob(_at_)example(_dot_)com's public key, the best way
to get it
is to go straight to the horse's moutn and ask bob(_at_)example(_dot_)com, or
in this
case a proxy, his MUA.
Peter Sylvester <Peter(_dot_)Sylvester(_at_)edelweb(_dot_)fr> 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" <anders(_dot_)rundgren(_at_)telia(_dot_)com> 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.