On Mon, Jun 30, 2003 at 02:15:03AM -0700, Blake Ramsdell wrote:
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Julien
Stern
Sent: Monday, June 30, 2003 1:10 AM
To: jimsch(_at_)exmsft(_dot_)com; ietf-smime(_at_)imc(_dot_)org
Subject: Re: (Practical) S/MIME certificate chain handling
So to summarize, I was wondering whether it would be a good idea to
mandate that clients should sent as much info as possible so
as to help
signature verification, or at least provide the user with the
option to
do so. Naturally, none of these info should include root
trust anchors.
I believe that most clients transmit the certificate chain (not
including the root) today.
To the best of my knowledge, Outlook does not, and it has quite a large
market share ... (Although, I'd be happy to know how to make it do so if
there is a way ;) ).
It's not clear what action we can take that would make life nicer for
everyone -- we already have language in 2632bis:
<verbatim>
Sending agents SHOULD include any certificates for the user's public
key(s) and associated issuer certificates. This increases the
likelihood that the intended recipient can establish trust in the
originator's public key(s). This is especially important when sending
a message to recipients that may not have access to the sender's
public key through any other means or when sending a signed message to
a new recipient. The inclusion of certificates in outgoing messages
can be omitted if S/MIME objects are sent within a group of
correspondents that has established access to each other's
certificates by some other means such as a shared directory or manual
certificate distribution. Receiving S/MIME agents SHOULD be able to
handle messages without certificates using a database or directory
lookup scheme.
</verbatim>
If there is something I'm missing, please let me know. This is a SHOULD
recommendation.
I'm afraid this cannot be made much clearer, you are right ...
I guess I would really like to be able to send a signed S/MIME email to
someone with whom I only share a root CA, and that all verifications can
be made ... Because we do not have interconnected directories yet, the
sender definitely has to send the full chain (up but not including the
root), but the client should also be able to check CRL and/or OCSP. Some
clients support these, but they often have to be configured manually.
There are five PKIX extensions which receiving agents MUST support,
indicated in section 4.4 of rfc2632bis. It would be quite nice that
receiving agents also support "CRL Distribution Points", and even
maybe "Authority Information Access".
More generally, we have
(1) the trusted common info (the root CA)
(2) the verification information (cert chains, crl, OCSP)
Many email clients do implement services to retrieve or access
directories, CRL and OCSP, but they need to know _where_ to access them.
Ideally, I think sending agent should include either (2), or indications
on where to retrieve (2). Maybe S/MIME should encourage the usage of
the aforementionned extensions ?
If I have to phone my email recipient to explain him: go on such web
page, click on "download intermediate CA", follow the procedure,
then click on "enable CRL", enter some.address.com/crl/class27-3.crl
I could also spell out the hash of my cert, and get rid of CAs ;)
Just kidding of course, but the information currently commonly
transmitted in S/MIME emails is often not sufficient to enable automatic
signature verification without preliminary manual configuration, for
each specific sender or group of senders.
--
Julien Stern