Re: additional XMLDSIG URIs

Hi guys,

I dislike the truncation option on the two SHA digests. The fact
that their underlying implementations are similar will probably
be entirely hidden from XMLDSIG implementors who will likely do
MessageDigest.getInstance ("SHA-384") or equivalent. Truncation
will add significant (relative) complexity in this (probable)
situation.

I'd suggest, for consideration, the type foo#pkcs7SignedData
pointing at a PKCS#7 signed data with associated certs and CRLs.
While not necessarily _good_, it is a fairly common container.

I could not find draft-eastlake-uri-fqdn-param-00.txt but I
personally would prefer a single base URL (not the XMLDSIG
namespace) that suggests the common origin of these URIs.

Merlin

r/dee3@torque.pothole.com/2001.04.17/23:57:46
>
>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.m
>icrosoft.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)
>>
>


-----------------------------------------------------------------------------
Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com

Received on Wednesday, 18 April 2001 14:37:12 UTC