I checked with some people on renaming the receipentKeyId field to recipientKeyid, and it's a no go. That name is used by compilers to name C code and changing it is going to cause problems. It's also been mispelled since about 1999 and nobody has said anything ;) I added a note in the ASN.1 that says:
-- receipentKeyId is spelt incorrectly, but kept for historical -- reasons. spt >-----Original Message----- >From: Turner, Sean P. [mailto:[EMAIL PROTECTED] >Sent: Friday, November 07, 2008 10:29 AM >To: '[EMAIL PROTECTED]'; '[email protected]' >Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' >Subject: RE: review of draft-ietf-smime-3851bis-08.txt > >Francis, > >Thanks for your comments. The only one I feel like I should >reply to is the comment on is 3.4.3.2: we do require SHA-256, >which is a SHA2 algorithm, just not the others. Basically, we >had to pick one and SHA-256 seemed like the one to go with. >Technically, we could remove the paragraph because it's not >really needed. For example, we point to RFC3370 and we don't >have a paragraph explaining that we don't use SS-DH or PBKDF2. > >Tim, > >I'll whip up another version after the IETF LC closes to save >the editor some work. > >spt > >>-----Original Message----- >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>Sent: Friday, November 07, 2008 10:21 AM >>To: [email protected] >>Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] >>Subject: review of draft-ietf-smime-3851bis-08.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-3851bis-08.txt >>Reviewer: Francis Dupont >>Review Date: 2008-11-06 >>IETF LC End Date: 2008-11-13 >>IESG Telechat date: unknown >> >>Summary: Ready >> >>Comments: a few editorial comments (i.e., to be handled by the RFC >>Editor if no new version of the document is published for another >>reason). >> >>Note I don't comment about the cryptographic strength >requirements even >>IMHO these should be handled by profiles according to specific >>environment context, the document specifying only the default (and >>minimum) profile (but the document doesn't make the adoption of this >>idea impossible or even hard, and if there was an agreement for >>following this kind of way this should have been done before). >> >>Comment details: >> - Discussion page 2: if this should be removed prior to >publication by >>the RFC editor it is better to mention it. >> >> - TOC page 3: Appendix C (Acknowledgments) is missing, same for >> Authors' Addresses >> >> - 1.6 page 7: WithRSAEncrption -> WithRSAEncryption >> >> - 3.4.3.2 page 28: why SHA-2 algorithms are still not recommended? >> (IMHO the paragraph still waits to be removed :-) >> >> - 7.1 page 38: I note an I-D (CMS-SHA2) is in the normative >references >> (not a problem, the publication of the document will just be defered >> until the I-D is published) >> >> - 7.1 pages 38 and 39: two FIPS publications (FIPS180-3 and >186-3) are >> marked as "draft". I don't know if this can be an issue... >> >> - Appendix A page 42: prefersBinaryInside -> preferBinaryInside >> >> - Appendix A page 43: receipentKeyId -> recipientKeyId >> >> - Appendix C page 44: Acknowledgements -> Acknowledgments >> >> - Author's Addresses page 44: Author's -> Authors' >> >>Regards >> >>[EMAIL PROTECTED] >> >>PS: congratulations for having got rid of RC2/40, this just took 13 >>years... > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
