Steve Henson wrote:
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.
I agree with Steve that the SigningCertificate signed attribute might be
another approach to handle this requirement for binding Attribute Certificate.
Although a hash only might be sufficient for a public key certificate since
it is also identified through the SignerInfo issuerAndSerialNumber field,
attribute certificates are NOT identified anywhere except by being included
in the SignedData certificates field. The situation gets even worst when
the SignedData optional certificates field is purposely left empty or does
not include attribute certificates since it is expected that recipients
have alternate means of obtaining them.
Because of this, a set of hashes alone will not suffice to identify
particular attribute certificates. In Addition, contrary to public key
certificates that are identified by the distinguished name of their issuer,
attribute certificates are identified by the GeneralNames of their issuer.
Any new generic syntax for the SigningCertificate signed attribute would
have to address both of these issues.
Francois Rousseau