RE: (Practical) S/MIME certificate chain handling

"Jim Schaad" <jimsch@nwlink.com> Fri, 27 June 2003 20:04 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 QAA18309 for <smime-archive@lists.ietf.org>; Fri, 27 Jun 2003 16:04:25 -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 h5RJeRrb060633 for <ietf-smime-bks@above.proper.com>; Fri, 27 Jun 2003 12:40:27 -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 h5RJeRGo060632 for ietf-smime-bks; Fri, 27 Jun 2003 12:40:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RJeQrb060627 for <ietf-smime@imc.org>; Fri, 27 Jun 2003 12:40:26 -0700 (PDT) (envelope-from jimsch@nwlink.com)
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 2A94E6F816; Fri, 27 Jun 2003 12:40:27 -0700 (PDT)
Reply-To: jimsch@exmsft.com
From: Jim Schaad <jimsch@nwlink.com>
To: 'Julien Stern' <julien.stern@cryptolog.com>, ietf-smime@imc.org
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: <20030626142646.GA13613@cryptolog.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>
Content-Transfer-Encoding: 7bit

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
>