Subject: Re: WG Last Call: draft-ietf-smime-domsec-07.txt

From: Russ Housley <[email-masked]>
Date: Tue, 09 Jan 2001 10:24:30 -0500

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 [email-masked], 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

---

From: "William Ottaway" <[email-masked]>
Date: Wed, 10 Jan 2001 16:13:06 -0000

Hi Russ,

Comments inline.

Bill.

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Russ Housley
> Sent: 09 January 2001 15:25
> To: [email-masked]
> Subject: Re: WG Last Call: draft-ietf-smime-domsec-07.txt
>
>
> Bill & Tim:
>

Under consideration.

> 	cn="Peter Yee", dc=hq, dc=spyrus, dc=com

Under consideration. I don't see a problem.

> subordinate to the assigned attributes arc; they would be shorter.

Fine. Can you give me a new number?

>     signature types specified in this document MUST encapsulate other

Have changed to the paragraph to :-

All signature types, except the originator type, MUST encapsulate other
signatures. Note a DOMSEC defined signature could be encapsulating an
empty signature as defined in section 3.

> be able to read messages that a DOMSEC client intended for others.

I agree.

> document.  I guess that this is a request for consistency as well.

Done.

> Please change "individual to domain" to individual-to-domain."

Done.

> Please change "domain to individual" to "domain-to-individual."

Done.

> signature."  Please pick one spelling and use it throughout the document.

Done.

> Please change "(re-)encrypted" to "encrypted (or re-encrypted)."

Done.

> paragraphs of section 3.  Perhaps those paragraphs can be

Have changed to DOMSEC defined signature. Is that better?

>     id-xxx-review OBJECT IDENTIFIER ::= { xxx 4}

Okay. Awaiting new arc.

> introduced, please say "a X.500 or LDAP directory may be used."

Done.