John,
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]."
[Jim Schaad: What is the benifit of putting in the ITU-T reference? Is it
not sufficent to reference just PKIX?]
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."
[Jim Schaad: Please remove "or decrypt" in the last sentence. In some
circumstances there is no need to verify the senders certificate for a
simple decryption operation. What do I care if the sender's certificate has
been revoked, it will still decrypt and that is all I care about.
Encryption does not carry any information about authentication.]
12) Sec 4.4.3. Recommend deleting this TBD section, because subjectAltName
is described in PKIX I.
[Jim Schaad: I disagree with this. Specifically we should state that this
is the place to put the RFC 822 name again.]
14) Appendix D, Please delete this entire Appendix because it is out of date
and not needed.
[Jim Schaad: Again this is fine with the caveat that we should obsolete the
SMIME2 spec in the intro.]
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.
Jim Schaad: I am not sure that I agree with this. There are now more ways
of chaining and we should add these in or at least acknowledge them.
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.
Jim Schaad: I disagree with this, we should have some minimal text to cover
this extension and what we expect to see.
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.
================================