OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [security-services] SHA-256 for SAML?



> 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"



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]