- From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
- Date: Tue, 10 Apr 2001 00:10:27 -0400
- To: <w3c-ietf-xmldsig@w3.org>, lde008@dma.isg.mot.com
In the absence of response, I plan to go ahead and do a personal "Additional XMLDSIG Related URIs" draft with the aim of it becoming an Informational RFC. I'll aim for it to be posted this week. Thanks, Donald From: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com> Message-Id: <200104051948.PAA0000037017@torque.pothole.com> To: <w3c-ietf-xmldsig@w3.org> In-reply-to: Your message of "Wed, 04 Apr 2001 12:15:30 PDT." <035d01c0bd3b$bbf04620$2a0210ac@livermore> Date: Thu, 05 Apr 2001 15:48:29 -0400 >Given the suspicious things that have been found re MD5, I think that >if we included it, we would have to specifcially recommend against its >use with RSA or similar signature algorithms. (As far as I know these >suspicious things do not effect its security in HMAC applications.) > >However, given the state of standardization of XMLDSIG and the large >number of possible additional URNs, I think it would be a better idea >to have an additional supplemental document for them. What do people >think of such an idea? > >Thanks, >Donald > >From: "Joseph Ashwood" <jashwood@arcot.com> >Message-ID: <035d01c0bd3b$bbf04620$2a0210ac@livermore> >To: <w3c-ietf-xmldsig@w3.org> >References: <OF053FCE02.426B57FA-ON85256A24.0015A56B@somers.hqregion.ibm.com> >Date: Wed, 4 Apr 2001 12:15:30 -0700 > >>The desire for RIPEMD series hashs is extremely rare, or least has been in >>my experience. It has been my experience that at the various sizes the >>preferred algorithms are MD5 (128), SHA-1 (160), Tiger-192, SHA-256, >>SHA-384, SHA-512, very few people seem to even consider going larger than >>SHA-512. So I don't think there's any real need to create a unified >>directory of any more than those. Recently I've noticed an increase of >>desire for hash mode cipher functions, so we may want to consider having at >>least token support for them, I personally don't appreciate them, I have >>generally found that they are easier to attack, or at least as slow as a >>dedicated hash function, but some people swear by them (although I do admit >>I appreciate some of the provable aspects of them). Personally I'd say we >>should include those before we go about including RIPEMD, Whirlpool, etc, >>simply because it is more likely that someone will desire them (although in >>the next few years Whirlpool will probably be named the Cryptonessie hash >>function, so it may come into demand). >> Joe >>----- Original Message ----- >>From: "Tom Gindin" <tgindin@us.ibm.com> >>To: "Glenn Adams" <gadams@vgi.com> >>Cc: "Brian LaMacchia" <bal@microsoft.com>; <w3c-ietf-xmldsig@w3.org> >>Sent: Tuesday, April 03, 2001 9:00 PM >>Subject: Re: XML DSIG Algorithm URNs >> >> >>> >>> Brian's point about defining URN's for the new extended SHA's is >>still >>> appropriate, even assuming that we include support for MD5 and RSA/MD5. >>> Should we include RIPEMD-160 (and perhaps RIPEMD-128) as well? They are >>> not mandatory to implement, of course. >>> >>> Tom Gindin >>> >>> >>> "Glenn Adams" <gadams@vgi.com>@w3.org on 04/03/2001 08:35:59 PM >>> >>> Sent by: w3c-ietf-xmldsig-request@w3.org >>> >>> >>> To: "Brian LaMacchia" <bal@microsoft.com> >>> cc: <w3c-ietf-xmldsig@w3.org> >>> Subject: Re: XML DSIG Algorithm URNs >>> >>> >>> We are also using SHA-1 (and recommend it as a preference), but need to >>use >>> MD5 >>> for compatibility with certain existing practice as well; that is, we have >>> certain legacy issues we must contend with. It seems to us that XML DSIG >>> should >>> recognize the continued use of these legacy algorithms even if they are >>not >>> recommended. >>> >>> Regards, >>> Glenn >>> >>> ----- Original Message ----- >>> From: "Brian LaMacchia" <bal@microsoft.com> >>> To: "Glenn Adams" <gadams@vgi.com> >>> Cc: <w3c-ietf-xmldsig@w3.org> >>> Sent: Tuesday, April 03, 2001 12:52 PM >>> Subject: RE: XML DSIG Algorithm URNs >>> >>> >>> > We didn't define URLs for MD5 because the crypto community has moved >>> > away from using or recommending MD5 in any new standard over the past >>> > few years, and thus there wasn't anyone pushing for use of MD5 with >>> > XMLDSIG. Why are you specifying use of MD5 in a new standard? >>> > Shouldn't you be using at least SHA-1? Along these lines, the request I >>> > expected to see is for XMLDSIG to specify URLs for SHA-256, SHA-384 and >>> > SHA-512. >>> > >>> > Note: I'm not saying we shouldn't specify an URL for MD5 and >>> > RSA-MD5-PKCS1v1.5, just questioning your reliance on it in a new >>> > standard. However, if we are going to open up the URL list then we >>> > should definitely add SHA-256, -384 and -512 to the list. >>> > >>> > --bal >>> > >>> > -----Original Message----- >>> > From: Glenn Adams [mailto:gadams@vgi.com] >>> > Sent: Monday, April 02, 2001 6:11 PM >>> > To: w3c-ietf-xmldsig@w3.org >>> > Subject: XML DSIG Algorithm URNs >>> > >>> > >>> > The ATSC (Advanced Television Systems Committee) DASE (DTV Application >>> > Software >>> > Environment) is expected to normatively reference the XML DSIG >>> > recommendation (hopefully to be finalized very soon). >>> > >>> > It is a requirement of DASE to support MD5 as a message digest algorithm >>> > as well as MD5 with RSA Encryption as a signature algorithm, and thus we >>> > need URNs to refer to these algorithms. We note that XML DSIG does not >>> > presently define a URN for either of these algorithms. Therefore, we >>> > request that the XML DSIG group add URNs for these algorithms, e.g., >>> > >>> > http://www.w3.org/2000/09/xmldsig#md5 >>> > http://www.w3.org/2000/09/xmldsig#rsa-md5 >>> > >>> > If XML DSIG doesn't define these, we will have to define our own URNs; >>> > however, given the very high likelihood of the use of these two >>> > algorithms, we believe it would be in the best interest of the XML DSIG >>> > user community to have W3C specify these URNs. >>> > >>> > Regards, >>> > Glenn Adams >>> > Chair, ATSC T3/S17 DASE Specialist Group >>> > >>> > >>> > >>> >>> >>> >>> >>> >> >
Received on Tuesday, 10 April 2001 00:10:43 UTC