- From: <Frederick.Hirsch@nokia.com>
- Date: Thu, 18 Aug 2011 14:39:42 +0000
- To: <public-xmlsec@w3.org>
- CC: <Frederick.Hirsch@nokia.com>, <tlr@w3.org>
What should we do, if anything, with the RSA-WHIRLPOOL algorithm? I was looking at ACTION-238 on Thomas - this relates to the ACTION-222 proposal. That proposal suggested documenting the ECDSA-RIPEMD identifier (which we have done in the algorithms cross-reference) and suggested requiring it instead of ecdsa-sha1. At this point we require ecdsa-sha256 so the reason for requiring this algorithm in XML Signature 1.1 is moot. I suggest no additional change is needed for this algorithm. The other proposal is to document the identifier for RSA-WHIRLPOOL, which we have not done. Should we put this in the algorithms cross reference. If so, can someone please make a concrete proposal of changes to that document? Please comment on what we should do next so we can close this long standing action. Thanks regards, Frederick Frederick Hirsch, Nokia Chair XML Security WG --- from ACTION-222: Proposal: * ECDSA-RIPEMD Identifier: http://www.w3.org/2007/05/xmldsig-more#ecdsa-ripemd160 #ecdsa-ripemd160 fragment of the new namespace identifies a signature method processed in the same way as specified by the #ecdsa-sha1 fragment of this namespace with the exception that RIPEMD160 is used instead of SHA-1. * RSA-WHIRLPOOL Identifier: http://www.w3.org/2007/05/xmldsig-more#rsa-whirlpool This implies the PKCS#1 v1.5 padding algorithm [RFC3447] as described in section 2.3.1 but with the ASN.1 BER WHIRLPOOL algorithm designator prefix. An example of use is <SignatureMethod Algorithm=http://www.w3.org/2007/05/xmldsig-more#rsa-whirlpool"/> * ECDSA-WHIRLPOOL Identifiers: http://www.w3.org/2007/05/xmldsig-more#ecdsa-whirlpool The #ecdsa-whirlpool fragment of the new namespace identifies a signature method processed in the same way as specified by the #ecdsa-sha512 fragment of this namespace (http://www.w3.org/2001/04/xmldsig-more) with the exception that WHIRLPOOL is used instead of SHA-512. Konrad Lanz, 10 Mar 2009, 16:39:01
Received on Thursday, 18 August 2011 14:40:12 UTC