As suggested by Russ Housley, because there does not seem to be a consensus
on this one, I am starting a separate thread to discuss this topic.
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.
Because a signer may have multiple Attribute Certificates, it should be up
to the signer to indicate which ones he/she is wishing the recipient to
use. The recipient should only be allowed to use what is possible within
the choice of the signer. The context alone might not be sufficient for the
recipient to determine which particular Attribute Certificate must be used.
There are currently no means for a signer to bind particular Attribute
Certificate(s) to a signed content from the many attribute certificates
he/she may have. To fix this, without mandating anything further
requirements under S/MIME, I would like to suggest a new signed attribute
under CMS.
Section 11 of CMS should contain a new signed attribute as suggested in my
previous messages that binds particular Attribute Certificate(s) with a
signed content to convey the signer's privilege. Note this new signed
attribute would only be processed by the recipient's application.
It would read as follows:
"11.6 Signer Privileges
The signer-privilege attribute type specifies the attribute certificate
that must be considered to be bound with the ContentInfo value being signed
in signed-data and/or in a countersignature attribute. The
signer-privilege attribute helps in conveying the signer's privilege to the
recipient's application.
The signer-privilege attribute may be a signed attribute; it cannot be an
unsigned attribute, an authenticated attribute, or an unauthenticated
attribute.
The following object identifier identifies the signerPrivilege attribute type:
id-aa-signerPrivilege OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) <TBD> }
Signer-privilege attribute values have ASN.1 type SignerPrivilege:
SignerPrivilege ::= IssuerSerial
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 that created 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 of
the attribute certificate.
Note: The definition of IssuerSerial matches the one specified in the 1997
version of X.509 for an attribute certificate.
A signerPrivilege attribute can have multiple attribute values.
Until the use of attribute certificates gets better defined, the processing
of the signerPrivilege attribute should left to the recipient's application."
Francois Rousseau