Denis, Responses are in-line. spt >-----Original Message----- >From: owner-ietf-smime@xxxxxxxxxxxx >[mailto:owner-ietf-smime@xxxxxxxxxxxx] On Behalf Of Denis Pinkas >Sent: Monday, March 03, 2008 9:06 AM >To: Paul Hoffman; Turner, Sean P.; ietf@xxxxxxxx >Cc: ietf-smime@xxxxxxx >Subject: Re: Last Call: draft-ietf-smime-sha2 (Using SHA2 >AlgorithmswithCryptographic Message Syntax) to Proposed Standard > > >Responses are in-line. > >(...) > >>>>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. >> >>Spencer wins on this one. The sentence doesn't make much sense in a >>standards-track document. > >It is important to know in which document the algorithms are >described in detail. >Deleting the sentence would not solve my concern. The 2nd sentence in the Intro says (or will say after I delete the and): "The message digest algorithms are defined in [SHS]." The 1st sentence in 3 references the DSS, X9.62, and RFC2313 for DSA, ECDSA, and RSA (we're moving the references to 1st sentence of 2nd para. I think we're covered. >>> >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). >> >>I'll disagree with this. These are not security considerations; they >>are performance considerations. And pretty obvious ones at that. > >It is both performance and security. >The larger the hash is, the better is the security, but the >performance may be lower. I don't really have a problem adding this sentence. >>> >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. >> >>... or anywhere else. If any algorithm (hash, encryption, signing, >>...) is broken, it is broken. Sean's right here. > >The message is the following: if the SHA2 family is broken, >then you had better to use two hash algorithms from a >different family (e.g. use Whirlpool). > >We should also reference >http://www.ietf.org/internet-drafts/draft-ietf-smime-multisig-04.txt >which allows to use two different hash functions (from >different families, if possible). I'm not sure we need to add this reference. >Denis > > > _______________________________________________ IETF mailing list IETF@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf