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
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
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.