Subject: Content security model

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Jul 2012 12:59:43 -0400

I have been thinking a lot about Web Services and how their security
needs should be met in HTTP/2.0. I came up with some thoughts that
might provoke discussion:

0) The killer application for HTTP/2.0 (if any) is going to be Web
Services. Anyone supporting a Web server is going to have to support
/1.1 for decades to come. A new Web Service can stipulate HTTP/2.0
transport as a requirement.

1) TLS security is good for what it does, but it is still transport
security and will therefore be hop-by-hop as far as intermediaries are
concerned. This gives rise to the need for security features in HTTP
that are orthogonal to TLS and can survive passage through an
intermediary.

2) Multiplexing changes the nature of Web Services security and allows
for a significant simplification. Under HTTP/1.1 a Web Service that
takes a message from A and forwards it to B has to modify the content
if it is going to provide additional information in the transaction.
This constraint no longer applies under multiplexing.

3) HTTP security controls should only secure content. Signing headers
is not only difficult, it is often counterproductive. If a Web service
depends on information in a header there is probably something wrong.

This last one might seem a little controversial, after all, doesn't
DKIM have a mechanism for header signing? DKIM does have a header
signing mechanism but the headers being signed should probably have
been content in the first place. The subject line, From, To, these are
all message content. They are part of the headers because content and
routing are conflated in SMTP email.

HTTP does have a similar conflation, but nowhere near as severe.
Content is mostly confined to the body and Routing is strictly
confined to the Head. The parts that cross the line are
Content-Encoding and Content-Type. Both of which are ignored in a Web
Services context almost all the time.  Yes, a Web Service could
support multiple character encodings but I cannot see any case where I
would want the service to use Content-Encoding to make the choice.

>From these I draw the following conclusions:

* HTTP 2.0 should draw a distinction between routing headers and
content meta-data
* HTTP encryption and authentication are necessary independent of TLS support

-- 
Website: http://hallambaker.com/

---

From: James M Snell <[email-masked]>
Date: Wed, 25 Jul 2012 10:06:13 -0700

+1

On Wed, Jul 25, 2012 at 9:59 AM, Phillip Hallam-Baker <[email-masked]>wrote:

> [snip]

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 25 Jul 2012 10:48:08 -0700

On Wed, Jul 25, 2012 at 9:59 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> . . . long discussion differentiating HTTP headers and body . . .

> * HTTP encryption and authentication are necessary independent of TLS support

Just to be clear, that last bullet should be "Encryption and
authentication of HTTP bodies are necessary independent of TLS
support", yes?

---

From: Albert Lunde <[email-masked]>
Date: Wed, 25 Jul 2012 12:59:19 -0500

> would want the service to use Content-Encoding to make the choice.

This seems like a reasonable position for web services, but HTTP is also 
a transport for HTML in the context of web browsers, which when mixed 
with JavaScript and dynamic HTML, have done a remarkable job of 
confusing content with metadata, and declarative markup with 
Turning-complete languages.

There must be some security attacks which involve corrupting the headers 
or the request. Maybe HTTP/2.0 will have better framing to resist this.

"HTTP Request Splitting" comes to mind, or maybe adding a 
Content-Disposition header.

You may be right, though that it's easier to apply some kinds of 
security (signing or encryption) to a payload.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Jul 2012 14:23:00 -0400

Yes, in a web service context the two are independent.

* Header confidentiality is a major concern in many instances, ==> TLS
is a requirement
* Integrity and encryption need to flow across intermediaries, ==>
HTTP security is a requirement

TLS is inherently limited to two party conversations (OK you could
possibly force it to do multicast).

Web Services transactions are frequently of the type, A hands data
onto B who looks at it and decides whether to forward it to C or D
which may be immediate or after a delay. TLS is just not the right
tool to achieve that requirement although it would probably be used on
each of the A-B, B-C, C-D links.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Jul 2012 14:30:07 -0400

