ietf-smime
[Top] [All Lists]

Re: (Practical) S/MIME certificate chain handling

2003-06-30 01:09:53

Jim,

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.

--
Julien

On Fri, Jun 27, 2003 at 12:40:30PM -0700, Jim Schaad wrote:
Julien,

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.

jim

-----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: Thursday, June 26, 2003 7:27 AM
To: ietf-smime(_at_)imc(_dot_)org
Subject: (Practical) S/MIME certificate chain handling



Hi all,

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
  digital envelopes."

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 
solutions.

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 
recognized
  "root" or "top-level certification authority" to all of the 
signers in
  the signerInfos field. There may be more certificates than 
necessary,
  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 
that recipients
  have an alternate means of obtaining necessary certificates 
(e.g., from
  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.
Sincerely,

--
Julien Stern