ER023
From: Carlo Milono [mailto:cmilono@tibco.com]
Sent: Wednesday, October 14, 2009 2:40 PM
To: ws-sx@lists.oasis-open.org
Cc: Marc Goodner
Subject: Subject: NEW Issue: SHA2 Algorithms and 2010
PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER.
The issues coordinators will notify the list when that has occurred.
Protocol: ws-trust / ws-sc / ws-sp
WS-Trust 1.4 http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/os/ws-trust-1.4-spec-os.pdf
WS-SecureConversation 1.4 http://docs.oasis-open.org/ws-sx/ws-secureconversation/v1.4/os/ws-secureconversation-1.4-spec-os.pdf
WS-Security Policy 1.3 http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.3/os/ws-securitypolicy-1.3-spec-os.pdf
Artifact: all
Type: design (minor editorial)
Title: Planning for SHA2 - SHA1 Sun-setting in 2010
Most of my Company’s Public Sector customers are mandating SHA2 algorithms throughout; W3C has a Working Draft of “XML Signature Syntax and Processing Version 1.1” (26 February 2009). This specification introduces additional namespaces and imports which are not included in any of the foundation specifications in WS-SX (ws-trust, ws-sc, and ws-sp, nor in other OASIS specification on which _they_ depend). NIST has issued a strong statement which the NSA and other departments are following:
“NIST encourages a rapid adoption of the SHA-2 hash functions for digital signatures, and, in any event, Federal agencies must stop relying on digital signatures that are generated using SHA-1 by the end of 2010.” See: http://csrc.nist.gov/groups/ST/hash/statement.html and http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html.
The namespace URI for v1.1 of the XML Signature Syntax is currently http://www.w3.org/2009/xmldsig11# - it has a relevant schema and it a companion schema rather than a replacement for the 1.0 core. Other relevant namespaces include http://www.w3.org/2001/04/xmldsig-more# which includes SHA384, used for “Secret” labeled artifacts. NOTE: http://www.w3.org/2001/04/xmlenc# includes sha256 and sha512 (sha512 is used for “Top Secret” labeled artifacts).
Some references borrow from the TLS specification (e.g., ws-trust 1.4, L 909) – the move to SHA2 is also having implications of a similar move to TLS 1.2.
Description:
WS-Trust 1.4
Section 1.3 Namespace – Table 1 – should include http://www.w3.org/2001/04/xmldsig-more# for sha384 Digest. For Signature, it is relevant for rsa-sha256/ecdsa-sha256/rsa-sha384/rsa-sha512/ecdsa-sha1/ecdsa-sha384/ecdsa-sha512. For MAC, it is relevant for hmac-sha256, hmac-sha384, hmac-sha512.
Section 8.10
Mentions as an example of SHA1 with XML-C14N
Section 9.1 Key and Encryption Requirements – L2540 “The token should be signed using RSA-SHA1…” & example starting on L2544.
WS-SecurityPolicy 1.3
Section 1.2 Namespaces – same issue as with WS-Trust 1.4
Section 5.4.11.1 KeyValue Token – Example
Section 6.1 [Algorithm Suite] Property – needs to include additional algorithms associated with the http://www.w3.org/2001/04/xmldsig-more namespace, such as the Table on L1717, which needs to include sha384 and sha512.
WS-SecureConversation 1.4
Section 1.3 Namespace – same issue as with WS-Trust 1.4
Section 7 Deriving Keys – TLS derivation based on sha1 example on L767 -> L837
Related issues:
Looking forward, it looks like ECDSA will supplant RSA and DSA; these are part of NIST’s “Suite B” mandate. This will place further wrinkles in our fabric, but there doesn’t appear to be a firm date as there is for SHA1. Foundational specification such as Web Services Security: SOAP Message Security 1 are closed, UsernameToken Profile uses base64(sha1(nonce+created+password)) for its Digest password form http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-UsernameTokenProfile.pdf. WS-I Basic SecurityProfile 1.1 specifically recommends sha1 http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html#DigestMethods.
Proposed Resolution:
Include namespace http://www.w3.org/2001/04/xmldsig-more# in all three documents (follow W3C for future inclusion of http://www.w3.ort/2009/xmldsig11# )
Where SHA1 is explicitly mentioned, apply notational conventions to make it in line with both W3C and NIST (for example, W3C Section 6.0 Algorithms/Digest has SHA1 and SHA256 as Required with SHA384 and SHA512 as Optional).