On Wed, Jul 25, 2012 at 1:59 PM, Albert Lunde <[email-masked]> wrote:
> This seems like a reasonable position for web services, but HTTP is also a
> transport for HTML in the context of web browsers, which when mixed with
> JavaScript and dynamic HTML, have done a remarkable job of confusing content
> with metadata, and declarative markup with Turning-complete languages.

Hopefully TLS deals with those cases to the extent that it is possible to do so.

> There must be some security attacks which involve corrupting the headers or
> the request. Maybe HTTP/2.0 will have better framing to resist this.
>
> You may be right, though that it's easier to apply some kinds of security
> (signing or encryption) to a payload.

I suspect it will fall out naturally from the MUX design since pretty
much every MUX design ends up separating routing headers and content
headers. Take a look at MIME for example.

Worst case scenario would be some sort of encapsulation scheme:

GET / HTTP/1.1
Date: Blah..
Proxy-Woxy:
Content-Integrity: wkjfhawkjhqkwjerhg
Content-Length:1029096

Content-Type: application/http
Content-Length:1029048

<?xml 2.3; encoding=utf9>
<....

This does look a little like PEP of course.

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 26 Jul 2012 11:12:41 +1200

> transport as a requirement.

We don't *need* any "killer app" unless we break the protocol semantics 
or mandate features which require a lot of administrative intervention 
to deploy 2.0. Seamless gateway for 2.0<->1.1 is a requirement - 
precisely to avoid this type of change.

The existing players who have already fronted up and expressed interest 
in upgrading should be all it takes to get the ball rolling.

> that are orthogonal to TLS and can survive passage through an

+1000. Well put.

> This constraint no longer applies under multiplexing.

This does not follow. A web service which is designed with transport 
details embeded in the content is going to face content modification 
trouble no matter what we do. Unless you are considering the HTTP 
headers "content" somehow.
  The cases of Location, Content-Location and services trying to do 
NAT-like things with URL domain names is an foul smell unrelated to 
multiplexing. I can see the flow controls needed for multiplexing 
leading to better efficiency on these systems, but not removing their 
behaviour entirely.

> would want the service to use Content-Encoding to make the choice.

The 1.1 drafts were onto a good thing by separating and identifying 
what headers are "content" meta data and which are "transport" meta 
data.
  If we enshrine the difference in HTTP/2 (different frame sections, 
whatever) we leave ourselves the option of signing the content headers 
against manipulation, while leaving the transport group open for 
intermediary routing etc.

We took this for a theoretical test-drive in the network-friendly-00 
framing design. The headers which are repeated per-request are usually 
the content headers, and the transport headers are aggregated across 
requests into the transport or common frames. Embedding message signing 
into this framing system would mean; sending the non-signed headers in a 
common frame ahead of the signed request, then signing the followup 
request-frame and entity-frames for the request flow frames. Encrypted 
or signed responses can easily operate the same in their flow.
   In theory the trade-off is a small drop in efficiency as common 
frames change from being strictly common, to containing un-signed unique 
things and constantly needing updates. This small drop would seem to be 
a good tradeoff against blanketing an entire connection with TLS 
overheads.

> * HTTP encryption and authentication are necessary independent of TLS 

+1000.

Amos

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 26 Jul 2012 10:04:55 +1000

> > 3) HTTP security controls should only secure content.
> > Signing headers is not only difficult, it is often counterproductive.
> > If a Web service depends on information in a header
> > there is probably something wrong.

What about the URI?
What about the method (GET, POST, DELETE...)?

Only protecting the body only works for RPC-style web services in which every request is a POST to a single API endpoint (eg POST /api/ HTTP/1.1). Even then the body needs to have an "audience" field that is likely to repeat the host (or URI).

HTTP/2 needs to support REST APIs, where the method and URI are crucial parts.

> > * HTTP 2.0 should draw a distinction between routing headers and

