Bill & Tim:
I have completed my WG Last Call review, and I have a few comments. I have
divided them into two categories: technical and editorial. In my view, the
technical comments must be addressed. On the other hand, the editorial
comments can be accepted or rejected by you.
TECHNICAL
I am concerned with the term "domain component." It could easily be
confused with the domainComponent attribute, as defined in RFC 2247. The
domainComponent naming attribute is used to represent DNS names as X.500
distinguished names. Is there another term that avoids this potential
confusion. Perhaps some text can be taken from RFC 1422, where the name
subordination concept is discussed.
I would like to see the discussion in section 3.1.1 and 4.1 include X.500
distinguished names that include the domainComponent naming attribute, as
defined in RFC 2247. For example:
cn="Peter Yee", dc=hq, dc=spyrus, dc=com
The id-aa-signatureType OID was assigned from the S/MIME WG arc. However,
id-aa-sigtype-domain-sig, id-aa-sigtype-add-attrib-sig, and
id-aa-sigtype-review were not assigned. Has any implementor used the
values listed in the draft? I would prefer to assign values that are not
subordinate to the assigned attributes arc; they would be shorter.
I cannot parse the following sentence (from section 3.1.2). Since "MUST"
appears twice, the sentence is obviously very important. Please reword it.
All signature types, except the originator type, MUST encapsulate other
signature types specified in this document MUST encapsulate other
signatures.
The specification relies on several well-known names (such as
domain-confidentiality-authority). These well-known names are indicators
that unusual processing is allowed. For example, when I fetch a
certificate from a directory for Bill Ottaway, and I get a certificate
containing a Diffie-Hellman key bound to the subject name
cn=domain-confidentiality-authority, ou=dera, o=mod, c=uk, I am expected to
consider the name acceptable. I generated an encrypted message using the
Diffie-Hellman key expecting that a proxy will decrypt the message and
share it only with Bill. So, there is clearly some security consideration
text needed. Organizations must take care with these well-known names,
even if they do not implement DOMSEC. If I can get a certificate
associated with domain-confidentiality-authority(_at_)spyrus(_dot_)com, then I might
be able to read messages that a DOMSEC client intended for others.
EDITORIAL
Please change "domain to domain" to "domain-to-domain." I think that this
will improve readability, especially in sentences where domain-to-domain,
individual-to-domain, and domain-to-individual concepts are all
discussed. You already use "end-to-end" and "desktop-to-desktop" in the
document. I guess that this is a request for consistency as well.
Please change "individual to domain" to individual-to-domain."
Please change "domain to individual" to "domain-to-individual."
Sometimes you say "Domain signature," and other times you say "domain
signature." Please pick one spelling and use it throughout the document.
Please change "(re-)encrypted" to "encrypted (or re-encrypted)."
I find the term "DOMSEC signature" confusing. It is only used in two
paragraphs of section 3. Perhaps those paragraphs can be reworded to avoid
this term.
In my opinion, the OIDs in section 3.1.2 would be easier to read id
presented this way:
-- domain signature
id-xxx-domain-sig OBJECT IDENTIFIER ::= { xxx 2 }
-- additional attributes signature
id-xxx-add-attrib-sig OBJECT IDENTIFIER ::= { xxx 3}
-- review signature
id-xxx-review OBJECT IDENTIFIER ::= { xxx 4}
In section 4.2, you discuss a "directory." When the concept is first
introduced, please say "a X.500 or LDAP directory may be used."
Happy New Year,
Russ