All,
I have some responses in-line to Blake's calls for comments:
k. Section 3.1, paragraphs 1-4. Delete or
relocate
into an appendix. Rationale: verbiage seems to be editorial
and/or expository in nature, but not technical per se.
I think that this jabber about DNs is not required -- this language
predates PKIX. I recommend that it simply be deleted. Comments?
[JSP: Agree that Section 3.1, paragraphs 1-4 should be deleted.]
(2) Paragraph 1, line 10. Change
"minimum
required"
to "maximum allowable". Rationale: to promote interoperability
despite the v3 extensions "curse," and so that verbiage agrees
with the first sentence in paragraph # 3.
The first sentence in paragraph # 3 does not preclude the inclusion of
other extensions, but says that if you put them in you SHOULD NOT mark
them as critical. The idea is that a v3 S/MIME application may not
understand extensions that are not profiled here, so marking them as
critical will make the receiving agent choke, even though it may be a
compliant S/MIME v3 agent.
I don't want to limit the use of new extensions that may be useful in an
S/MIME environment by saying that this set is the "maximum allowable".
However soft that language may be, it is still discouraging. Comments?
[JSP: I agree with Blake.]
q. Section 4.4.3. How should the "subject
alternative
name extension" be marked?
Good question. Comments? I recommend critical. Same goes for
basicConstraints.
[JSP: I disagree with these comments. The S/MIME CERT I-D should minimize
the requirements that it places on the construction of certificates. The
CERT I-D does not need to state whether subjectAltName or basicConstraints
must be critical. PKIX I provides this information. The S/MIME CERT I-D
should not duplicate or contradict what is in PKIX I.]
- John Pawling