+1
Though I suspect there are lots of headers where this distinction is not crystal clear.

--
James Manger

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Jul 2012 20:13:36 -0400

As I said, if the content type matters then it really needs to be
considered a part of the content rather than something that
intermediaries have a right to meddle with.

Similarly, if A passes a message to B which 'modifies it' and then
passes 'the message' to C, well, it isn't there are two completely
separate messages from a security point of view, one between A-B and a
second completely different set of content between B-C.

The only way that a message can flow through B with 'modification' in
a meaningful sense is if the message is a composite message and the
parts that have been modified are separated from the parts that remain
constant. So for example, I submit a purchase order to the local
enterprise service which appends a second message with a promise of
payment. The vendor receives two separate signed blobs, one for the
bill of goods, another for the payment promise.

On Wed, Jul 25, 2012 at 6:41 PM, James French <[email-masked]> wrote:
> It occurs to me that a man-in-the-middle could change a Content-Type
> header to trick a web service into a delivering scripted data.
>
> 1.) MITM uploads script.jpg to https2://legit-host/script.jpg
> 2.) Client requests /script.jpg from legit-host
> 3.) legit-host signs and delivers script.jpg with a Content-Type of: image/jpg
> 4.) MITM changes Content-Type header from image/jpg to text/html
> 5.) Client runs script.jpg with the permissions level of a script
> running on legit-host
>
> It's unlikely that this scenario would come up in practice, but it
> does exist as a hypothetical vector.
>
>> depends on information in a header there is probably something wrong
>>

---

From: Grahame Grieve <[email-masked]>
Date: Thu, 26 Jul 2012 10:22:35 +1000

There's no limit to the things that B might have to do to the content
in order to "make things work" - whatever that is. I think that the key
is to differentiate between the various roles that B may play, and the
limit on them. In the sense of a protocol intermediary, then B is limited
to some kinds of changes, not others. In the case of others, B becomes
something else - an application intermediary. There's some utility in
describing, for instance, to what degree an application intermediary can
provide additional services that include changing some content without
completely invalidating the idea of authenticating the connection between
A and C. That would necessarily include visibility - in the sense that
this kind of intermediary should be visible to the end-points

Grahame

-- 
-----
http://www.healthintersections.com.au / [email-masked]

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Jul 2012 20:27:52 -0400

Those are good questions.

I guess it depends very much on what type of intermediary is involved
and whether it is a proxy type object or something 'transformational'.
In the first case the URI is going to be the same, in the second it is
going to change.

So when I design a protocol, I don't actually use the URI at all. My
server dispatch methods cannot see it, and that is exactly what I want
as I don't want the dispatcher to see anything other than the
authenticated data and the credential it is validated against.

If I wanted to pass parameters in the URI then I would make the
authentication token one of the parameters. But seriously, I never saw
the virtue of squashing your whole protocol into the request URI.

The URI line is very limited though, only 1024 bytes. Which means that
any serious service has to use url/form encoding as an option at the
very least. If you are going to pass content in the body of the
message then why not use the JSON encoding in both directions and save
some work?

As far as security goes, the model is rather different between
symmetric and asymmetric key.

With a public key protocol, the message is signed and anyone can check
the signature. This creates opportunity for endless subversion issues
as commands intended for one recipient are redirected to another. I
actually try to avoid using signatures for this very reason unless I
am writing a protocol where that is the requirement.

With a symmetric key protocol the authentication and thus the command
is inherently bound to the keys at both ends.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Jul 2012 20:34:37 -0400

Where security is concerned the problem is that either something is
inside the authentication boundary or it is not. If it is inside the
boundary it must not be modified in any way whatsoever if the
integrity check is to work at all. If it is outside the boundary then
the dispatch service should probably not see it at all lest it end up
making assumptions that it is trustworthy.

