Re: Proposed erratum: SHA-256 for XML Signature 1.0 (ACTION-269)

On 11 May 2009, at 18:54, Sean Mullan wrote:

> I don't think it makes sense to say "implementations of prior  
> versions of this specification" since it is the same version.  
> Perhaps just "implementations of this specification".

+1; I thought I had caught this one.

>
> --Sean
>
> Thomas Roessler wrote:
>> Let's add the following erratum to the list of errata for XML  
>> Signature 1.0.  It's stretching the errata process a bit; let me  
>> know what you think.  (I'll check within the Team as well.)
>> The text is based on what's in the current 1.1 Working Draft.
>>> Class: substantive
>>> Affects conformance: yes
>>> This erratum introduces SHA256 as a recommended algorithm into XML  
>>> Signature 1.0, and recommends its use over the use of SHA1.   
>>> SHA256 will be introduced as a mandatory to implement algorithm in  
>>> XML Signature 1.1.
>>> Change the initial text in section 6.2 as follows:
>>> "This specification defines several possible digest algorithms for  
>>> the DigestMethod element, including REQUIRED algorithm SHA-1 and  
>>> the RECOMMENDED algorithm SHA-256. Use of SHA-256 is strongly  
>>> recommended over SHA-1 because recent advances in cryptanalysis  
>>> have cast doubt on the long-term collision resistance of SHA-1.  
>>> However, SHA-1 support is REQUIRED in this specification to  
>>> support interoperability with implementations of prior versions of  
>>> this specification.
>>> Digest algorithms that are known not to be collision resistant  
>>> SHOULD NOT be used in DigestMethod elements. For example, the MD5  
>>> message digest algorithm SHOULD NOT be used as specific collisions  
>>> have been demonstrated for that algorithm."
>>> Add a new section 6.2.2:
>>> 6.2.2 SHA-256
>>>
>>> Identifier: http://www.w3.org/2001/04/xmlenc#sha256
>>>
>>> The SHA-256 algorithm [SHA-256] takes no explicit parameters. A  
>>> SHA-256 digest is a 256-bit string. The content of the DigestValue  
>>> element shall be the base64 encoding of this bit string viewed as  
>>> a 32-octet octet stream.
>>>
>> -- 
>> Thomas Roessler, W3C  <tlr@w3.org>
>

Received on Monday, 11 May 2009 22:17:41 UTC