1. You have said that we are removing we are removing request syntax from
the Message and certificates drafts. I am going to assume that you are
really doing that and not point out all of the locations in this draft where
it needs to be done. I would suggest keeping a short sentence at some point
point to the CRMF/PKIP drafts, except that I don't think they are going to
be finished in time.
2. Please remove section 1.2 and Appendix C. We no longer need to document
past behavior as this is now done for us by use of the IETF archive. Please
add a sentence to the introduction stating that this document supperceeds
the informational draft SMIMEV2-CERTS.
3. Section 2.2.1 -- There are now three different certificate formats
supported by CMS. Please add attribute certificates to the list.
4. Section 2.3, paragraph 5. This paragraph deals with chaining of
certificates and states that DN parsing is a MUST and nothing else is
recommended. We put this in at the very end of the V2 draft with the
intention of changing it later. I know that at Microsoft we are looking at
alternate methods of building chains. I think that we want to expand this
paragraph, but I don't know what the current PKIX proposals are and I would
not wish to go beyond that point. Is there anyone out there who can tell me
what the PKIX working group is thinking on:
A. DN chaining.
B. AltIssuer/AltSubjectName chaining.
C. AltKeyId chaining in each of its three variations. keyIdentifier,
authorityCertIssuer and authorityCertSerialNumber.
5. Section 2.2.1. If I could find a good one, I would like to get a
pointer to attribute certificaets in this section (i.e. reference a
document). As I don't think such a think exists, this comment should be
ignored.
6. Appendix F
UNIVERSAL STRING for Challenge Password? Should this simply be BMPString?
--- This dies as we don't play the PKIP game anymore.
Rewrite 5.2 for CMP and id-dsa-with-sha1 --- ditto
Stronger MD2 / MD5 language needed? --- ditto
2.2.1 -- are they "proposed" revisions, or actual revisions? --- My
understanding is that these are real revisions -- it is refering to the X509
V3 specification. We can treat this as real and lets change to "In
addition, the V3 revision of X.509 certificates ..."
Names for chaining -- see comment 4 as a request for information.
Algorithms for certs --- I don't understand the question.
Capitalization of OIDs -- lets be consistent, but not to the point of
stupidity. Also the spaces in Postal Code and Phone Number should be
removed.
Only one "official" email address? --- Please describe you issue with this.
I don't see any reason to restrict myself to one "official" address although
some CAs may wish to do this a part of local policy.
Make references [PKCS-*] consistent with smime-msg spec --- Yes you should
Section A.7 -- bit 7 is encipherOnly, bit 8 is decipherOnly. Are we going
to use these? -- I recommend that we remove the following appendixes A.5 and
A.6 as we no longer do PKI work in this document. We should "import" the
definitions of basicConstraints and keyUsage from PKIX part one and not put
them in this document.