What it comes down to is that intermediaries that modify HTTP messages
can cause Web Services to stop working. Which is probably a good thing
since it is rather unlikely that an intermediary that does not
understand the semantics of the Web Service concerned is going to do
anything other than introduce breakage or worse introduce a subtle
error that it is not readily apparent.

The objective should be to ensure that Web Services do not malfunction
in the presence of intermediaries, not to require them to attempt to
repair the damage.

---

From: Grahame Grieve <[email-masked]>
Date: Thu, 26 Jul 2012 10:43:51 +1000

> in the presence of intermediaries, not to require them to attempt to

of course. But since we live in the real world too, we shouldn't prevent
their use to repair the damage.

> making assumptions that it is trustworthy.

yes, quite. So currently there is a binary choice: you can have managed
interactions, or secure interactions. As you say, in an ideal world, we
would not need managed interactions (nor secure ones, really), But in
the real world we do live in, we very much need secure interactions, and
we also need managed ones. I'd like for the protocol to avoid making
this a binary choice, though it smells ugly to me.

> can cause Web Services to stop working.

oh yes, though they can also cause them to work in the first place.

> Which is probably a good thing

well, typically, in my world, the intermediary is a general purpose
toolkit introduced over the exchange with the express purpose of
bridging between two end-points that have very specific disagreements
about how things work. This is a common requirement when actually
integrating two off-the-shelf packages that both thought they'd implemented
the same semantics, but in actual case haven't. In the context of a
secure exchange, the general purpose toolkit gets to mount a MITM
attack on them too. This works until the end-to-end security becomes
part of the transaction semantics, at which point the MITM is no longer
transparent, and there is no way forward.

Grahame

p.s. this is obviously about application to application web services, and
the general argument doesn't make sense in a consumer web context.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 25 Jul 2012 21:00:02 -0400

A trusted intermediary can do anything it likes and the recipient will
accept the data (provided that the trusted intermediary
re-authenticates it)

Now the trusted intermediary may not be trustworthy, but that is a
whole different thing entirely.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 26 Jul 2012 06:41:30 +0000

In message <[email-masked]
ra.com>, "Manger, James H" writes:

> Only protecting the body only works for RPC-style web services [...]

This is where we need to use a more precise terminology than "protect",
and "secure":

Are we talking Authenticity, Privacy or Integrity here ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Mike Belshe <[email-masked]>
Date: Wed, 25 Jul 2012 23:59:09 -0700

> security and will therefore be hop-by-hop as far as intermediaries are

Actually, TLS is end-to-end encrypted and just an opaque byte stream as far
as intermediaries are concerned.  I'm not sure what you mean by hop-by-hop,
but TLS is not (to me) hop-by-hop.

> This constraint no longer applies under multiplexing.

I don't think multiplexing has impact on this.  If HTTP/2.0 (with
multiplexing) is truly transparent, then the higher level message
transformations are identical with or without mux.

> depends on information in a header there is probably something wrong.

Like a cookie?  We can retroactively try to claim cookies are wrong, but
that doesn't help the millions of services that employ them today.

I think you're just differentiating the securing of the stream (which is
what TLS does) from the securing of the content (some sort of signing).
 These are independent and can be mixed and matched.

Mike

---

From: James French <[email-masked]>
Date: Wed, 25 Jul 2012 22:42:13 +0000

---

From: Grahame Grieve <[email-masked]>
Date: Thu, 26 Jul 2012 01:05:59 +0000

well, perhaps I should express my thinking like this:

   trust is not layered. it's all captured to either the intermediary
   or the server. I wish it were otherwise.

Grahame

-- 
-----
http://www.healthintersections.com.au /
[email-masked] / +61 411 867 065

---

From: Benjamin Carlyle <[email-masked]>
Date: Thu, 26 Jul 2012 05:12:31 +0000

> transport as a requirement.

