Gil,
This document is definitely a step in the right direction. A few
comments are attached below:
(1) The connection between encryption and message integrity is
misleading. TLS includes a message integrity check using HMAC (keyed MAC)
on a per-message basis. Use of encryption supports a confidentiality
requirement not message integrity; all references to encryption should
be removed from
the draft (unless confidentiality is an additional requirement) . I can
propose alternative language in a change version of your draft.
(2) I am troubled by prescriptive advice given on lines 184-186 that
describes a specific technique for identifying a security token.
As we have discussed before, the requirement to connect a specific
security token to a specific message is a general requirement extending
beyond RX. It would be much better if this text were to make reference
to Section 8 of WS-SC which describes this technique versus inventing it
from scratch,
(3) Lines 189-192 state:
[quote]
For the lifetime of the Sequence the RM Source and the RM Destination
use the session key(s) associated with the security context to either
sign or encrypt (as defined by WS-Security) at least the body and any
relevant WS-RM-defined headers of any and all messages or faults that
refer to that Sequence.
[\quote]
The reference to encryption should be removed. Is it also possible to
explicitly list the headers that must be signed?
(4) Finally, Section 3 of WS-SC describes different models for
establishing a shared SC. Should this specification offer advice on the
models
supported by a RM source and destination? Are all three models supported?
---------------
prateek
