All,
First, I want to thank Blake for incorporating the majority of my previous
comments into the March 11, 1998, S/MIME V3 Certificate Handling
Specification. I have the following comments. I have also taken the
liberty to include comments submitted by others that I believe have achieved
WG consensus, but were not included in CERT-02. Recommend that everybody
should look at this list to ensure that they agree with the comments and
that I did not omit a comment:
1) Sec 1, 1rst para: Please make the following change:
OLD: "In order to validate the keys of a message sent to it, an S/MIME agent
needs to certify that the key is valid. This draft describes the mechanisms
S/MIME uses to create and validate keys using certificates."
NEW: "Before using a public key to provide security services, the S/MIME
agent MUST certify that the public key is valid. S/MIME agents MUST use
X.509 certificates to validate public keys as described in the ITU-T
Recommendation X.509 (1997) [X.509] and the Internet Public Key
Infrastructure (PKIX) X.509 Certificate and CRL Profile [KEYM]. S/MIME
agents MUST meet the S/MIME-specific requirements documented in this I-D in
addition to those stated in [X.509] and [KEYM]."
2) Sec 1, 3rd para: Please delete the following paragraph because it is
ambiguous and the previous comment will replace this para:
"In order to handle S/MIME certificates, an agent has to follow
specifications in this draft, as well as some of the specifications listed
in the following documents:
- "PKCS #1: RSA Encryption", [PKCS-1].
- "Cryptographic Message Syntax", [CMS]."
3) Sec 1.1, certificate definition, last sent: Please add "and extensions as
defined in [KEYM]." to the following sentence: "This type also contains the
distinguished name of the certificate issuer (the signer), an
issuer-specific serial number, the issuer's signature algorithm identifier,
and a validity period."
4) Sec 1.1, CRL definition, 2nd sent: Please add "and extensions as defined
in [KEYM]." to the following sentence: "The information consists of an
issuer name, the time of issue, the next scheduled time of issue, and a list
of certificate serial numbers and their associated revocation times."
5) Sec 2.2, first para: Please change "MUST" to "MAY" in "End entity
certificates MUST include an Internet mail address"
6) Sec 2.2.1, first sent: Jim Schaad commented: "-- There are now three
different certificate formats supported by CMS. Please add attribute
certificates to the list."
7) Sec 2.2.1, 3rd sent: similar to Jim Schaad's comment: Please change:
OLD: "In addition, proposed revisions of X.509 certificates address much of
the same functionality and flexibility as was intended in the PKCS #6."
NEW: "In addition, v3 X.509 certificate extensions address much of the same
functionality and flexibility as was intended in the PKCS #6."
8) Sec 3.1, last para: This change is required because it is impossible for
a subject or issuer name to have the value of ASN.1 NULL. The subject DN in
a user's (i.e. end-entity) certificate MAY be an empty SEQUENCE. Please
change:
OLD: "All subject and issuer names MUST be non-NULL in S/MIME-compliant v3
X.509 Certificates, except that the subject DN in a user's (i.e. end-entity)
certificate MAY be NULL in which case the subjectAltName extension will
include the subject's identifier and MUST be marked as critical."
NEW: "All subject and issuer names MUST be populated (i.e. not an empty
SEQUENCE) in S/MIME-compliant v3 X.509 Certificates, except that the subject
DN in a user's (i.e. end-entity) certificate MAY be an empty SEQUENCE in
which case the subjectAltName extension will include the subject's
identifier and MUST be marked as critical."
9) Sec 4, intro, last para, 1rst sent: Please replace "PKCS #7" with "CMS".
10) Sec 4.2, 1rst para, last sent: Please change:
OLD: "This is necessary when a) verifying a signature from a correspondent
and, b) creating a digital envelope with the correspondent as the intended
recipient."
NEW: "This is necessary before using a public key to provide security
services such as: verifying a signature; encrypting a content-encryption key
(ex: RSA); or forming a pairwise symmetric key (ex: Diffie-Hellman) to be
used to encrypt or decrypt a content-encryption key."
11) Sec 4.4.2, last para: Please add: "If the keyUsage keyAgreement bit is
set to 1 AND if the public key is to be used to form a pairwise key to
decrypt data, then the S/MIME agent MUST only use the public key if the
keyUsage encipherOnly bit is set to 0. If the keyUsage keyAgreement bit is
set to 1 AND if the key is to be used to form a pairwise key to encrypt
data, then the S/MIME agent MUST only use the public key if the keyUsage
decipherOnly bit is set to 0."
12) Sec 4.4.3. Recommend deleting this TBD section, because subjectAltName
is described in PKIX I.
13) Appendix A, Please delete this entire Appendix because it is redundant
to info contained in PKIX I. Also, it includes an obsolete definition of
keyUsage.
14) Appendix D, Please delete this entire Appendix because it is out of date
and not needed.
15) App F, Needed changes:
Algorithms for certs
JSP: This is specified in PKIX I, so please delete this bullet.
Names for chaining
JSP: IMHO, the existing text is fine, so please delete this bullet.
Rewrite 5.2 for CMP and id-dsa-with-sha1
JSP: This section is gone, so please delete this bullet.
Make references [PKCS-*] consistent with smime-msg spec
JSP: Please incorporate aforementioned related comment and then please
delete this bullet.
2.2.1 -- are they "proposed" revisions, or actual revisions?
JSP: Please incorporate aforementioned related comment and then please
delete this bullet.
Section A.7 -- bit 7 is encipherOnly, bit 8 is decipherOnly. Are we going
to use these?
JSP: Please incorporate aforementioned related comment and then please
delete this bullet.
Challenge password -- CHOICE should be tagged for assigning values, and
should UTF8 should be an option?
JSP: Challenge password has been deprecated from the S/MIME v3 specs, so
please delete this bullet.
A.7 -- certificate extensions. Are we keeping this up-to-date, or do we
just refer to PKIX?
JSP: Please incorporate aforementioned related comment and then please
delete this bullet.
subjectAltName is an extension -- we need to deal with it as such
JSP: This is specified in PKIX I, so please delete this bullet.
Key usage for signing / encrypting certificate explanation
JSP: Please incorporate aforementioned related comment and then please
delete this bullet.
RFC # for PKCS #1
JSP: Is this really necessary for the CERT I-D to move forward?? If not,
please delete this bullet.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================