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

[John Bradley <jbradley@mac.com>]

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