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

Re: additional XMLDSIG URIs

From: Donald E. Eastlake 3rd <dee3@torque.pothole.com>
Date: Tue, 17 Apr 2001 23:57:46 -0400
Message-Id: <200104180357.XAA0000059340@torque.pothole.com>
To: "Brian LaMacchia" <bal@microsoft.com>
cc: <w3c-ietf-xmldsig@w3.org>, <lde008@dms.isg.mot.com>

From:  "Brian LaMacchia" <bal@microsoft.com>
Resent-Date:  Tue, 17 Apr 2001 17:43:47 -0400 (EDT)
Resent-Message-Id:  <200104172143.RAA08733@www19.w3.org>
Date:  Tue, 17 Apr 2001 14:11:39 -0700
Message-ID:  <BCDB2C3F59F5744EBE37C715D66E779CEAB65F@red-msg-04.redmond.corp.microsoft.com>
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>,
            <w3c-ietf-xmldsig@w3.org>
Cc:  <lde008@dms.isg.mot.com>

>Two questions:
>
>1) Why did you choose to use URLs that were not of the form
>"http://www.w3.org/2000/09/xmldsig#<something>", where the something is
>sha256, sha284, etc.  Ideally these should probably be NIST-defined
>identifiers, and failing that I would have expected them to follow the
>XMLDSIG naming scheme.  

Variously: I was taking my own advice from
draft-eastlake-uri-fqdn-param-00.txt; NIST in their draft seems to
only define OIDs, not URIs; and these additional URIs are not
officially part of the XMLDSIG standard nor is their naming and
compilation a work item of this working group.  However, as long as it
does not violate some official policy of the IETF or W3C (which my
fqdn draft certainly isn't yet), I'd generally be willing to go along
with working group consensus on this matter as well as on the one
below.

>2) Why did you add the truncation options to SHA-384 and SHA-512?  I
>can't really see a point in this; if you want a shorter hash output then
>just use a shorter hash function.  DO you have a particular scenario in
>mind that would likely want to use a subset of a SHA-384 or SHA-512
>hash?

SHA-384 and SHA-512 are 99.9+% identical. The only difference is the
value of the eight starting constants and that SHA-384 is the result
of truncating the 512 bit result.  Anyone implementing both of these
will share the 99.9+% of identical code between them and call it from
an outer routine that provides the initial constants and, for SHA-384,
truncates the results.  It seems like < 0.01% more work to let people
get 400 bit or 320 bit or other odd size hashes <= 512 if they have
such a need...

>					--bal

By the way, hopefully the final revision of draft-eastlake-sha1-01.txt
will get publicly posted next week and in not too long it should be an
Informational RFC documenting sample code to do SHA-1.  I'm planning
on also doing a couple of drafts covering SHA-256/384/512.

Thanks,
Donald

>-----Original Message-----
>From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com] 
>Sent: Monday, April 16, 2001 8:59 PM
>To: w3c-ietf-xmldsig@w3.org
>Cc: lde008@dms.isg.mot.com
>Subject: additional XMLDSIG URIs
>
>
>
>My first partial draft of additional XMLDSIG URIs is at
><ftp://ftp.pothole.com/pub/dee3/draft-eastlake-xmldsig-uri-00.txt>
>
>Donald
>
>=====================================================================
> Donald E. Eastlake 3rd                      dee3@torque.pothole.com
> 155 Beaver Street                                +1 508-634-2066(h)
> Milford, MA 01757 USA                            +1 508-261-5434(w)
>
Received on Tuesday, 17 April 2001 23:59:06 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:13 GMT