Francois Rousseau wrote:
So far the consensus is to accommodate the transfer of Attribute
Certificates but not to mandate anything further about them under S/MIME.
However just transferring Attribute Certificates under the SignedData
certificates field might not be sufficient for future business applications
using S/MIME as a transport mechanism.
Might this not be better handled as an extension to the
SigningCertificate signed attribute? IMHO this seems to be fulfilling
the same purpose for the signers certificate and defeat similar attacks.
If this was extended to allow arbitrary certificates (attribute or
otherwise) to be included it would fulfil both purposes and foil some
potential (though admittedly difficult) attacks as well.
That still leaves the thorny issue of how to identify the certificates:
i.e. hash of certificate only, hash and other properties or just other
properties.
As I've said before I personally prefer hash only because it is compact
and guaranteed to be unique. It will also bind anything whatever the
final syntax e.g. attribute certificates, "normal" certificates or any
other kind of certificate that might be used in the future.
In this way even if an implementation does not handle attribute
certificates itself (e.g. does not parse them) it can still check for
tampering by treating such certificates as a "blob".
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.