Subject: [Gen-art] RE: reiew of draft-ietf-smime-ibearch-05.txt

From: "Luther Martin" <[email-masked]>
Date: Thu, 1 Nov 2007 13:08:07 -0700

Comments in-line. 

Also note that I've made the reference to RFC 3236 normative instead of
informative. Although RFC 3236 is an informative RFC, it is required to
implement the contents of this document, in which case RFC 3967 seems to
require it to be a normative reference. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, October 18, 2007 8:38 AM
> To: [email-masked]
> Cc: Guido Appenzeller; Luther Martin; [email-masked];
> [email-masked]
> Subject: reiew of draft-ietf-smime-ibearch-05.txt
> 
> I have been selected as the General Area Review Team (Gen-ART)
> reviewer for this draft (for background on Gen-ART, please see
> http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-smime-ibearch-05.txt
> Reviewer: Francis Dupont
> Review Date: 2007-10-18
> IETF LC End Date: 2007-10-25
> IESG Telechat date: unknown
> 
> Summary: Not Ready
> 
> Comments: the Not Ready comes mainly from the missing ASN.1 summary.
> Other things:
>  - Abstract page 1: "generate their public key" the wording is not
>    good, I prefer the introduction one

Changed to reflect this comment.

>  - ToC page 2: the 2.x.y titles overflow

Changed to reflect this comment.

>  - 2.1 page 4 and some others: i.e. -> i.e., and e.g. -> e.g.,

Changed to reflect this comment.

>  - 2.2 page 4: the wording of:
>               The recipient's IBE public parameters allow the
>               creation of unique public and private keys.
>    is bad: one can understand these parameters are needed to create
each
>    time a new private key. The text after is clearer so it is just a
> wording
>    issue.

Changed to reflect this comment.

>  - 2.2 page 5: send someone -> send to someone and send them -> send
to
> them

Changed to reflect this comment.

>  - 2.2.1 page 6: the use of PKGs that require -> requires?
>    (it is just a question, i.e., a matter of taste)

I believe that the current wording is grammatically correct.

>  - 2.2.2 page 6: key key -> key

Changed to reflect this comment.

>  - 2.3 page 7: about HTTPS: after TLS 1.1 is always required and HTTP
is
>    sometimes cited. As it is better/clearer IMHO that should be used
at
>    this place too.

Changed to reflect this comment.

>  - 3.1 page 10 (and at some other places): there is no reason to
require
>    DER encoding when BER is enough. The IETF way should be to send DER
>    and to accept any kind of BER.

DER is needed in the use of IBE because keys are calculated from the
various values being used. Use of DER instead of BER avoids many
implementation difficulties in this area.

>  - 3.2 page 10: the "set of" is very confusing. The term structure
>    has no meaning in ASN.1 and IMHO is far better.

Changed to reflect this comment.

>  - 3.2 page 10: domain names are not coded in UTF8. In fact they are
>    on one hand free, i.e., octet strings, and on the other hand very
>    restricted... PKIX (RFC 3280) uses IA5String for dNSName but I
>    don't know if there is a real policy about this issue.

The use of IA5String reflects the consensus of the S/MIME working group.

>  - 3.2 page 11: (notAfter) times -> time

Changed to reflect this comment.

>  - 3.2 page 11: another misleading "set of"

Changed to reflect this comment.

>  - 3.2 page 12: congratulations, you avoid an "ANY DEFINED BY"
(brr...!)
>  - 4.3 page 14: but not XER (X.693). BTW this can make the document a
>    bit hard to implement (I know a very small number of XER
> implementations)
>    and it raises again the question of the basic vs canonical encoding
>    (cf. the section 9 of the ITU-T recommendation). Why mix DER and
XER?

Changed to reflect this comment.

>  - 4.6 page 16: Extensions is not defined

Changed to reflect this comment.

>  - 4.6 page 17: "the ASN.1 module below" is nowhere so:
>    * the preceeding comment
>    * I don't know if an ASN.1 module is required in this situation but
>      it is so useful I'll do as it is.

Added.

>  - Authors' Addresses page 24: please add USA?

Added.

> 
> Regards
> 
> [email-masked]

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art