W3C home > Mailing lists > Public > public-xmlsec@w3.org > August 2011

RE: Proposed changes to XML Encryption 1.1 CR Draft

From: Magnus Nystrom <mnystrom@microsoft.com>
Date: Tue, 23 Aug 2011 05:16:26 +0000
To: "Frederick.Hirsch@nokia.com" <Frederick.Hirsch@nokia.com>, "public-xmlsec@w3.org" <public-xmlsec@w3.org>
Message-ID: <D744D68428430B4F9C81DE8A4D5950681210E316@TK5EX14MBXW605.wingroup.windeploy.ntdev.microsoft.com>
Frederick,

I am not sure we should deprecate PKCS #1 v1.5 this far and at this point in the process of XML Encryption 1.1. In the case of SHA-1 there was a clear reason - weaknesses have been shown. In the case of PKCS #1 v1.5 this is not the case; it is still a perfectly valid mode. As PKCS #1 v2.1 states, "we cannot exclude the possibility that attacking RSAES-OAEP is considerably easier than inverting RSA for concrete parameters. Still, the existence of a security proof provides some assurance that the RSAES-OAEP construction is sounder than ad hoc constructions such as RSAES-PKCS1-v1_5."

If we truly want to use a scheme with better security proofs, then we should use RSA KEM (from PKCS #1 v2.1: "Hybrid encryption schemes based on the RSA-KEM key encapsulation paradigm offer tight proofs of security directly applicable to concrete parameters." Currently we only have RSA-KEM in the GHC document... And in particular, switching to OAEP but not mandating a MGF1 for OAEP other than SHA-1 seems ... asymmetric. I am thinking we may not want to change things here so late in the process unless we move towards RSA-KEM. Others?

-- Magnus


> -----Original Message-----
> From: public-xmlsec-request@w3.org [mailto:public-xmlsec-request@w3.org]
> On Behalf Of Frederick.Hirsch@nokia.com
> Sent: Wednesday, August 10, 2011 2:10 PM
> To: public-xmlsec@w3.org
> Cc: Frederick.Hirsch@nokia.com
> Subject: Proposed changes to XML Encryption 1.1 CR Draft
> 
> I have some proposed changes to the XML Encryption 1.1 CR draft [1]:
> 
> (1) PKCS1 [2]  discusses security proofs related to   RSAES-PKCS1-v1_5 and
> RSAES-OAEP , in particular for chosen cipher text attacks (see section 7). It
> states
> 
> "RSAES-OAEP is recommended for new applications;  RSAES-PKCS1-v1_5 is
> included only for compatibility with existing applications, and is not
> recommended for new applications"
> 
> I suggest we update XML Encryption 1.1 to support this  (best practice) advice by
> 
> (1a) changing the Key Transport item in  "5.1.1 Table of Algorithms"  from
> 
> required RSA-v1.5
> http://www.w3.org/2001/04/xmlenc#rsa-1_5
> 
> to
> 
> required RSA-v1.5 (Use is DISCOURAGED; see Note below)
> http://www.w3.org/2001/04/xmlenc#rsa-1_5
> 
> with corresponding
> Note:  RSA-v1.5 is required for backward compatibility to decrypt keys, but
> should not be used to encrypt keys, as noted in PKCS1. RSA-OAEP should be used
> instead.)
> 
> (1b) In section "5.5.1 RSA Version 1.5" remove "(required)" after the identifier
> URL (as we did for SHA-1)
> 
> (2) Editorial: in  "5.1.1 Table of Algorithms"  for SHA-1 it states " (Use is
> DISCOURAGED; see below)" but this "see below" is not a link  and thus not easy
> to follow.
> 
> We should update this to mimic the text in XML Signature 1.1, with "(Use is
> DISCOURAGED; see SHA-1 Warning)" where "SHA-1 Warning" is a link to the
> Message Digest section 5.8 that already contains the warning text. (In XML
> Signature we put that warning text in the SHA-1 section, tI suggest we do that
> here as well).
> 
> (3) Section 5.5.2 RSA-OAEP states
> 
> "The desired output length for EME-OAEP-ENCODE is one byte shorter than the
> RSA modulus."
> 
> PKCS1 states that the output is the length of the RSA modulus k (see item 2i in
> 7.1.1).
> 
> I suggest we remove this sentence (PKCS1 is the normative reference and details
> this material)
> 
> We could argue all these changes are editorial as #1 is advice on proper use that
> reflects what is already in PKCS1.
> 
> regards, Frederick
> 
> Frederick Hirsch
> Nokia
> 
> [1] http://www.w3.org/TR/2011/CR-xmlenc-core1-20110303/
> 
> [1] http://www.ietf.org/rfc/rfc3447.txt
> 
> This should complete ACTION-822
> 
> 
> 
Received on Tuesday, 23 August 2011 05:16:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 23 August 2011 05:16:57 GMT