Francois:
Please excuse the deplay in responding to your comments.
Sec 6, Sec 6.2 and Sec 6.4 should indicate if the different key management
techniques can be used in combination for the various recipients and/or a
single recipient of an encrypted content. Reading Sec 6, it does not seem
to preclude either approach.
It is possible for there to be three recipients, each with a different key
managament technique. What needs to change to make this clear?
Sec 6.1, both the OriginatorInfo "certs" field and the SignedData
"certificates" field from Sec 5.1 are defined as a "CertificateSet" type,
which is defined at Sec 10.2.3 as a set of "CertificateChoices" type
allowing PKCS #6 extended certificates, X.509 certificates and X.509
attribute certificates. Although attribute certificates can be present in
the "certificates" field if the value of the SignedData "version" field is
set to 3, attribute certificates are not mentioned in the definition of the
OriginatorInfo "certs" field at Sec 6.1. Does this mean that the
"EnvelopedData" and the "AuthenticatedData" content types can NOT contain
attribute certificates in their OriginatorInfo "certs" field?
No. In the OriginatorInfo discussion, I will add: "certs may also contain
attribute certificates associated with the originator. "
Sec 6.1, under the definition of the "contentEncryptionAlgorithm" field, I
suggest that the last sentence should read "The same algorithm and
content-encryption key are used for all recipients".
Agree.
Sec 10.2.1 defines the "CertificateRevocationLists" type that appears under
the "crls" field of the "SignedData", the "EnvelopedData" and the
"AuthenticatedData" content types, as a set of "CertificateList", which the
definition is imported from X.509. In addition to the Certificate
Revocation List (CRL) attribute type, which is mentioned throughout the CMS
document, three other attribute types using the syntax of CertificateList
are also defined in X.509 (i.e. Authority Revocation List (ARL), Delta
Revocation List and Attribute Certificate Revocation List), however they
are not mentioned in CMS. Are these other attribute types not also allowed
in the "crls" field of CMS? Note that PKIX Part 1 currently only mentions
the CRL and Delta CRL attribute types. I suggest that an enlarged
definition of CRL be added at Sec 10.2.1 to cover all types.
I will add: "The CertificateList may contain a CRL, an Authority Revocation
List
(ARL), a Delta Revocation List, or an Attribute Certificate Revocation List.
All of these lists share a common syntax."