I respectfully disagree with the idea that S/MIME supported algorithms
should be handled by PKIX for the reasons below.
According to my understanding the PKIX solutions involve a certificate
extension that is signed by an issuing authority.
The supported algorithms may change according to software, export laws,
or just plain user preference. There is indeed no reason why the S/MIME
supported algorithms should be the same as those for other purposes. If
the PKIX solution requires a new certificate (and possible expense)
whenever the supported algorithms change this is not very flexible.
I would presume the S/MIME proposal would involve very minor (if any)
changes to the current method of sending supported S/MIME algorithms in
the SMIMECapabilities authenticated attribute. One natural (to me
anyway) method is to use an empty message, (maybe with no certificates)
and dummy (or no) content and including a signing time in
SMIMECapabilities. The dummy content case involves no changes to CMS.
The S/MIME method has the advantage that it is under control of the
software and does not rely on an issuing authority. It is very similar
to the current method: all that would really be required would be to
feed in the "dummy message" from whatever source it came from into the
sofware as an ordinary S/MIME message with minor alterations.
Steve.
--
Dr Stephen N. Henson.
UK based freelance Cryptographic Consultant. For info see homepage.
Homepage: http://www.drh-consultancy.demon.co.uk/
Email: shenson(_at_)bigfoot(_dot_)com
PGP key: via homepage.