Re: [security-services] SHA-256 for SAML?

[Frederick Hirsch <frederick.hirsch@nokia.com>]

The W3C XML Security WG has published updated XML Security 1.1 drafts  
on 30 July 2009:

http://www.w3.org/News/2009#item136

The updates to XML Signature 1.1 and XML Encryption 1.1 include  
algorithm updates related to SHA-2 family.

We may wish to consider updates to reference XML Security 1.1 at the  
appropriate time.

	• XML Signature Best Practices. This Working Draft describes best  
practices related to improving security and mitigating attacks, yet  
others are for best practices in the practical use of XML Signature,  
such as signing XML that doesn't use namespaces, for example.

	• XML Signature Syntax and Processing Version 1.1. This Working Draft  
updates the signature specification.

	• XML Signature Transform Simplification: Requirements and Design.  
This Working Draft outlines a proposed simplification of the XML  
Signature Transform mechanism, intended to enhance security,  
performance, streamability and to ease adoption.

	• W3C XML Encryption Syntax and Processing Version 1.1. This Working  
Draft updates the encryption specification.

	• XML Security Generic Hybrid Ciphers. This First Public Working  
Draft augments XML Encryption Version 1.1 by defining algorithms, XML  
types and elements necessary to enable use of generic hybrid ciphers  
in XML Security applications.

	• XML Security Algorithm Cross-Reference. This Group Note collects  
the various known URIs for XML security algorithms (at the time of its  
publication) and indicates which specifications define them.

Additional drafts related to XML SIgnature 2.0 are provided on the  
publication status page:

http://www.w3.org/2008/xmlsec/wiki/PublicationStatus

regards, Frederick

Frederick Hirsch
Nokia



On Aug 2, 2009, at 12:26 PM, ext John Bradley wrote:

> For US agencies and perhaps others this is the relevant policy.
> http://csrc.nist.gov/groups/ST/hash/policy.html
>
> In adoption work on another protocol the GSA wanted HMAC-SHA256
> required vs HMAC-SHA1.
> They at least don't want anything new with SHA1 signatures.
>
> The signing of certificates is most effected by collisions.  So I
> think that will be there first target in existing software.
>
> Unless there is some new crack the thing to worry about with SAML is
> the lifetime of the non-repudiation, that is effected by the
> increased  ability to find collisions.
>
> Non-Repudiation is a requirement for LoA 3 & 4.
>
> My preference is to make certain that SHA-2 signatures are well
> supported for those that need to or want to use them.   That way if
> SHA-1 is further cracked in a year or two we won't be scrambling.
>
> Generating a forged SAML assertion that is valid and matches the SHA-1
> from another assertion is not likely doable in our lifetimes.   That
> however doesn't change the NIST policy abut using SHA-1 signatures.
>
> With SHA-2 and ECDSA likely becoming required in XMLDSIG 1.1.
> I think adding support for describing the supported signature
> algorithms in meta-data is sensible.
>
> I agree with Bob lets add it to the to do pile.
>
> John B.
>
> (I avoided taking pokes at Gov PKI and certificates,  others feel
> free;-)
>
> On 1-Aug-09, at 11:29 PM, RL 'Bob' Morgan wrote:
>
>>
>>> That language should have been moved into conformance, it's pretty
>>> much an errata, I would say. It's not even useful for conformance,
>>> since it's a SHOULD, so it probably ought to just be yanked.
>>
>> OK, so there's a proposed erratum, also the same text in the
>> conformance doc should be removed as you note.
>>
>>>> Presumably the followup question is:  is the SSTC working on what
>>>> people
>>>> tend to call "crypto algorithm agility" so the transition to new
>>>> signature
>>>> and encryption methods can be managed going forward?  I think the
>>>> answer
>>>> to that is "no" too, though maybe some of the recent XML signature
>>>> revision discussion has a bearing on that.
>>>
>>> That's also entirely about conformance, of course. The XML
>>> Signature changes that are coming do include changes to the
>>> recommended and MTI algorithms, but the spec as a whole is still
>>> algorithm agnostic, and thus SAML is too.
>>
>> Not entirely about conformance, since it is probably useful to be
>> able to indicate in metadata what signing/encryption algorithms an
>> entity prefers/supports, and metadata can't do that now other than
>> the under-specified <EncryptionMethod> element.  As you noted in a
>> private thread, metadata extensions could be defined to do that.
>>
>> It is said that there is or will be pressure from some parties to
>> stop using SHA-1 and start using SHA-256 in a year or two, so
>> probably this would be a good TC work item for the near future.
>>
>> - RL "Bob"
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/ 
>> my_workgroups.php
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>