RE: (Practical) S/MIME certificate chain handling

"Jim Schaad" <> Fri, 27 June 2003 20:04 UTC

Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id QAA18309 for <>; Fri, 27 Jun 2003 16:04:25 -0400 (EDT)
Received: from (localhost []) by (8.12.9/8.12.8) with ESMTP id h5RJeRrb060633 for <>; Fri, 27 Jun 2003 12:40:27 -0700 (PDT) (envelope-from
Received: (from majordom@localhost) by (8.12.9/8.12.9/Submit) id h5RJeRGo060632 for ietf-smime-bks; Fri, 27 Jun 2003 12:40:27 -0700 (PDT)
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.12.9/8.12.8) with ESMTP id h5RJeQrb060627 for <>; Fri, 27 Jun 2003 12:40:26 -0700 (PDT) (envelope-from
Received: from ROMANS ( []) by (Postfix) with ESMTP id 2A94E6F816; Fri, 27 Jun 2003 12:40:27 -0700 (PDT)
From: Jim Schaad <>
To: 'Julien Stern' <>,
Subject: RE: (Practical) S/MIME certificate chain handling
Date: Fri, 27 Jun 2003 12:40:30 -0700
Message-ID: <009801c33ce3$f83cc200$3d0311ac@augustcellars.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <>
Precedence: bulk
List-Archive: <>
List-ID: <>
List-Unsubscribe: <>
Content-Transfer-Encoding: 7bit


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.


> -----Original Message-----
> From: 
> [] On Behalf Of Julien Stern
> Sent: Thursday, June 26, 2003 7:27 AM
> To:
> 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