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


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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

Subject: SHA-1 vs. SHA-2/SHA-3/etc.?

Hi members,

last year I asked some questions in connection with switching from core XMLDSIG message structure to extended XMLDSIG one (which is called XAdES and published by ETSI). That time this suggestion was rejected. It was reasonable and we could accept it. But there is still a point which is hardcoded in the SAML v2.0 standard and can cause problems: the set of acceptable crypto algorithms.

Based on the SAML v2.0, we can just use RSA+SHA-1 signature method (http://www.w3.org/2000/09/xmldsig#rsa-sha1). The digest method is not mentioned in the standard, but the sample contains just the URI of SHA-1 (http://www.w3.org/2000/09/xmldsig#sha1).

Since 2012-01-01 it is required to use at least SHA-256 as base of hashes (both as digest method and as signature method) in Hungary (based on the recommendation of EU). I understood that your aim is not to modify the standard (if it is not really neccessary) in order to keep wide range interoperability. But from the viewpoint of security considerations we have to expand the set of crypto algorithms in order to keep usability. Is there a way to publish an official announcement about the acceptable crypto algorithms (and their URIs)? e.g. by simply referencing the list of crypto algorithms published in ETSI TS 102 176-1 v2.1.1?


Best regards,


SAML assertions and protocols MUST use enveloped signatures when signing assertions and protocol messages. SAML processors SHOULD support the use of RSA signing and verification for public key operations in accordance with the algorithm identified by http://www.w3.org/2000/09/xmldsig#rsa-sha1. [...] Signatures MUST contain a single <ds:Reference> containing a same-document reference to the ID attribute value of the root element of the assertion or protocol message being signed. [...] SAML implementations SHOULD use Exclusive Canonicalization [Excl-C14N], with or without comments, both in the <ds:CanonicalizationMethod> element of <ds:SignedInfo>, and as a <ds:Transform> algorithm.

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