OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [ws-rx] Updated proposal for i121


Comments in line . . . 

> -----Original Message-----
> From: Prateek Mishra [mailto:prateek.mishra@oracle.com] 

[stuff removed]

> (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.

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?

> (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,

There are a couple of problems with this:

(1) The section you are referring to appears (AFAICD) only in an editors
draft. We can't go to public review with references to editors drafts in
our document.

(2) The section you are referring to shows examples wherein SCT's are
referenced by local ID. Hal has made it clear to me that he does not
want to see this practice encouraged. I believe he has an issue open on
that in WS-SX.

(3) Obviously WS-SX is going to move forward and the section you are
referring to will probably appear (in some form pending the outcome of
the issue noted above) in CDs, PRs, etc. The problem is that the WS-SX
TC is somewhat behind the WS-RX TC in the OASIS process. I don't want to
end up blocking the WS-RX TC waiting on the WS-SX TC to get to a
particular stage.

Perhaps we could use our own description that will be forwardly
compatible with what WS-SC will eventually say on the matter?
 
> (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?

See my previous comments on encryption.

I think explicitly listing the headers is a good idea. The only problem
is the treatment of the headers that can be piggy-backed. They need to
be signed but the signature doesn't necessarily need to cover the body
of the message. In fact, there may be cases in which there is no body to
sign. Perhaps a table . . .

> (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?

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.

- gp


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]