Re: (Practical) S/MIME certificate chain handling
I was certainly not suggesting to sent the root certificate.
My point was the following: quite often, when one receives a
signed email, there is only the end-user cert.
So, it is the responsability or the receiver to retrieve the possibly
many subordinate CA certs, to figure out where the CRL is, if there
is an OCSP responder, to find out where is it, etc.
So, sure, when there will be a global worldwide interconnected directory
service which would include information on all these items, the sender
won't even have to sent his own certificate, but right now, the behavior
of some email clients, with which you cannot even send the subordinate
CA certs, seems problematic to me.
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.
On Fri, Jun 27, 2003 at 12:40:30PM -0700, Jim Schaad wrote:
I am not sure that I see any added benefit in sending the root
certificate as part of a signed message. If you don't already have the
certificate as a trusted certificate then you cannot make any additional
statements about the fact that you do or do not trust the signature on
the message you just received.
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Julien
Sent: Thursday, June 26, 2003 7:27 AM
Subject: (Practical) S/MIME certificate chain handling
I have a question regarding certificate chain verification
when receiving a signed email.
rfc2632bis-03.txt says that
"A receiving agent needs to provide some certificate retrieval
mechanism in order to gain access to certificates for recipients of
And then explains that X.500 (or LDAP) directories could be
used, or maybe the DNS system, or that the certificates could
be transmitted in the mail.
In the (very) long run, directories of some kind (where both
certificates and crl could be checked), or a remote chain
verification server as investigated by PKIX, seem to be nice
However, nowadays, such systems are highly manual at best,
and totally inexistent in most cases, hence, it would seem
reasonnable to provide the full chain of certificates needed
to verify the sender's one(s), as suggested by CMS (RFC2632) :
"certificates is a collection of certificates. It is
intended that the
set of certificates be sufficient to contain chains from a
"root" or "top-level certification authority" to all of the
the signerInfos field. There may be more certificates than
and there may be certificates sufficient to contain chains
from two or
more independent top- level certification authorities.
There may also
be fewer certificates than necessary, if it is expected
have an alternate means of obtaining necessary certificates
a previous set of certificates)."
This fairly natural behavior is implemented in Outlook
Express, Netscape, Mozilla, Notes, OpenSSL, etc. Oddly
enough, Outlook seem to only send the sender certificate, and
does not seem to provide a way to send the full chain, making
it quite unusable in practice for secure email.
While I might have overlooked an option which actually allows
the sending of a full chain, do you think it would be
reasonnable, and in the scope and the spirit of the S/MIME
Working Group, to mandate that client MUST(?)/SHOULD(?) have
an option that sends all information available to validate
the sender cert (cert chain + possibly crl and/or OCSP).
This option, especially if mandatory, would be of great use
to facilitate the widespread adoption of S/MIME, and could be
deactivated for efficiency reasons when directories (or a
similar alternate system) are widely deployed.
Thanks for your time.