W3C home > Mailing lists > Public > public-xmlsec@w3.org > December 2012

Call for Consensus: publish update to XML Signature Best Practices W3C Note (respond by 12 December)

From: <Frederick.Hirsch@nokia.com>
Date: Thu, 6 Dec 2012 15:46:01 +0000
To: <public-xmlsec@w3.org>
CC: <Frederick.Hirsch@nokia.com>
Message-ID: <1CB2E0B458B211478C85E11A404A2B27018506AF@008-AM1MPN1-033.mgdnok.nokia.com>
This is a call for consensus (CfC) for the XML Security WG to agree to add a new security consideration to the XML Signature Best Practices and publish an update as a W3C  WG Note on 10 January 2013, assuming that date works for the W3C Team.

Draft (4 December 2012): http://www.w3.org/2008/xmlsec/Drafts/best-practices/Overview.html

Agreeing to this decision means I will request the Note publication after 17 December with a planned  publication date of 10 January 2013, assuming that date works for the W3C Team. As part of publication process I will update the references (including cross-references to other documents being published at the same time), as well as prepare the publication draft with the appropriate cover pages.

Please respond to this email by next Wednesday 12 December indicating support (a +1 will do) or any concern. Silence will constitute consent, but a positive response is preferred.

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair XML Security WG

The addition is as follows (see http://www.w3.org/2008/xmlsec/Drafts/best-practices/Overview.html#signers-separate-keys for formatted version):

[[

4.4 For Signers: When encrypting and signing use distinct keys

Best Practice 27: Signers: When encrypting and signing use distinct keys

If the same key is used for different operations such as signing and encryption attacks are possible that can allow signatures to be forged, so separate possibly derived keys should be used for different functions.
Use of state-of-the-art and secure encryption algorithms such as RSA-OAEP and AES-GCM can become insecure when the adversary can force the server to process eavesdropped ciphertext with legacy algorithms such as RSA-PKCS#1 v1.5 or AES-CBC [XMLENC-BACKWARDS-COMP]. In this case the attacker may be able to forge valid server signatures if the server decrypts RSA-PKCS#1 v1.5 ciphertexts [XMLENC-PKCS15-ATTACK] and the signatures are computed with the same asymmetric key pair.

Accordingly, in situations where an attacker may be able to mount chosen-ciphertext attacks, we recommend applications should always use a different symmetric key for data confidentiality and for data integrity functionality (likewise for public key functions). When use of a single key is planned, key derivation should be used to produce different keys for these functions.

[XMLENC-BACKWARDS-COMP]
Tibor Jager, Kenneth G. Paterson, Juraj Somorovsky. One Bad Apple: Backwards Compatibility Attacks on State-of-the-Art Cryptography. In Proceedings of the Network and Distributed System Security Symposium (NDSS), 2013. URL: http://www.nds.ruhr-uni-bochum.de/research/publications/backwards-compatibility/

[XMLENC-PKCS15-ATTACK]
Tibor Jager; Sebastian Schinzel, Juraj Somorovsky. Bleichenbacher's Attack Strikes Again: Breaking PKCS#1.5 in XML Encryption . 2012. In Proceedings of the 17th European Symposium on Research in Computer Security (ESO RICS). URL:http://www.nds.rub.de/media/nds/veroeffentlichungen/2012/07/11/XMLencBleichenbacher.pdf

]]
Received on Thursday, 6 December 2012 15:47:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:19 UTC