Blake & Russ,
Here are my last call comments on the message and certificates draft. There
is one comment in here that, if you decide to do it, would also affect the
CMS and ESS drafts.
Jim
General Comments
1. I would like to see some consistancy developed in the reference naming
between the different documents produced from the S/MIME working group. I
especially dislike the KEYM reference name for PKIX Part1 as this is really
misleading. Part1 does not really say anything bout key management.
2. Are we requesting obsoletion of the V2 drafts or not. If we are then why
are we refering to them. If we are not then we need to make this clear to
the RFC editors. Based on the current thinking, it would be my guess that
we are not requesting the obsoletion of the S/MIME V2 drafts.
Message -06 draft Comments
1. Section 2.4.1 - Example on signature appears to eleminate
multipart/signed as it states content MUST be stored in eContent OCTET
STRING. I would strongly recommend removing the MUST on this as it is
example not statement of operation.
2. Section 2.5 - Why do we mention receipt requests but not security labels.
I would think they are of equal importance and should either both be
mentioned or omitted. This is especially true as security labels can easily
be understood by V2 clients but not receipts (well at least not easily). I
recommend we strike the reference to receipt requests.
3. Section 2.6 -- This is not stated in the format of a MUST. Change to
"S/MIME v3 agents MUST use the isserAndSerialNumber form of SignerInfo." or
similar statement.
4. Section 2.7.1.3 - Given that rule #4 appears to have vanished, there is
no reason not to remove all references to "Unknown version of S/MIME" in
this section. I recomment that we strike all such references.
5. Section 3.2.1 - The last sentence contains a "MUST not" this should be
"MUST NOT"
6. Section A - Changing to an ASN module would be considered niceness but
not necessity. I an finding that I use ASN modules more and more for
creation of ASN encode/decode functions. Given that we now have several
different ASN structures in this appendix, I would like to see this combined
into an ASN module. I can create this if desired.
7. References -- The [DH] citation should be made to reference the internet
draft/RFC
Certificate Draft comments
1. Section 1 - Reference to KEYM in the last sentence of paragraph #1 is
almost certianly meant to be a reference to SMIME-MSG
2. Section 1 - PKCS#10 requirements are in the V2 Msg Draft and not the V3
message draft. This text needs to be omitted or refer to MSG-V2 instead.
(CERT-V2?)
3. Section A - Remove reference to CRMF as we don't use it
4. Section 2.3 - P#3 - Given inheritance of DSA parameters do we need to
modify the statement on not sending the root CA cert. Messages are not even
internally validatable with out the root in some cases.
5. Section 4.3 - Why is there a reference to SMIME-MSG for RSA but not for
DSA? Why is there no reference for DSA?
6. Section 4.4 - P#1 - Lets replace the last sentence with "The syntax and
semantics of all the identified extensions are defined in [KEYM]."
7. Section 4.4 - P#2 - Replace sentence #1 with "... the Basic Constraints,
Key Usage, Authority Key Identifier, Subject Key Identifier and Subject
Alternative Name Certificate Extensions when they ..."
8. Section 4.4.1 - We have a big conflict with PKIX. We say
basicConstraints should appear, they say it should not. My personal opinion
on this one is that PKIX is wrong and we should not change it, but I raise
this as an incompatiblity between the two drafts.
9. Section 4.4.1 - Should we add the same criticality statement as occurs in
PKIX -- i.e. MUST be critical if it appears. I recommend that we strike the
criticality statment in 4.4.2 as it duplicates information in PKIX part1.