[Top] [All Lists]

RE: More on Cert-03.txt and Msg-03.txt

1998-04-27 18:57:37
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.
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

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
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"

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
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

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
(what with "non-critical unless"..."deemed critical"..."SHOULD 
NOT be marked as critical", etc.  Recommend complete rewrite or 

Suggested language welcome.

                      p.  Section 4.4.1.  

                              (1)  Paragraph 2, line 3.  Define
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
name extension" be marked?

Good question.  Comments?  I recommend critical.  Same goes for

Blake C. Ramsdell
Worldtalk Corporation
For current info, check
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

<Prev in Thread] Current Thread [Next in Thread>