Re: Draft registration of application/soap+xml

Rich,

> I don't think it's necessary to get into the whole tunneled thing here. 
> It is simpler (and less controversial) to say that the message may avail 
> itself of underlying transport-level security, and/or that XML features 
> such as DSIG and XMLENC may be used to provide soap-level security features.

But that's not true.  You can sign and encrypt RPC methods as much as
you like, but that won't make them secure.

> >   The SOAP processing model itself is entirely innocuous from a security
> >   perspective.
> 
> 
> I don't think so, since it doesn't seem feasible to encrypt the actor 
> and mustUnderstand values.  If a message is intended to go A->B->C->D 
> but encrypted so only B knows the C-uri, then an adversary could 
> redirect the message from B directly to D.

That's an interesting point, but the processing model doesn't specify
how to route, only how to target.  This would be something that the
designers of SOAP-RP/ WS-Routing, etc.. , would have to consider.

I think what I said in this paragraph;

"  "actor" values are URIs, however there are no requirements that a SOAP
  processor attempt to resolve them, so no security issues should result
  from their use.  Hostile or broken SOAP intermediaries that don't
  conform to the processing model may break the end-to-end contract
  formed by the use of the "actor" attribute, but that is a known
  problem in all environments with intermediaries.  There is no known
  security problem specific to the "actor" attribute in this respect."

should cover the case of somebody tampering with mustUnderstand or
actor, but I didn't give it a lot of thought.  If you think there's
some other possible vulnerability in that scenario, I'm all ears.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Friday, 4 January 2002 13:40:07 UTC