Jim,
I agree with you that authorization/access control information can also be
distributed through the "subject directory attributes" extension of a
public key certificate (e.g. US DoD Partition Rule Based Access Control
(PRBAC) scheme) instead of or in addition to attribute certificates (e.g.
US DoD Local Rule Based Access Control (LRBAC) scheme) as it has also been
recognized in the latest Proposed Draft Amendment (PDAM) to X.509(97).
This authorization/access control information can be included with the
signature verification public key certificate, the encryption public key
certificate or both public key certificates, and there was currently no
mean to bind it to the encryption public key certificate.
However in addition to changing only paragraph 4 of Section 5.4 as you have
proposed, I would suggest that the following paragraphs may also have to be
changed:
a. May be the new wording about signing certificates (Section 5) in the
introduction in Section 1 will have to be changed.
b. Section 5, paragraph 3,
Attribute certificates and other public key certificates can be used as
part of a signature verification process. There is no way in CMS to include
the list of other certificates to be used in the verification process. The
signer needs to have the ability to restrict the set of certificates used
in the signature verification process. This information needs to be encoded
in a manner that is covered by the signature on the SignedData object. The
methods in this section allows for the set of certificates to be listed as
part of the signing certificate attribute.
c. Section 5.3,
Some applications require that additional information be used as part of
the signature validation process. In particular, attribute certificates,
other public key certificates and policy identifiers provide additional
information about the abilities and intent of the signer. The signing
certificate attribute described in Section 5.4 provides the ability to bind
this context information as part of the signature.
d. Section 5.3.1,
5.3.1 Other Certificates
Some applications require that attribute certificates and/or other public
key certificates be validated. This validation requires that the
application be able to find the correct certificates to perform the
verification process; however there is no list of other certificates to
used in a SignerInfo object. The sender has the ability to include a set of
attribute certificates and public key certificates in a SignedData object.
The receiver has the ability to retrieve attribute certificates and public
key certificates from a directory service. There are some circumstances
where the signer may wish to limit the set of certificates that may be used
in verifying a signature. It is useful to be able to list the set of
certificates the signer wants the recipient to use in validating the
signature.
e. Section 5.4, paragraph 1,
The signing certificate attribute is designed to prevent the simple
substitution and re-issue attacks, and to allow for a restricted set of
certificates to be used in verifying a signature.
f. Section 5.4.1, paragraph 2,
Attribute certificates and additional public key certificates do not have
an issuer/serial number pair represented anywhere in a SignerInfo object.
When an attribute certificate or an additional public key certificate is
not included in the SignedData object, it becomes much more difficult to
get the correct set of certificates based only on a hash of the
certificate. For this reason, attribute certificates or additional public
key certificates are identified by the IssuerSerial object.
Any Comments?
Francois Rousseau
AEPOS Technologies
In reviewing some requirements that are coming from external companies on
our product requirements and I found the following problem.
It turns out that not everybody is up to the point of using attribute
certificates for assigning authorizations. This information is being
carried in normal authentication certificates and ususally in an encryption
certificate rather than the signing certificate. This means that we need to
allow more than attribute certificates in the last portion of the list.
Replace Section 5.4 paragraph 4 with the following:
If more than one certificate is present in the sequence of ESSCertIDs, the
certificates after the first one limit the set of authorization certificates
that are used during signature validation. Authorization certificates can be
both attribute certificates and normal certificates. The issuerSerial SHOULD
be
present in these certificates, unless the client who is validating the
signature is expected to have easy access to all the certificates required
for validation. If only the signing certificate is present in the sequence.
there are no restrictions on the set of authorization certificates used in
validating the signature.
jim