W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2001

Re: XML DSIG Algorithm URNs

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Tue, 10 Apr 2001 00:10:27 -0400
Message-Id: <200104100410.AAA0000045561@torque.pothole.com>
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.


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."
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?
>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
>>> 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
>>> 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
>>> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:10:04 UTC