Re: (Practical) S/MIME certificate chain handling

"Julien Stern" <julien.stern@cryptolog.com> Mon, 30 June 2003 08:46 UTC

Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05984 for <smime-archive@lists.ietf.org>; Mon, 30 Jun 2003 04:46:19 -0400 (EDT)
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5U89rFK051284 for <ietf-smime-bks@above.proper.com>; Mon, 30 Jun 2003 01:09:53 -0700 (PDT) (envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h5U89rNo051283 for ietf-smime-bks; Mon, 30 Jun 2003 01:09:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5U89pFK051277 for <ietf-smime@imc.org>; Mon, 30 Jun 2003 01:09:52 -0700 (PDT) (envelope-from julien.stern@cryptolog.com)
Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by kraid.nerim.net (Postfix) with ESMTP id 1F2E940EFA; Mon, 30 Jun 2003 10:09:48 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id 58ACB4133; Mon, 30 Jun 2003 10:09:44 +0200 (CEST)
Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 01372-02; Mon, 30 Jun 2003 10:09:44 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id 2294040B3; Mon, 30 Jun 2003 10:09:44 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Mon, 30 Jun 2003 10:09:44 +0200
From: Julien Stern <julien.stern@cryptolog.com>
Date: Mon, 30 Jun 2003 10:09:44 +0200
To: jimsch@exmsft.com, ietf-smime@imc.org
Subject: Re: (Practical) S/MIME certificate chain handling
Message-ID: <20030630080944.GA10009@cryptolog.com>
References: <20030626142646.GA13613@cryptolog.com> <009801c33ce3$f83cc200$3d0311ac@augustcellars.local>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <009801c33ce3$f83cc200$3d0311ac@augustcellars.local>
User-Agent: Mutt/1.5.4i
X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at example.com
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

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@mail.imc.org 
> > [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Julien Stern
> > Sent: Thursday, June 26, 2003 7:27 AM
> > To: ietf-smime@imc.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
> > 
>