On Friday, March 27, 1998 10:19 AM, Flanigan, Bill
[SMTP:flanigab(_at_)ncr(_dot_)disa(_dot_)mil] wrote:
j. Section 2.3, paragraph 5, sentences 3-5.
Relocate
into first paragraph. Rationale: information is too important
to be hidden back there.
I may be missing something. Paragraph 5 in section 2.3 is only two
sentences ("Receiving agents MUST support chaining..."). The only
paragraph around that is regarding attribute certificates (which we may
end up yanking). Is that what you are referring to?
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?
l. Section 3.2. Relocate paragraph # 2 into
the
last
paragraph of this section. Replace "emailAddress" with "Email
Address" in last line of last paragraph.
I have moved the paragraph. However, emailAddress is referring to a
particular OID, and making it more human will lose the connection to
that type, won't it? I will think about this.
n. Section 4.2.
(1) In line # 1, what does the "and"
mean?
And...what?
The sentence is as follows:
"In creating a user agent for secure messaging, certificate, CRL, and
certificate chain validation SHOULD be highly automated while still
acting in the best interests of the user."
How would you reword it? The intent is to express that in a secure
messaging user agent, the processing of certificates CRLs and chain
validation of certificates SHOULD be highly automated while still acting
in the best interests of the user. Should I change the language to read
this way?
(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?
(3) Paragraph 3, line 2. Define the
term
"critical."
Done. This now reads "Certificates issued for the S/MIME environment
SHOULD NOT contain any critical extensions (extensions that have the
critical field set to TRUE) other than those listed here."
(4) Paragraph 3. This paragraph is too
confusing
(what with "non-critical unless"..."deemed critical"..."SHOULD
NOT be marked as critical", etc. Recommend complete rewrite or
delete.
Suggested language welcome.
p. Section 4.4.1.
(1) Paragraph 2, line 3. Define
"end-user
subscriber" vis-a-vis "clients" , "users", "receiving agent",
and "sending agents".
I have changed this to "end-entity", to be consistent with PKIX I.
q. Section 4.4.3. How should the "subject
alternative
name extension" be marked?
Good question. Comments? I recommend critical. Same goes for
basicConstraints.
Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103 Fax +1 425 882 8060