Hi Sean: Some comments below
Sean Turner wrote:
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 <[email protected]> Review Date: 27-May-2009 IETF LC End Date: 28-May-2009Summary: The document is almost ready for publication as Informational RFC. There are a number of minor/nits comments.Comments:
- 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?
Probably yes. I will let your own judgment decide. The key point here is that someone should be able to trace back to the precise specification that defines an algorithm. Whether the trace back is done directly or indirectly, I think is less important.
- 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?
Same as before, I believe it is acceptable, providing it is possible to trace to the normative specs of references.
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?
Ok.
- 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 theregistrations (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?
I think so.
Thanks,
Miguel
--
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
