Denis, Thanks for taking the time to review this ID. Responses are inline. spt >-----Original Message----- > >There are obvious errors (intentionnaly left by the editor in >order to know how many people read the document). If I was going to leave something intentionally in the document to see if you'd read it, then it would have been a lot better ... something like (note this isn't an actual offer) "if you mention this sentence to me I'll buy you a beer". This ID is way too short to sneak in this kind of phrase. >On page 1: > >The message digest algorithms are defined in and [SHS]. > ^^^ Also in section 2.4: Will remove the "and". >2.4. SHA-512 > > The SHA-256 message digest algorithm is defined in [SHS]. > >whereas it should be: > >2.4. SHA-512 > > The SHA-512 message digest algorithm is defined in [SHS]. Will replace SHA-256 with SHA-512 in 2.4. >It would be valuable to explain why DSA cannot be used with >SHA-384 and SHA-512. I'll add some text. >In addition, it is not acceptable to reference in the >*normative* references "work in progess", i.e.[ECCADD]. I'm pretty sure this is done all the time. There are 17 IDs in the RFC editor queue with works-in-progress in normative references. >The same applies for [SHS]. The text states: > > NOTE [to be removed upon publication as an RFC]: NIST has not yet > finalized FIPS 186-3 and there is a chance that the draft may be > changed. This may result in differences between what is documented > in the current version of this document and what is in the >FIPS. It > is intended to synchronize the final version of this draft with the > FIPS before publication as an RFC. The FIPS PUB 186-3 part that this ID needs has very little chance of changing. The WG wanted this note to be safe. >There is a more substantive comment on the first paragraph of >section 1. >The text states: > > If an implementation chooses to support one of the algorithms > discussed in this document, then the implementation MUST do so as > described in this document. > >I believe the text should be: > > If an implementation chooses to support one of the algorithms > discussed in this document, then the implementation MUST do so as > described in [SHS]. The algorithms aren't defined in this document only the OIDs and where they go in CMS ... so I still think it's actually "as described in this document". But, Spencer suggests removing the sentences because they're not needed and I tend to agree with him. >A small discussion in the security considerations section on >the advantages (in particular in terms of performances versus >security) of using one or another function from the SHA2 >family would be helpful. I'll see if I can't get something from NIST (or at least point to it). >While I welcome this draft, everybody should take into >consideration that, if the SHA2 family happens to be broken >then we will be at risk. >This should be mentioned into the security considerations section. If an algorithm is cracked then isn't it obvious that we're in trouble? No other algorithm document I could find says something like this so I'm inclined to not include this in the security considerations section. >The NESSIE program has evaluated with succces the WHIRLPOOL algorithm. >WHIRLPOOL would be a good substitute to SHA-512 and I would >encourage that "someone" drafts an RFC to specify OIDs for >using WHIRLPOOL with CMS. > >Denis > >>The IESG has received a request from the S/MIME Mail Security WG >>(smime) to consider the following document: >> >>- 'Using SHA2 Algorithms with Cryptographic Message Syntax ' >> <draft-ietf-smime-sha2-03.txt> as a Proposed Standard >> >>The IESG plans to make a decision in the next few weeks, and solicits >>final comments on this action. Please send substantive >comments to the >>ietf@xxxxxxxx mailing lists by 2008-03-07. Exceptionally, >comments may >>be sent to iesg@xxxxxxxx instead. In either case, please retain the >>beginning of the Subject line to allow automated sorting. >> >>The file can be obtained via >>http://www.ietf.org/internet-drafts/draft-ietf-smime-sha2-03.txt >> >> >>IESG discussion can be tracked via >>https://datatracker.ietf.org/public/pidtracker.cgi?command=vie w_id&dTag >>=16033&rfc_flag=0 >> >> > >Regards, > >Denis Pinkas > > > _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf