(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 []) 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 []) 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 []) 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 []) 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 []) 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 ([]) by localhost (jupiter []) (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 []) 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.

Julien Stern