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

RE: additional XMLDSIG URIs

From: Brian LaMacchia <bal@microsoft.com>
Date: Wed, 18 Apr 2001 11:26:29 -0700
Message-ID: <BCDB2C3F59F5744EBE37C715D66E779CEAB661@red-msg-04.redmond.corp.microsoft.com>
To: "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
Cc: <w3c-ietf-xmldsig@w3.org>, <lde008@dms.isg.mot.com>
>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

I was not aware of your other draft.  Having now read it, I don't
believe it is appropriate for use in conjunction with a W3C standard as
it does not require that there be anything meaningful when you
dereference the URL.  To answer the question Joseph posed in his recent
message, I believe one of the strengths of using URLs as identifiers is
that it's possible to automatically load information (e.g., schema,
documentation, or even mobile code) about unknown identifiers that you
run across.  Without the dereferencing capability, you have to have a
priori agreement on all the identifiers and you're back into the morass
that we currently have with OIDs.  I see no justifiable reason for
duplicating the OID mess in yet another context.  I strongly recommend
that you reconsider your draft's proposal in this light.

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

I learned long ago not to assume an implementation of an IETF or W3C
standard was implemented in any particular fashion.  After all, we're
not standardizing implementations here. 

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

Two comments:

1)  You seem to be completely ignoring the test impact.  While it might
only take me a little while to make our XMLDSIG implementation
understand these additional options, it will significantly impact the
unit & interoperability testing of that implementation.  There needs to
be a good reason to do this, and I haven't seen one yet.

2) You wrote, "...if the have such a need...".  Is there such a need in
the community right now?  Has anyone expressed an interest in a hash
function between 256 and 384 bits, or between 384 and 512 bits?
Furthermore, are we doing users of XMLDSIG a service by providing all of
these options?  I really can't see a reason to go modify my
implementation at this point to handle these truncated values when
there's no clear demand for them.


>-----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
> 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 Wednesday, 18 April 2001 16:32:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:35 UTC