Here's a crazy thought. Why don't we put the knives away for a moment and
consider whether the new version of http could line up a little closer with
soap, if not necessarily in syntax then perhaps at least a little in its
model? Currently the structure of a http message is approximately a method
and uri or status code, plus key/value store of headers that each have
additional per header syntax and data model, plus an optional body.
Ignoring the whole of soap for a moment if that were merely translatable to
an xml info set then you could pick up xml canonicalization, signatures,
and encryption for relatively little standards work. It might even be
possible to consider unifying soap and http at this protocol level so we no
longer need to wrap one in the other in order to cross between systems.

I know the soap and http cultures have some distance between them, and I
know that there are technical difficulties as well as dangers of polluting
nice pure architectural style, but it seems to me that to have a run up
towards a new major version as important as http with a rollout that will
take decades to complete that making peace between the political and
technical needs of a few warring factions sold not be too big an issue to
consider biting off.

Maybe I'm crazy and/or naive :)

> depends on information in a header there is probably something wrong.

I don't see a point in securing a request message unless it's recipient can
authenticate uri, headers and body as being unchanged from when they were
authentically written on behalf of the user with possible additional
annotations from intermediaries. I don't see the point in securing content
returned from a server unless you are also securing cache control
information that tells me it is still valid and is not done kind of replay
attack, and again various header information is relevant to want to secure.

> * HTTP encryption and authentication are necessary independent of TLS
support

It seems to me we shouldn't need two solutions to any given problem. Soap's
tenancy to use custom methods, custom headers, and custom media types (ie
custom schemas) are not things we want or need on the Web, but I find it a
shame to be heading in different directions on basic important things like
signatures and encryption of messages. In the end http and soap at the
message structure level have but a hairl's difference between them. It
seems naively to me that I'd http were to take a step towards soap at that
basic message structure level that other standardisation problems might
become simpler to solve, and that the shared solution could facilitate an
unwrapping of soap messages to be able to be sent potentially as first
class citizens on the web... Although problems with WS-Addressing might be
the first hurdle to cross.

Benjamin

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 26 Jul 2012 09:01:14 +0000

In message <CABaLYCtZjfR0S3fz-vt8S6ZPaa05B0e5X+7tWPYb=[email-masked]>

>but TLS is not (to me) hop-by-hop.

TLS is, as far as content is concerned hop-by-hop.

Usage of the broken CA-certificate model for key-material limits TLS
to one hop which connects end to end, but other key-material models
support more hops.

This is one of the reasons I push the envelope+(metadata+content)
model for HTTP/2.0:  You can use TLS to gain privacy for
the envelope on a hop-by-hop basis, while still allowing the
intermediaries to act on that envelope, and while still having
end-to-end privacy on the metadata+content.

---

From: Jan Algermissen <[email-masked]>
Date: Thu, 26 Jul 2012 15:25:46 +0200

On Jul 26, 2012, at 7:12 AM, Benjamin Carlyle wrote:

> It might even be possible to consider unifying soap and http at this protocol level

As in 'writing a standard WSDL document for HTTP'?

Jan

---

From: Jonathan Ballard <[email-masked]>
Date: Thu, 26 Jul 2012 07:33:19 -0700

Message transformations, multiplexed or not, still have no expression for
frames in the schemes. That's where we can rely on said semantics instead
of assume where transformations are identical.

On that note, I wondered if HTTP/2 should state the minimal time resolution
between occurrences of individual messages before the transport must switch
to either streams or another real-time protocol for any higher resolution.

On Wednesday, July 25, 2012, Mike Belshe wrote:

>
>
> On Wed, Jul 25, 2012 at 9:59 AM, Phillip Hallam-Baker <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
> > wrote:
>
> Actually, TLS is end-to-end encrypted and just an opaque byte stream as
> far as intermediaries are concerned.  I'm not sure what you mean by
> hop-by-hop, but TLS is not (to me) hop-by-hop.
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Jul 2012 11:18:39 -0400

