From: Francois Rousseau <f(_dot_)rousseau(_at_)adga(_dot_)ca>
Yes storing Attribute Certificates in the signedData certificates field
will avoid the redundancy of having them repeated in each signer
signerInfo. However, the signerInfo issuerAndSerialNumber field is NOT
meant to help find the correct AC as suggested. It is meant to specify
which signer's public key to use to verify the digital signature on the
signedData eContent field.
As you say, issuerAndSerialNumber is meant to identify the signature
certificate containing the signer's public key.
However, the same issuer and serial number fields are used in the
AttributeCertificate's baseCertificateID to identify the same signer's
certificate. So issuerAndSerialNumber uniquely identifies both the
signature certificate and the attribute certificate(s) which reference
it.
So when AC's are included in the signedData
certificates CertificateSet, the receiving software can NOT still be sure
to find the correct AC.
I strongly disagree with the idea that there can be "correct" and
"incorrect" ACs. Every valid AC which has been issued against a
particular base certificate is correct, i.e. the subject possesses
every attribute which has been issued to him, regardless of whether the
attributes are contained in the base certificate, one large attribute
cert, or a bunch of smaller attribute certs.
If an authorization service requires the presence of a particular
attribute, then it is sufficient that the subject possesses that
attribute. The fact that the subject may also possess a number of
other attributes is not a factor in the authorization decision, i.e.
the other attributes are not "incorrect", they are merely ignored.
It is even worst when AC's are NOT included in the
signedData certificates CertificateSet to minimize the size of
transactions, although AC's have been used with the signing process to
provide an authorization service. The receiving software than has no means
to know that AC's were used, and to find and retrieve the applicable AC
during the later verification.
I agree that the receiver has no way of knowing that an AC was used if
it is not included in the CertificateSet. That is an argument for
requiring that any applicable AC be included in CertificateSet. To
enable the use of repositories so that the full AC doesn't need to
be carried in the message, I would support the addition of a reference to
CertificateChoices, which could contain a pointer to either a cert
or an attribute cert:
CertificateChoices ::= CHOICE {
certificate Certificate,
extendedCertificate [0] IMPLICIT ExtendedCertificate, -- obsolete
attrCert [1] IMPLICIT AttributeCertificate,
certReference [2] IMPLICIT IssuerAndSerialNumber }