Miguel,
Thanks for the review. Responses inline.
spt
Miguel A. Garcia wrote:
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 wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-smime-3278bis-07.txt
Reviewer: Miguel Garcia <miguel.a.gar...@ericsson.com>
Review Date: 27-May-2009
IETF LC End Date: 28-May-2009
Summary: The document is almost ready for publication as Informational
RFC. There are a number of minor/nits comments.
Comments:
- In Section 7, I am missing a normative reference to ASN.1. Probably
this is either [X.680] or the same reference used by
draft-ietf-smime-new-asn1:
[ASN1-2002]
ITU-T, "ITU-T Recommendation X.680, X.681, X.682, and
X.683", ITU-T X.680, X.681, X.682, and X.683, 2002.
I changes 7 to be: The ASN.1 syntax [X.680], [X.681], X.682], [X.683]
used in this document is gathered in this section for reference purposes.
- Similarly, in Section 7.1.1 there should be normative references to
SHA1-, SHA-224, SHA-256, etc.
The last sentence in 7.1.1 provides the references. While [CMS-ALG] and
[CMS-SHA2] aren't the algorithm specifications, they do provide
algorithm conventions and then point to the appropriate FIPS. Is this
acceptable?
- There are a number of notes at the end of Sections 7.1.2 and 7.1.3.
These notes, contains a normative text (the word OPTIONAL). I believe a
note should be informative in nature, thus, it should not contain
RFC-2119 reserved words. Perhaps the text should be promoted outside a
note.
I removed "NOTE:" from the last paragraph in 7.1.2 and 7.1.3.
- Section 7.1.3, the text mentions ECDSA with SHA-1, ECDSA with SHA-224,
etc... Is there a reference to add here? The same question is applicable
to Sections 7.1.4, 7.1.5, etc. Even Section 8. I believe all these
should be normative references.
The last sentence in 7.1.3, 7.1.5, and 7.1.6 provides the references for
the algorithms. While references aren't algorithm specifications, they
do provide conventions and then point to the appropriate FIPS/RFC. Is
this acceptable?
References definitely missing from 7.1.4.
For section 8, I've got to ask if I need to sprinkle the
references after each algorithm OID/name if they're already in section 7?
- Honestly, I didn't understand the IANA Considerations section. I don't
undersetand if IANA needs to take an action or not, and if it needs to
do it, which is the registry they should act upon and which values they
should assign. This should be clarified.
I had this wrong. The Arc isn't delegated from IANA it's delegated from
RSA. I clarified this, the # of OIDs we needed, and who does the
registrations (note that Russ Housley has acted as the SMIME WG
Registrar). It now says:
This document makes extensive use of object identifiers to register
originator public key types and algorithms. The algorithm object
identifiers are registered in the ANSI X9.62, ANSI X9.63, NIST, RSA, and
SECG arcs. Additionally, object identifiers are used to identify the
ASN.1 modules found in Appendix A (there are two). These are defined by
the SMIME WG Registrar in an arc delegated by RSA to the SMIME Working
Group: iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0). No action by IANA is necessary for this document
or any anticipated updates.
Clearer?
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