On Thu, Jul 26, 2012 at 1:11 AM, Benjamin Carlyle <[email-masked]> wrote:
> an xml info set then you could pick up xml canonicalization, signatures, and
> encryption for relatively little standards work.

Nothing involving XML Signature is remotely simple, and I was one of
the people who worked on it. I was also an editor of WS-Security.

What I am trying to do with this proposal is to provide the capability
that WS-Security should have provided if the XML nonsense had not got
in the way.

> It might even be possible
> to consider unifying soap and http at this protocol level so we no longer
> need to wrap one in the other in order to cross between systems.

That is the idea.

What makes XML Signature hard is canonicalization combined with the
fact that the signature has to sit in the middle of the data it signs,
thus bringing in transforms.

Put the signature in a HTTP header and pretty much everything that is
hard about XML Signature goes away.

> Maybe I'm crazy and/or naive :)

We could look at DIME and my DIME Security proposal :-)

> attack, and again various header information is relevant to want to secure.

Web Services are layered on top of HTTP just like HTTP is layered on
TLS to produce HTTPS. TLS does not secure the TCP headers, so why
should web services require the HTTP routing layer to be secure?

IPSEC tries to secure the TCP header and it turns out to be a major
protocol blunder. They secured the source and destination IP addresses
and so the protocol didn't work through NAT which at this point is the
normal situation for an Internet connection. The designers did that
deliberately to stop the spread of NAT. I remember sitting in the
meeting listening to the rants against the evils of NAT thinking to
myself 'Time Warner wants $10/month per IP address, sod that for a
lark, I have 15 machines and in any case they will only allow 4'.

Ideological commitments such as XML Cannonicalization and NAT-busting
in the face of empirical evidence that they don't work are the reason
that we end up having to do stuff over and over again. Which in turn
is the reason that it is important to make sure that the ideological
commitment that ruined the first spec does not get carried over to the
next. We don't really need JSON encoding, we could do perfectly well
by choosing a rational subset of XML and dropping all the SGML
nonsense that has no place in a web service type transport. But the
political difficulty of rationalizing XML is harder than the political
difficulty of just rebuilding the spec from scratch somewhere that the
ideology can't be re-injected.

The reason that there is an issue is that HTTP has the operation and
the content metadata sprinkled into the routing headers. This gives us
three parts of the message we might need to sign.

* Method + URI
* Content Metadata headers
* The Body

Signing the URI is in turn a little tricky as in a Web service it is
quite often the case that some parts of the URI are actually routing
and other parts are parameters to the Web service.

For example a Web service "Foo" with command "Command" and parameters
"p1=v1.." might be specified as:

http://www.example.com/Foo/Command?p1=v1&p2=v2
http://www.example.com/Foo?cmd=Command&p1=v1&p2=v2

Now let us introduce an intermediary that reroutes the service to a
back end processor that supports versions 1 through 5:

http://foo.example.com/v1/Command?p1=v1&p2=v2
http://foo.example.com/v1?cmd=Command&p1=v1&p2=v2

This is all very standard stuff, but how does the signer know which
part of the uri is routing and which is command? In the first example
there is a part of the URI stem that is security critical, in the
second only the parameters are security critical.

There is always a tension between how much legacy you want to support
and making the spec clean and simple. My personal preference would be
to tell people that if they want to use the integrity features then
they have to design their Web service around the particular
constraints it imposes. But that is an ideological position I probably
can't win so I would have to fallback to something like the following

* Each integrity header contains integrity check(s) for exactly one
range of data.
* The header specifies which parts of the message it covers, these may
be the body, the content meta-data headers or the method and (part) of
the canonicalized URI.

So if we have a message

GET /foo/part HTTP/1.1
Host: Foobar
Content-Type: application/html

We might specify an integrity check on just the body, just the
metadata or both as follows:

Integrity: body ; ...
Integrity: meta ; ...
Integrity: body ; meta ; ...

If we want to sign the method line we might sign the whole thing
(including the Host part) or just the method and '/part' as follows:

