Re: Xenc Requirements req - comments on security and other issu es

Sure. I'll provide it together with my recommended change to item 1 as well (see discussion below): 


    1.. sign before you encrypt: weaknesses if a plaintext hash (inside an XML Signature) is provided along with the encrypted data, unless proper precautions are taken (such as properly adding an encrypted random string to the plaintext before hashing). {List: Finney} 
    2.. encrypt before you sign: potential for fraud if one is induced to digitally sign encrypted data that may not be what the user expected. Also, there may be more than one <data,key> pairs resulting in the same encrypted data, therefore special care must be taken in the selection of the encryption function or in the signature process to provide non-repudiation of the data. .{List: Wang, Ashwood}
    Sure. I'll provide it together with my recommended change to item 1 as well (see discussion below): 
  My background is that of a lawyer, not a cryptographer, but doesn't no. 2 only apply if Joseph's point is disregarded: i.e., that no. 2 is only a problem if the signer is held responsible for knowing and approving the content of the encrypted data? As Joseph correctly pointed out, http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0076.html, this is a legal problem. When encrypted portions of a document are presented, the signer usually is not adopting the contents as his or her own statement or position because the content is undecipherable. If he or she never saw the contents,  the signer ostensibly should not be held responsible for it. I would think that the standard could simply declare, in order  to ensure that one only "signs what one can see", encrypted data is not the responsibility of a signer whose signature is applied at a time after encryption by another took place. Alternatively, a warning could be made to applications developers: i.e., that applications should establish by a click-wrap agreement, which is presumptively valid under e-Sign even without a digital signature, that a signer is not responsible legally for the contents of an encrypted block applied by another prior to the time that a digital signature was affixed. A similar approach could be made with respect to the desirability of randomizing hashed plaintext under no. 1. Simply suggest these approaches to applications developers and leave the proposed work product on the standard alone.