Re: additional XMLDSIG URIs

Hi,

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

My draft doesn't prohibit there being anything at the URL's. These
additional URIs are, at this instant, not part of the W3C standard or
otherwise in the orbit of the W3C.  The XMDLSIG standard permits
algorithms defined by other orgnanizations, such as these, and does
not require them to be dereferencable.  Do you want to change the
XMLDSIG standard to require dereferencability?

But I still don't understand why you assume the suggested URIs would
not be dereferencable.  In fact, I would think that the IETF would be
more stable and better able to keep material there than you typical
current dot.com.  Furthermore, I can't understand why you say they
would be like OIDs.  There is no global database or protocol system
associated with OIDs that I am aware of.  Domain names and URIs are
inherently different in having a global database, which usually
contains physical address pointers, and a system of protocols
associated with them.

>>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 <=3D 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.

Well, since people seem to be against it, I do plan to drop it from
the draft. And if the unit testing impact is too much for some
organizations, that's another reason.

As for integration testing, I would argue that if there are no
DigestMethod's with a parameter, then the mechanism for handling
parameters to them will never be exercised and is a lot more likely to
be buggy than an implementation of this trivial truncation feature.

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

So I can't make any assumptions about implementations but should make
assumptions about cryptographic size/strength requirement
quantization?

Ahhh, you have an existing implementation without this feature...

>					--bal

Thanks,
Doanld

>>-----Original Message-----
>>From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com]=20
>>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
>>
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>> 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 Thursday, 19 April 2001 09:13:12 UTC