Integrity: method;
Integrity: method=5;

The count in method is the part of the suffix that is in the scope of
the signature.

While playing with this scheme last night, I found that it is actually
rather nice to have multiple integrity checks, even if you are using
'fast' symmetric key, like I often do.

Signing content is a pain for a start, you have to cache the whole
message before you can start work. That is not a major hassle when you
are dealing with messages of a few hundred bytes like I usually do.
But one of the projects I want to work on now that I have a working
protocol compiler is to allow me to upload photos from my digital
camera to my server. Since I shoot RAW each of my pictures is 10Mb.
And I want a D800 which would make it even worse.

This is the type of application where REST style makes a lot of sense.
Put the commands in the method line and you can use the whole of the
body for the content being operated on. Separate integrity checks for
each means that a bogus request can be rejected before you have
accepted 10Mb of data.

[And no, I don't think a stateless protocol is the way to move data
objects that size. I am going to be implementing restart and such or
the new scheme is going to be as horrible to use in practice as the
EyeFi is. I also shoot video and those come in 2Gb chunks]

> It seems to me we shouldn't need two solutions to any given problem.

Transport and Message level security are two different beasts. You
cannot get non-repudiation at the transport layer for a start. Message
level security requires the involvement of the application.

> Soap's
> signatures and encryption of messages.

I think some of the SOAP stuff was designed for folk selling SOAP
platforms and consulting services necessary to make them work. Only it
didn't really take off because the whole edifice was too complex for
most people to want to bother with and so we have a fracture in the
Web Services world between the REST camp and the SOAP camp.

What I want to do is to make the division moot by arming the JSON/REST
camp with the same tools that the SOAP camp have always relied on :-)

> In the end http and soap at the
> message structure level have but a hairl's difference between them. It seems
> naively to me that I'd http were to take a step towards soap at that basic
> message structure level that other standardisation problems might become
> simpler to solve, and that the shared solution could facilitate an
> unwrapping of soap messages to be able to be sent potentially as first class
> citizens on the web... Although problems with WS-Addressing might be the
> first hurdle to cross.

Well SOAP really has its origins in COM. To understand SOAP
architecture you need to think about the problem 'how do I expose my
COM service as a Web Service'. That is why it needs all that mechanism
within mechanism and that is perfectly fine if your problem is how to
expose an existing COM service as a Web Service.

SOAP does not end up delivering value when you are designing a Web
Service protocol from scratch.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 26 Jul 2012 08:52:34 -0700

> accept the data (provided that the trusted intermediary

Well, there is trust and then there is trust.  I might trust an
intermediary to look at my data to determine if it contains bad stuff,
but I might not trust it to modify it.  One problem with the current
system is that you don't get to choose.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 26 Jul 2012 13:42:55 -0400

> system is that you don't get to choose.

Exactly.

If I have a purchasing system I want to have a split control so that a
purchase order requires an authorization by a manager and a
confirmation by the purchasing clerk.

The purchasing clerk (or rather their computer) needs to see the
contents of the purchase order but must not be capable of generating
orders by themselves. That leads to $15 million carbon credit frauds.

---

From: Mike Belshe <[email-masked]>
Date: Thu, 26 Jul 2012 10:52:11 -0700

On Thu, Jul 26, 2012 at 2:01 AM, Poul-Henning Kamp <[email-masked]>wrote:

> far

> to one hop which connects end to end, but other key-material models
No - its end to end- those in the middle cannot see the contents.    The
only ones that can see the content are the client and the origin server.
 This is the basic building block of e-commerce.

You're saying the CA system is so broken that every proxy has access to all
TLS traffic, which is provably false.

Mike

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 26 Jul 2012 18:17:23 +0000

In message <[email-masked]>

>TLS traffic, which is provably false.

How about we decide that you say what you want to say, and then I'll
say what I want to say ?

I'm sure it would work much better than you making claims about what
I am saying or not...