Mr. Kemp wrote:
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.
Attribute Certificates will most probably be signed by Attribute
Authorities (AA) that have their own private keys, which will be different
from the private key used by a Certificate Authority (CA) to signed public
key certificates. The only exception is if a CA is also acting as an AA and
it is using the same private key to signed both types of certificates. This
implies that the signedInfo issuerAndSerialNumber field can NOT uniquely
identify both the public key certificate and the AC for each originator.
Also the issuer field in AC is not referred through "Name" as in public key
certificates, instead it is referred through "GeneralNames" (same
GeneralNames as in subjectAltName and issuerAltName extensions from PKIX
Part 1). Because of this, the issuerSerial in Attribute Certificate's
baseCertificateID does NOT have the same syntax as the signedInfo
issuerAndSerialNumber field.
Because ACs offer a choice, the baseCertificateID associated with a public
key certificate is not the only approach to refer to its owner. Instead, an
AC can refer to its owner through its GeneralNames.
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:
Because of what is mentioned above, I would again suggest that a new
CMSAttribute be added in the signerInfo authenticatedAttributes field to
let the receiving software know for each signer that AC's were used along
the signing process, and to help the receiving software find and retrieve
from the repository the applicable AC for each signer that used them.
Instead of using the syntax of the signedInfo issuerAndSerialNumber field,
I suggest it should have the following syntax:
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
issuerUID UniqueIdentifier OPTIONAL }
Where the fields of IssuerSerial have the following meanings:
The issuer is the name of the Attribute Authority which signed the
attribute certificate.
The serialNumber is the serial number that uniquely identifies the
attribute certificate.
The issuerUID may be used to identify the issuer of the attribute
certificate in instances where the issuer name is not sufficient. This may
be required because of the use of GeneralNames to identify the issuer.
Note that all these fields already exist in ACs.
Francois Rousseau