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

["William Ottaway" <w.ottaway@xxxxxxxxxxxxxxxx>]

Hi Russ,

Comments inline.

Bill.

> -----Original Message-----
> From: owner-ietf-smime@xxxxxxxxxxxx
> [mailto:owner-ietf-smime@xxxxxxxxxxxx]On Behalf Of Russ Housley
> Sent: 09 January 2001 15:25
> To: ietf-smime@xxxxxxx
> Subject: Re: WG Last Call: draft-ietf-smime-domsec-07.txt
>
>
> 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.

Under consideration.


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

Under consideration. I don't see a problem.

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

Fine. Can you give me a new number?

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

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.


> 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@xxxxxxxxxx, then I might
> be able to read messages that a DOMSEC client intended for others.
>

I agree.

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

Done.

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

Done.

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

Done.

> Sometimes you say "Domain signature," and other times you say "domain
> signature."  Please pick one spelling and use it throughout the document.
>

Done.

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

Done.

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

Have changed to DOMSEC defined signature. Is that better?

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

Okay. Awaiting new arc.


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

Done.

> Happy New Year,
>    Russ
>