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

From: Francis Dupont <[email-masked]>
Date: Thu, 18 Oct 2007 17:37:59 +0200

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
 - ToC page 2: the 2.x.y titles overflow
 - 2.1 page 4 and some others: i.e. -> i.e., and e.g. -> e.g.,
 - 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.
 - 2.2 page 5: send someone -> send to someone and send them -> send to them
 - 2.2.1 page 6: the use of PKGs that require -> requires?
   (it is just a question, i.e., a matter of taste)
 - 2.2.2 page 6: key key -> key
 - 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.
 - 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.
 - 3.2 page 10: the "set of" is very confusing. The term structure
   has no meaning in ASN.1 and IMHO is far better.
 - 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.
 - 3.2 page 11: (notAfter) times -> time
 - 3.2 page 11: another misleading "set of"
 - 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?
 - 4.6 page 16: Extensions is not defined
 - 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.
 - Authors' Addresses page 24: please add USA?

Regards

[email-masked]

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