-----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 3:35 AM
To: Blake Ramsdell; jimsch(_at_)exmsft(_dot_)com;
ietf-smime(_at_)imc(_dot_)org
Subject: Re: (Practical) S/MIME certificate chain handling
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 ;) ).
Outlook 2002 sends all the certificates in the chain (I just verified
this). When Jim Schaad wrote the code way back in something like
Outlook 97, I'm fairly certain that it sent all the certificates also.
This could very well be a case of misconfiguration of some sort, and I'd
be happy to work through it with you offline. The early S/MIME
implementations all understood the utility of this, and included the
certificates for exactly the reasons that you cite.
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.
I agree, and that's why they send all the certificates along with
messages to this date. By "they", I mean S/MIME-enabled versions of
Netscape, Outlook Express, Outlook, and the S/MIME plugin for Eudora
that I wrote. Granted, there could have been some change in those
clients since I've used them (I haven't used Netscape for awhile, but
Outlook Express and Outlook are in regular use here in the 'Labs, and I
know some people are still using the Eudora plugin). Unfortunately
we're speaking in generalities here, so you and I need to have a
discussion and find out exactly what is going on with current clients to
make sure that we understand if there's a problem, and who needs to
address it.
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".
This starts getting into a thorny area. Basically I've been waiting for
seven years for the certificate distribution and revocation checking
problem to get sorted out and it hasn't happened. It is not clear what
the "correct" revocation direction is, so we defer to "whatever PKIX
says" and "whatever your environment uses". That's a crappy answer, but
we've been careful not to infringe on PKIX's charter and their solutions
to this problem. I'll just stop talking right now, lest I say something
mean ;).
More generally, we have
(1) the trusted common info (the root CA)
(2) the verification information (cert chains, crl, OCSP)
Agreed.
Many email clients do implement services to retrieve or access
directories, CRL and OCSP, but they need to know _where_ to
access them.
Agreed.
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 ?
I think we should encourage "whatever PKIX says to use", which is what
we do. It's up to the working group if we want to undertake this
effort, and what form it will take. It is much larger, I think, than
saying "hey, just use this extension of the certificates".
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 ;)
That's exactly what we did in the S/MIME implementations that I've
worked on -- there is a "direct trust" option that you verify the MD5
hash of the certificate. In practice, it worked quite well because it
was mostly server-to-server configuration, and we never dealt with
revocation. So, kidding or not, it actually works in small, closed
environments where they can tell you in person if they lost their
private key ;).
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.
I just don't agree with this statement, and I consider it to be too
general. Like I said, my focus is on the MS clients and our own code,
and they perform well with the exception of a) working with an unknown
root and b) no consistent revocation option. The Verisign certs come
with a CRLDP extension that we honor, but I can't speak about other
clients. So Verisign certificates (which have a root installed in all
the clients and use CRLDP and have CRLs available) work right now. For
other roots and the associated revocation algorithm du jour, that's a
separate problem, and I worry about how much we can address it here.
Blake