RE: Xenc Requirements req - comments on security and other issues

Joseph, 

Having joined the discussions recently, I took your note as motivation to go
over this document [1] more carefully,and here are some comments. I begin
with few substantive comments and then move to minor comments (typos etc.). 

Substantive comments:
1. In section 5 (Security), item 3.2: I believe there is a bigger potential
security exposure using `encrypt before you sign`, specifically that with
some encryption algorithm we lost the non-repudiation property which is such
an important feature of public key signatures. Specifically, if the signer
can find two messages m1 and m2 and two keys k1 and k2 which encrypt to the
same ciphertext (E_k1(m1)=E_k2(m2)), then signing only ciphertext will allow
the signer to select later whether to claim he signed m1 (sharing key k1
with recipient) or m2 (sharing k2). This can be solved by either signing
(also) the plaintext, of course using techniques as I described in my other
note to prevent confidentiality exposure, or by using an encryption
algorithm where finding such pairs is infeasible. 

2. Ditto, item 2: I think this volunerability implies there should be an
integrity check mechanism as part of XENC, which I believe is not in the doc
(section 3) presently. 

3. Ditto, item 3.1 and 4.1: First, I think these two comments are too
similar and should be merged. Secondly, we should say that this weakness
`may exist unless the hashing/signature takes appropriate precautions`. 

4. In section 3.3 (Requirements / Processing), item 6., Encryption and
Signatures: I think there is another option we should explore, that will
allow an application to sign securely plaintext, ciphertext or both, and the
verifier can verify or not the plaintext as he wishes. We just began
discussing this on the list and all I suggest is for now to either remove
the `applications have the following options` sentence or add a mention that
there is still discussion on this. 

Minor comments:

1. First sentence of section 2. is obscure to me, i.e. what you mean by
`describes requirements over intended result`. Maybe just a language
problem.
2. In section 3.3 (Requirements / Processing), item 1.3, a typo in second
line (`a lterations to particular DOM and/or XML parser implementations`)
3. Ditto, item 2.2, should be `following` not `follow`
4. Ditto, item 5.1, at the end: should be `encrypting it` not `encrypted`

[1] http://www.w3.org/Encryption/2001/03/21-xml-encryption-req.html

Best regards, 
Amir Herzberg
CTO, NewGenPay Inc.  

See our demo and overview/tutorials on secure e-commerce in
http://www.NewGenPay.com

Received on Wednesday, 28 March 2001 07:43:18 UTC