Blake (and friends),
I have the following comments to the 20 Nov 97 S/MIME v3 Certificate
Handling specification.
In general, I believe that we should at least mention Attribute Certificates
(AC) in the spec since they are included in the CMS CertificateChoices
syntax. I don't believe that we need to solve every problem regarding
validating ACs, but we should at least make some statements regarding their
use. The following comments included some specific recommendations
regarding ACs and other topics:
1) Sec 1.1: Please add the following text (some of the following text that
was paraphrased from the X.509 spec): "Attribute Certificate (AC): An X.509
AC is a separate structure from a subject's public key X.509 Certificate. A
subject may have multiple X.509 ACs associated with each of its public key
X.509 Certificates. Each X.509 AC binds a SEQUENCE OF Attributes with one
of the subject's public key X.509 Certificates. The X.509 AC syntax is
defined in [X.509]"
2) Sec 2.2: Please add as last sent: "Receiving agents SHOULD support X.509
ACs."
3) Sec 2.3: Please add as last para (some of the following text that was
paraphrased from the X.509 spec): "Receiving agents SHOULD support X.509
ACs. At a minimum, receiving agents SHOULD at least support the decoding of
X.509 ACs. Please note that there is no requirement that the same CA create
both the public key X.509 Certificate and X.509 AC(s) for a user. Each
organization's local policy will define how X.509 ACs are validated and
used. The implications of performing multiple certification path
validations should be considered when defining local policy. Exchanges
between a subject and the CA dealing with the generation of X.509 ACs are
outside the scope of this specification."
4) Sec 5.2: Section 5.2 strongly implies that S/MIME v3 agents must use PKCS
#10 to request certificates. IHMO, this is a significant issue that needs to
be debated further. The issue is should the Spec discuss using PKCS #10,
PKIX CMP or some other variant? Or should the topic of requesting
certificates be included in a separate document such as a PKIX document?
5) Sec 5.2, 3rd para: Please replace with: "Receiving agents MUST support
the identification of a DSA key with the id-dsa OID and related syntaxes
defined in [KEYM]. Receiving agents MUST support the identification of a DH
key with the dhpublicnumber OID and related syntaxes defined in [KEYM]. CAs
MUST support id-dsa-with-sha1 as defined in [KEYM] for verification of
signatures on certificate requests as described in [SMIME-MSG].
Receiving agents SHOULD support the identification of an RSA key with the
rsa defined in X.509 and the rsaEncryption OID. CAs SHOULD support
sha-1WithRSAEncryption and md5WithRSAEncryption and SHOULD support
md2WithRSAEncryption for verification of signatures on certificate requests
as described in [SMIME-MSG]."
6) Sec 5.3: Please replace with: "CAs SHOULD use the id-dsa-with-sha1
signature algorithms when signing certificates. CAs may use the
sha-1WithRSAEncryption signature algorithms when signing certificates."
7) Sec A.7: The most recent definition of KeyUsage extension defines bits 7
and 8 as encipherOnly and decipherOnly, respectively. The cert spec needs
to address the usage (or non-usage) of these bits.
8) App B: Add reference for CMS.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================