(Practical) S/MIME certificate chain handling
"Julien Stern" <julien.stern@cryptolog.com> Thu, 26 June 2003 15:01 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 LAA29559 for <smime-archive@lists.ietf.org>; Thu, 26 Jun 2003 11:01:09 -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 h5QEQqrb051535 for <ietf-smime-bks@above.proper.com>; Thu, 26 Jun 2003 07:26:52 -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 h5QEQqoU051534 for ietf-smime-bks; Thu, 26 Jun 2003 07:26:52 -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-104-thursday.nerim.net [62.4.16.104]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QEQprb051528 for <ietf-smime@imc.org>; Thu, 26 Jun 2003 07:26:51 -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 7310B40E5C for <ietf-smime@imc.org>; Thu, 26 Jun 2003 16:26:46 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id 8CE4B4462 for <ietf-smime@imc.org>; Thu, 26 Jun 2003 16:26:46 +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 08899-06 for <ietf-smime@imc.org>; Thu, 26 Jun 2003 16:26:46 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id 513F74453 for <ietf-smime@imc.org>; Thu, 26 Jun 2003 16:26:46 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Thu, 26 Jun 2003 16:26:46 +0200
From: Julien Stern <julien.stern@cryptolog.com>
Date: Thu, 26 Jun 2003 16:26:46 +0200
To: ietf-smime@imc.org
Subject: (Practical) S/MIME certificate chain handling
Message-ID: <20030626142646.GA13613@cryptolog.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
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>
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
- (Practical) S/MIME certificate chain handling Julien Stern
- Re: (Practical) S/MIME certificate chain handling chris.gilbert
- RE: (Practical) S/MIME certificate chain handling Jim Schaad
- RE: (Practical) S/MIME certificate chain handling Jim Schaad
- Re: (Practical) S/MIME certificate chain handling Julien Stern
- RE: (Practical) S/MIME certificate chain handling Blake Ramsdell
- Re: (Practical) S/MIME certificate chain handling Julien Stern
- RE: (Practical) S/MIME certificate chain handling Blake Ramsdell
- RE: (Practical) S/MIME certificate chain handling Peter Gutmann
- Re: (Practical) S/MIME certificate chain handling Julien Stern
- RE: (Practical) S/MIME certificate chain handling Darrell Dykstra
- Re: (Practical) S/MIME certificate chain handling chris.gilbert