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

Re: XML DSIG Algorithm URNs

From: Joseph Ashwood <jashwood@arcot.com>
Date: Tue, 3 Apr 2001 10:07:41 -0700
Message-ID: <00d201c0bc61$49a67830$2a0210ac@livermore>
To: "Brian LaMacchia" <bal@microsoft.com>, "Glenn Adams" <gadams@vgi.com>
Cc: <w3c-ietf-xmldsig@w3.org>
As odd as it may sound to some I actually side with Adams on this one.
Sometimes it is necessary to compromise security in small ways (like using
MD5 instead of SHA-1) in order to make things fit just right. However
because this is in reference to such a situation, I believe we need some
method of classifying functions into at least 3 categories; strong,
moderately secure, broken. These will have to be done in such a way that a
function can be moved down the list, and I'm not firm on either the name or
even the number of categories so anyone can feel free to name them
differently if they can come up with something better. That would allow us
to meet the needs of those that need to use MD5 for whatever reason.
Alternately it may be recommendable for ATSC DASE to move to SHA-1. Based on
what's been said MD5 does not seem to be used because of it's speed, if for
no other reason than RSA signing is a fraction of the speed of DSA, and
unless you are signing values of astonishing size (Gigabytes at least) DSA
as spec'd will outperform RSA signing. MD5 was not used for it's size,
because an RSA signature size is chosen by the size of the modulus, if size
were an issue either ECDSA or DSA would have been selected. In terms of
security DSA is at least as good as RSA for the same size. So except for the
name there's really no reason to use RSA. If we do specify such URNs I would
like to see the use of the name PSS instead of PKCS 1.5 simply because it is
academically correct, the PSS paper specified PSS, and PKCS 1.5 merely
packages it up into an ASN.1 box.
                    Joe

----- 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 9:52 AM
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, 3 April 2001 14:13:11 UTC

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