On Nov 23, 2007, at 2:53 AM, Peter Gutmann wrote:
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).
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?
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.
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
smime.p7s
Description: S/MIME cryptographic signature