[Top] [All Lists]

RE: (Practical) S/MIME certificate chain handling

2003-06-27 18:54:13


I hope there is a great deal more to this than what you are stating for
a Best Practice recommendation.

1.  Acceptance of root certificates by end-users is a real problem.
They tend to say yes without any good reason to do so.  This means that
it is easy to stick "bad" root certificates on a persons machine (and
thus do future spoofing) by simply sending a full certificate chain with
a message.

2.  Sending an OCSP or CRL with a message generally does not do a great
deal of good unless you are having long lived items (in which case they
may be incorrect).  In many cases either 1) the CRL/OCSP response is out
of date or 2) the OCSP response is not known to me.

If you are really working in a single structure, then this information
should be automatically distributed to people's machines and not send
from the sender.


-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of 
Sent: Friday, June 27, 2003 3:43 AM
To: Julien Stern
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: (Practical) S/MIME certificate chain handling

While I might have overlooked an option which actually allows the 
sending of a full chain, do you think it would be 
reasonable, 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 behaviour came out as a Best Practice recommendation 
from the analysis of the results for the recent EEMA PKI 
Challenge project.

Royal Mail is a trading name of Royal Mail Group plc. 
Registered in England and Wales. Registered number 4138203. 
Registered office at 148 Old Street, LONDON EC1V 9HQ