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
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.
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of
Sent: Friday, June 27, 2003 3:43 AM
To: Julien Stern
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
client MUST(?)/SHOULD(?) have an option that sends all information
available to validate the sender cert (cert chain + possibly crl
This behaviour came out as a Best Practice recommendation
from the analysis of the results for the recent EEMA PKI
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