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 PROTECTED]
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
