RE: [ws-rx] Updated proposal for i121

["Gilbert Pilz" <Gilbert.Pilz@bea.com>]

More comments nested ever deeper . . .

> -----Original Message-----
> From: Raepple, Martin [mailto:martin.raepple@sap.com] 
> Sent: Thursday, July 06, 2006 4:45 AM
> To: Gilbert Pilz; ws-rx@lists.oasis-open.org
> Cc: Prateek Mishra
> Subject: RE: [ws-rx] Updated proposal for i121
> 
> <QUOTE>
> I definitely welcome and specific proposals you may have on 
> this issue but I'm not certain I agree with you. I had 
> thought that, in general, once a block of information has 
> been encrypted it is not possible to make any changes to the 
> ciphertext without breaking the decryption process. Any 
> attempts to decrypt the altered ciphertext will, at best, 
> yield unintelligible junk or, as is more often the case, 
> result in an some kind of run time error from the crypto 
> engine. Therefore encryption gives you both confidentiality 
> and integrity. Am I mistaken?
> </QUOTE>
> 
> To the best of my knowledge, there are certain block cipher 
> modes (e.g.
> CBC)
> used in symmetric crypto algorithms that do ONLY provide 
> confidentiality but do NOT protect the integrity of the 
> encrypted data.
> This means that an attacker (even without the knowledge of 
> the key) may still be able to modify the encrypted data and 
> the decryption process will still work without throwing any 
> run time exceptions. 
> Therefore I think it is not best practice to use encryption 
> as a means to protect integrity. Instead, message integrity 
> should only be verified by (keyed) hash functions 
> specifically designed to protect data integrity and
> (optionally)
> the authenticity of a message.

I stand corrected. I'll add Prateek's suggestion to remove references to
encryption from the proposal.

[stuff removed]

> <QUOTE>
> My thinking was that a shared SC is a pre-condition to 
> protecting a Sequence using WS-SC. How the RMS and RMD 
> established that shared SC is out of scope of the WS-RM 
> specification in the same way that the means and mechanisms 
> for establishing an SSL/TLS session are out of scope as well.
> </QUOTE>
> 
> Yes, but one can think of RM-specific usage of the SC models 
> which should be described in a security section of the RM 
> spec. Prateek and I had a very productive side discussions on 
> that and are working on a proposal. 
> 
> Unfortunately, we won't be able to submit it before Monday 10th. 
> Apologies to the TC for the delay, but I hope people will 
> then have a chance to review it next week so that we can 
> discuss it on the 7/13 call.

At this point I'd really like to move ahead and get the new chapter 5 in
place with the understanding that there will be further modifications.
We can take those up as additional issues and resolve them individually.
I'm afraid that if we keep revising proposals that everyone seems to
mostly agree with we will end up dragging the process out.

- gp