HMAC output length erratum for XML Signature 1.0 (Re: Is ACTION-297 the impact of ISSUE-105 (HMAC output length is defined on bits base64 on octets) on the XMLDSig 1.0 errata ? (see also: ACTION-298 and ACTION-320))

Picking up on this...  I see that I was chairing the meeting where we accepted this erratum; seems nobody paid attention to the editorial pieces, though.  Reflecting on what is appropriate to say in normative language, I'd propose the following language instead (this retains the same intent as what Konrad said):

> For best interoperability, signature applications SHOULD set the HMACOutputLength parameter to a value that is a multiple of 8. If the HMACOutputLength parameter is not divisible by 8, verifiers MAY use the nearest multiple of 8 that is smaller than HMACOutputLength instead; the previous considerations about minimum values for HMACOutputLength apply.  This optional cut-off is equivalent to ignoring the rightmost 1-7 bits of the HMAC's output.

(I guess ACTION-405 continues past this week's meeting...)
--
Thomas Roessler, W3C  <tlr@w3.org>







On 8 Sep 2009, at 18:27, Konrad Lanz wrote:

> Collecting the bits together ...
> 
> It seems that [ACTION-297], [ACTION-298] and [ACTION-320] are mostly the
> same thing and done already.
> 
> The only issue potentially remaining is that 1.1 solves the issue 105
> for 1.1 [XMLDSig11] and not for 1.0 [XMLDSig-errata] we say nothing. For
> legacy reasons shouldn't we also be able to work with HMACOutputLength
> not divisible by 8.
> 
> Hence I interpret [ACTION-297] as providing text for an erratum to 1.0.
> 
> In the spirit of [ACTION-320] and [XMLDSig11], however I'm not sure we
> can add a MUST/REQUIRES in an erratum, so maybe a SHOULD/RECOMMENDS
> would be more appropriate:
> 
> This specification RECOMMENDS that the truncation length be a multiple
> of 8 (i.e. fall on a byte boundary) because Base64 encoding operates on
> full bytes for newly created signatures.
> 
> Verifying applications MAY successfully verify HMAC signatures if their
> actual SignatureValue is 1 to 7 bits shorter than the HMACOutputLength
> (ignoring the last partly used byte) [ACTION-298] given that the
> truncation length is not below half the underlying hash algorithm's
> output length, or 80 bits, whichever of these two values is greater
> [Discussion-On-ACTION-298].
> 
> BR
> Konrad
> 
> [XMLDSig-errata] http://www.w3.org/2008/06/xmldsigcore-errata.html
> [XMLDSig11] http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/#sec-HMAC
> [ACTION-257] http://www.w3.org/2008/xmlsec/track/actions/257
> [ACTION-297] http://www.w3.org/2008/xmlsec/track/actions/297
> [ACTION-298] http://www.w3.org/2008/xmlsec/track/actions/297
> http://lists.w3.org/Archives/Member/member-xmlsec/2009Jun/0002.html
> [ACTION-320] http://www.w3.org/2008/xmlsec/track/actions/320
> [Discussion-On-ACTION-298]
> http://www.w3.org/2009/06/16-xmlsec-minutes.html#item08
> -- 
> Konrad Lanz, IAIK/SIC - Graz University of Technology
> Inffeldgasse 16a, 8010 Graz, Austria
> Tel: +43 316 873 5547
> Fax: +43 316 873 5520
> http://www.iaik.tugraz.at/content/about_iaik/people/lanz_konrad/
> http://jce.iaik.tugraz.at/sic/products/xml_security/
> 
> Downlaod certificate chain (including the EuroPKI root certificate):
> http://ca.iaik.tugraz.at/capso/certs.jsp
> <Konrad_Lanz.vcf>

Received on Monday, 7 December 2009 17:24:30 UTC