http+aes

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

http+aes

Julian Reschke
Reply | Threaded
Open this post in threaded view
|

Re: http+aes

Poul-Henning Kamp
In message <[hidden email]>, Julian Reschke writes:

>FYI:
>
> http://dev.w3.org/html5/spec/Overview.html#http-aes-scheme

So you encrypt the response body with the password clearly visible in the
request, to gain privacy ?

Please explain what I'm overlooking here...


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


Reply | Threaded
Open this post in threaded view
|

Re: http+aes

Anne van Kesteren-2
On Mon, 05 Mar 2012 11:29:01 +0100, Poul-Henning Kamp <[hidden email]>  
wrote:
> In message <[hidden email]>, Julian Reschke writes:
>> FYI:
>>
>> http://dev.w3.org/html5/spec/Overview.html#http-aes-scheme
>
> So you encrypt the response body with the password clearly visible in the
> request, to gain privacy ?
>
> Please explain what I'm overlooking here...

I think the intent is that the user agent does the decryption and that  
therefore the key is not part of the request, but the specification is  
sort of vague / wrong on that it seems. Ian?


--
Anne van Kesteren
http://annevankesteren.nl/

Reply | Threaded
Open this post in threaded view
|

Re: http+aes

Julian Reschke
In reply to this post by Poul-Henning Kamp
On 2012-03-05 11:29, Poul-Henning Kamp wrote:

> In message<[hidden email]>, Julian Reschke writes:
>
>> FYI:
>>
>> http://dev.w3.org/html5/spec/Overview.html#http-aes-scheme
>
> So you encrypt the response body with the password clearly visible in the
> request, to gain privacy ?
>
> Please explain what I'm overlooking here...

Dunno; just forwarding.

You may want to send feedback to the HTML WG mailing list...

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: http+aes

Julian Reschke
On 2012-03-05 11:43, Poul-Henning Kamp wrote:

> In message<[hidden email]>, Willy Tarreau writes:
>
>> Being able to encrypt only the payload would be extremely useful in
>> server-to-server communications in datacenters.
>
> How usefull is it, when packet sniffing gets you both the key
> and the encrypted data ?
>
> I could understand it if the userinfo pointed to a PSK, but sending
> the actual AES key as part of the request defeats any attempt at
> privacy I can see ?

I think the confusion comes from embedding local information into the
URI; it seems the userinfo is not supposed to be transmitted on the
wire. (which of course raises the question about why it's in the URI then)

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: http+aes

Stefan Eissing
In reply to this post by Julian Reschke

Am 05.03.2012 um 11:43 schrieb Poul-Henning Kamp:
>
> I could understand it if the userinfo pointed to a PSK, but sending
> the actual AES key as part of the request defeats any attempt at
> privacy I can see ?


I assume the intention is to omit the userinfo in the request, as
it is done with the userinfo in the standard http scheme.

It would be interesting to hear more about the intended use scenario.
My gut feeling is that URIs are public by nature and like to be written
down.

Also, would the fragment identifier, given that a new scheme is introduced
anyway, not be a better place to store information for the client?

Cheers,

Stefan

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782




Reply | Threaded
Open this post in threaded view
|

Re: http+aes

Julian Reschke
On 2012-03-05 11:52, Stefan Eissing wrote:

>
> Am 05.03.2012 um 11:43 schrieb Poul-Henning Kamp:
>>
>> I could understand it if the userinfo pointed to a PSK, but sending
>> the actual AES key as part of the request defeats any attempt at
>> privacy I can see ?
>
>
> I assume the intention is to omit the userinfo in the request, as
> it is done with the userinfo in the standard http scheme.
>
> It would be interesting to hear more about the intended use scenario.
> My gut feeling is that URIs are public by nature and like to be written
> down.
>
> Also, would the fragment identifier, given that a new scheme is introduced
> anyway, not be a better place to store information for the client?
> ...

-1; fragment identifier semantics depends on media type, not protocol...

But yes, it's not entirely clear why this needs to be in the URI.

Reply | Threaded
Open this post in threaded view
|

Re: http+aes

Anne van Kesteren-2
On Mon, 05 Mar 2012 12:02:19 +0100, Julian Reschke <[hidden email]>  
wrote:
> But yes, it's not entirely clear why this needs to be in the URL.

If you don't tie it to the URL, you will have to change every API (<a>,  
XMLHttpRequest, <video>, <script>, ...) to also take a key.


--
Anne van Kesteren
http://annevankesteren.nl/

Reply | Threaded
Open this post in threaded view
|

Re: http+aes

Stefan Eissing
So the gist of http+aes is to URL-inject a Transfer-Encoding into the
existing http infrastructure?

//Stefan

Am 05.03.2012 um 12:08 schrieb Anne van Kesteren:

> On Mon, 05 Mar 2012 12:02:19 +0100, Julian Reschke <[hidden email]> wrote:
>> But yes, it's not entirely clear why this needs to be in the URL.
>
> If you don't tie it to the URL, you will have to change every API (<a>, XMLHttpRequest, <video>, <script>, ...) to also take a key.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782




Reply | Threaded
Open this post in threaded view
|

Re: http+aes

Yngve Nysaeter Pettersen
In reply to this post by Julian Reschke
On Mon, 05 Mar 2012 11:21:06 +0100, Julian Reschke <[hidden email]>  
wrote:

> FYI:
>
> http://dev.w3.org/html5/spec/Overview.html#http-aes-scheme

This definition (and the HTTPS+AES one) leaves a lot to be desired, IMO

* What are the use cases?

* Why is it better than using HTTPS? If the URL is sent over HTTPS you  
will very likely already have at least one persistent HTTP connection open  
to the server (assuming it is the same server) so establishing a new  
connection (same or different server) for this request is not going to  
increase performance. Even if no connections are open, for a properly  
configured server, reestablishing a SSL/TLS session is not going to take  
much longer (one extra roundtrip) and the entire request and response will  
be protected.

* What is the keymaterial? If the userinfo is the key, how is it encoded?  
Base64, hex, calculated (how?), or other format, and if so, where is the  
CTR nonce encoded? If userinfo is not the key, how is the userinfo used to  
obtain the the encryption key, and how is that information secured?

* If the keymaterial is intended for long-term usage by a single user,  
depending on storage methods, how is the keymaterial info migrated  
securely to a new client, either for parallel use in multiple clients, or  
system recovery?

* Given that this is probably going to be MITM vulnerable when used over  
plain HTTP, what should the client do if the URL is provided over HTTP (or  
included by reference in a document loaded over HTTP)? Refuse to perform  
the request, or go ahead anyway?

* How does this interact with other ongoing specification work, such as  
the Javascript Crypto APIs?

* How will this interact with clients that does not understand the URL  
scheme? It is quite possible that they will display the userinfo in the  
addressbar or the resulting error messages.



--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer     Email: [hidden email]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

Reply | Threaded
Open this post in threaded view
|

Re: http+aes

Julian Reschke
On 2012-03-05 13:51, Yngve Nysaeter Pettersen wrote:

> On Mon, 05 Mar 2012 11:21:06 +0100, Julian Reschke
> <[hidden email]> wrote:
>
>> FYI:
>>
>> http://dev.w3.org/html5/spec/Overview.html#http-aes-scheme
>
> This definition (and the HTTPS+AES one) leaves a lot to be desired, IMO
>
> * What are the use cases?
> ...

Indeed.

I intended the FYI mail to inform people about what's going on in HTML
land; not really to have the discussion over here.

I recommend sending feedback to the HTML WG mailing list...

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: http+aes

Karl Dubost-5
In reply to this post by Julian Reschke

Le 5 mars 2012 à 05:21, Julian Reschke a écrit :
> FYI:
> http://dev.w3.org/html5/spec/Overview.html#http-aes-scheme


A better link (or less browser killing) ;)
http://dev.w3.org/html5/spec/iana.html#http-aes-scheme

And the text (This is revision 1.5603. Editor's Draft 5 March 2012)

    12.6 http+aes scheme

    This section describes a URL scheme registration for the IANA URI
    scheme registry. [RFC4395]

    URI scheme name:
        http+aes

    Status:
        permanent

    URI scheme syntax:
        Same as http, with the userinfo component instead used for
        specifying the decryption key. (This key is provided in the form
        of 16, 24, or 32 bytes encoded as ASCII and escaped as necessary
        using the URL escape mechanism; it is not in the
        "username:password" form, and the ":" character is not special
        in this component when using this scheme.)

    URI scheme semantics:
        Same as http, except that the message body must be decrypted by
        applying the AES-CTR algorithm using the key specified in the
        URL's userinfo component, after unescaping it from the URL
        syntax to bytes. If there is no such component, or if that
        component, when unescaped from the URL syntax to bytes, does not
        consist of exactly 16, 24, or 32 bytes, then the user agent must
        act as if the resource could not be obtained due to a network
        error, and may report the problem to the user.

    Encoding considerations:
        Same as http, but the userinfo component represents bytes
        encoded using ASCII and the URL escape mechanism.

    Applications/protocols that use this URI scheme name:
        Same as http.

    Interoperability considerations:
        Same as http, but specifically for private resources that are
        hosted by untrusted intermediary servers as in a content
        delivery network.

    Security considerations:

        URLs using this scheme contain sensitive information (the key
        used to decrypt the referenced content) and as such should be
        handled with care, e.g. only sent over TLS-encrypted
        connections, and only sent to users who are authorized to access
        the encrypted content.

        User agents are encouraged to not show the key in user
        interface elements where the URL is displayed: first, it's
        ugly and not useful to the user; and second, it could be
        used to obscure the domain name.

        The http+aes URL scheme only enables the content of a
        particular resource to be encrypted. Any sensitive
        information held in HTTP headers is still transmitted in the
        clear. The length of the resource is still visible. The rate
        at which the data is transmitted is also unobscured. The
        name of the resource is not hidden. If this scheme is used
        to obscure private information, it is important to consider
        how these side channels might leak information.

            For example, the length of a file containing only
            the user's age in seconds encoded in ASCII would
            easily let an attacker watching the network traffic
            or with access to the system hosting the files
            determine if the user was less than 3 years old,
            less than 30 years old, or more than 30 years old,
            just from the length of the file. Padding the file
            to ten digits (either with trailing spaces or
            leading zeros) would make all ages from zero to
            three hundred indistinguishable.

            Another example would be the file name. Consider a
            bank where each user first downloads a "data.json"
            file, which points to some other files for more
            data, such that users in debt download a "debt.json"
            file while users in credit download a "credit.json"
            file. In such a scenario, users can be categorised
            by an attacker watching network traffic or with
            access to the system hosting the files without the
            attacker ever having to decrypt the "data.json"
            files.

        The security considerations that apply to http apply as well.
    Contact:
        Ian Hickson <[hidden email]>
    Author/Change controller:
        Ian Hickson <[hidden email]>
    References:
         The http URL scheme is defined in: http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging

--
Karl Dubost - http://dev.opera.com/
Developer Relations, Opera Software


Reply | Threaded
Open this post in threaded view
|

Re: http+aes

Ian Hickson
In reply to this post by Yngve Nysaeter Pettersen
On Mon, 5 Mar 2012, Yngve Nysaeter Pettersen wrote:
> >
> > http://whatwg.org/html#http-aes-scheme
>
> This definition (and the HTTPS+AES one) leaves a lot to be desired, IMO
>
> * What are the use cases?

The use case is being able to get private data from a provider A to a
client C via an untrusted intermediary B, where the lack of trust is
specifically over whether or not the intermediary will look at the data
(as opposed to whether they will attempt to manipulate the data, which
would be readily detectable and thus put an end to the A-B relationship
typically via a lawsuit). The use case is addressed by encrypting the
content before sending it to B (typically a CDN) and delivering the key
with any URL referring to that content directly from A to C.

For example, the content could be a movie. "A" would be a movie
distributor, "C" would be a consumer, and "B" would be a CDN. B is paid by
A to host the content, but B might have rogue elements who would take all
of the movie content and upload it to a copyright-violating community.

Another example would be YouTube with private videos. YouTube would like
to cache private videos at the edge of the network on CDNs, but might want
to use CDNs whose integrity is not entirely trusted.

Similar situations exist with other content types.

In both cases, this solution addresses the problem by encrypting the
content at B (the CDN) such that the CDN cannot make use of the files, and
serves the key directly from A's servers.

(We don't generally include rationale in the HTML spec, for practical
reasons, though if anyone is interested in working with us to document
them I'd be happy for the help; contact me off-list.)


> * Why is it better than using HTTPS?

The attack scenario is that the CDN itself isn't trusted not to look at
the data. HTTPS only helps with on-the-wire attack scenarios.


> If the URL is sent over HTTPS you will very likely already have at least
> one persistent HTTP connection open to the server (assuming it is the
> same server) so establishing a new connection (same or different server)
> for this request is not going to increase performance.

Relative to the current setup, there are no additional connections; the
only difference is that the content at B (the CDN) is encrypted.


> * What is the keymaterial? If the userinfo is the key, how is it
> encoded? Base64, hex, calculated (how?), or other format

The key is the userinfo value. (It's escaped in the URL, using the normal
URL escaping rules.) I believe this is clear in the spec; let me know if
the current text is ambiguous on this.


> where is the CTR nonce encoded?

The key is fresh per resource, so there's no need for a nonce, so it's
zero. I've clarified this in the spec.


> * If the keymaterial is intended for long-term usage by a single user,
> depending on storage methods, how is the keymaterial info migrated
> securely to a new client, either for parallel use in multiple clients,
> or system recovery?

There is typically going to be one key per encrypted resource. It is
transmitted to the client with the URL; in normal operation, this would be
done over HTTPS, from A to C directly. I'm not aware of a use case where
it would need to be stored for long-term usage.


> * Given that this is probably going to be MITM vulnerable when used over
> plain HTTP, what should the client do if the URL is provided over HTTP
> (or included by reference in a document loaded over HTTP)? Refuse to
> perform the request, or go ahead anyway?

Anything transmitted over HTTP over an untrusted network is unsafe.
There's not really anything more serious here than generally. It would be
impossible to generically determine if the URL was obtained over encrypted
channels or not (e.g. consider a URL constructed from parts obtained
using XMLHttpRequest over both encrypted and unencrypted channels), so I
don't think there's much point trying to block this.


> * How does this interact with other ongoing specification work, such as
> the Javascript Crypto APIs?

It does not, as far as I can tell. I'd be happy for this feature to be
moved to a more appropriate spec if there is one, though.


> * How will this interact with clients that does not understand the URL
> scheme?

They won't be able to access the content.


> It is quite possible that they will display the userinfo in the
> addressbar or the resulting error messages.

Displaying the userinfo to the user isn't particularly bad (it's random
data, and the user is implicitly trusted with it anyway). Other attack
scenarios in this situation seem like they'd apply to any bogus URL, and
would need addressing independent of this scheme.


I believe this answers all the technical questions on this thread so far,
let me know if I missed any.

Cheers,
--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

Re: http+aes

Poul-Henning Kamp
In message <[hidden email]>, Ian Hick
son writes:

>For example, the content could be a movie. "A" would be a movie
>distributor, "C" would be a consumer, and "B" would be a CDN. B is paid by
>A to host the content, but B might have rogue elements who would take all
>of the movie content and upload it to a copyright-violating community.

I'm sorry, but IMO this is just security-theater, and it represents
so terrible handling of key-material that it is deeply irresponsible
to even mention it in a standards document, without a lengthy list
of caveats and disclaimers.

Somebody should point Bruce Schneier at this, he needs a good laugh...

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


Reply | Threaded
Open this post in threaded view
|

Re: http+aes

Poul-Henning Kamp
In reply to this post by Julian Reschke
In message <[hidden email]>, Willy Tarreau writes:
>On Mon, Mar 05, 2012 at 06:09:35PM +0000, Poul-Henning Kamp wrote:

>Example :
>    Content-Encoding: aes-ctr-128; keyid=0x34751806
>    Cache-control: no-transform
>
>This has the benefit of working out-of-the-box without affecting existing
>intermediary components.

That doesn't really improve the crypto scheme or key-handling in
any meaningful way.

It does make it slightly less hackish as HTTP considered.

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


Reply | Threaded
Open this post in threaded view
|

Re: http+aes

Stefan Eissing

Am 05.03.2012 um 22:41 schrieb Poul-Henning Kamp:

> In message <[hidden email]>, Willy Tarreau writes:
>> On Mon, Mar 05, 2012 at 06:09:35PM +0000, Poul-Henning Kamp wrote:
>
>> Example :
>>   Content-Encoding: aes-ctr-128; keyid=0x34751806
>>   Cache-control: no-transform
>>
>> This has the benefit of working out-of-the-box without affecting existing
>> intermediary components.
>
> That doesn't really improve the crypto scheme or key-handling in
> any meaningful way.
>
> It does make it slightly less hackish as HTTP considered.


Something along the lines of

Link: <https://serverA/keys/1234>; rel="content-decryption"

would expose the key only to parties authorized to retrieve it. If the
client sends the resource URL in the referer header, then the key url
does not need to be specific even, but the matching key could be
selected by serverA.

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782




Reply | Threaded
Open this post in threaded view
|

Re: http+aes

Ian Hickson
In reply to this post by Poul-Henning Kamp
On Mon, Mar 5, 2012 at 10:09 AM, Poul-Henning Kamp <[hidden email]> wrote:

I'm sorry, but IMO this is just security-theater, and it represents
so terrible handling of key-material that it is deeply irresponsible
to even mention it in a standards document, without a lengthy list
of caveats and disclaimers.

Could you elaborate on this? In particular, what risks do you believe exist here given the scenario this is intended to address and given the list of issues to consider already given in the specification?

I'm eager to address any problems that exist with this proposal, but I am failing to reconcile the proposal as I understand it with your assessment of it above.

--
Ian Hickson
Reply | Threaded
Open this post in threaded view
|

Re: http+aes

Ian Hickson
In reply to this post by Ian Hickson
On Mon, 5 Mar 2012, Willy Tarreau wrote:

>
> I wouldn't go to such extremities, but at least I think that we're just
> facing a layering violation. Only the contents have to be encrypted so
> that the caches cannot use them, while the transport remains unchanged.
> So a new scheme is not appropriate for this, a Content-Encoding would be
> much better. User agents would be configured to know that content-
> encoding XYZ requires a deciphering key whose ID is presented in the
> header itself and should have been retrieved via another channel.
>
> Example :
>     Content-Encoding: aes-ctr-128; keyid=0x34751806
>     Cache-control: no-transform

This would require changes at the intermediaries. It would also require a
mechanism to link keys to IDs, which is non-trivial given the same-origin
policy, multiple browsing contexts, subresources, etc.


> This has the benefit of working out-of-the-box without affecting
> existing intermediary components.

It would seem to me to require slightly more effort than the scheme
approach on this front.


(We did actually consider something like this.)

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Reply | Threaded
Open this post in threaded view
|

Re: http+aes

Poul-Henning Kamp
In reply to this post by Ian Hickson
In message <[hidden email]>
, Ian Hickson writes:

>> I'm sorry, but IMO this is just security-theater, and it represents
>> so terrible handling of key-material that it is deeply irresponsible
>> to even mention it in a standards document, without a lengthy list
>> of caveats and disclaimers.
>
>Could you elaborate on this? In particular, what risks do you believe exist
>here given the scenario this is intended to address and given the list of
>issues to consider already given in the specification?

The major risk is that people understand neither how little privacy
this buys them, nor how trivially easy it is to compromise that
privacy accidentally.

The proffered strawman about copyright protection is not credible:

You cut and paste the link, and anybody who receives it can view
the copyrighted object, and you have no idea who leaked it.

That's pretty much exactly what the Copyright-Monopolies try to
avoid, they want per-licensed-copy unique links, so the can see
who copy&pasted it.

There is no way to salvage this, if you do not strengthen the
key-handling.

If instead of the actual key, you provided the identifier for a
pre-shared key, to be read from local storage on the client machine,
then the link would not work for anybody who didn't have the
pre-shared key in their "secrets" file.  (If you label the keys
individually per licensee, and you can see who tried to leak the
non-working links of you want to.)

That of course means that you need to provide a way to pre-share
the keys, and yes, that means that it will not work "by magic"
without user-involvment, but that is exactly what is necessary to
make this more robust:  You want people to realize that this is
secret key-material, you don't want to, as proposed, not even make
the user aware that it is there in the first place.

Trying to get benefits from crypto while trying to hide the fact
that it is not there, does not work, if people don't know it is
there, they don't know that they have to be careful not to break it.

Another problem is that this scheme does not offer any integrity.

Your malicius CDN could truncate your object and you would never
notice that the last 2 pages of the contract are missing.

Having been through the mill a couple of times myself, I can not
recommend strongly enough, that you try to get at least one
card-carrying cryptographer to go over the key-handling and the
cryptographic operations, before you try to standardize anything
involving a cryptographic algorithm.

Do it right, there are no workable shortcuts in crypto.

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


Reply | Threaded
Open this post in threaded view
|

Re: http+aes

Ian Hickson
On Tue, 6 Mar 2012, Poul-Henning Kamp wrote:
>
> The major risk is that people understand neither how little privacy this
> buys them, nor how trivially easy it is to compromise that privacy
> accidentally.

It's not intended that users even know this is being used, so it doesn't
really matter if they don't understand it.


> The proffered strawman about copyright protection is not credible:
>
> You cut and paste the link, and anybody who receives it can view the
> copyrighted object, and you have no idea who leaked it.

This is not intended for a situation where you do not trust the
recipients, indeed. There's not really any credible way to give someone
content that isn't watermarked in some way if you don't trust them. If the
content _is_ watermarked, then you probably can't usefully cache it in a
CDN. If you can, then you can do so with this mechanism as well, it's an
orthogonal concern.


> Trying to get benefits from crypto while trying to hide the fact that it
> is not there, does not work, if people don't know it is there, they
> don't know that they have to be careful not to break it.

Let's be honest, most users have no idea what crypto is, let alone that it
is there. Even things as critical as TLS as used for HTTPS -- most users
don't really know what's going on. If we're going to rely on users
understanding crypto, we might as well give up now.


> Another problem is that this scheme does not offer any integrity.
>
> Your malicius CDN could truncate your object and you would never notice
> that the last 2 pages of the contract are missing.

In practice, a CDN would not keep its business if it was damaging the
content it was caching. This is a substantially different risk than the
CDN (or a rogue agent within the CDN) just copying the content.

There's no reason this mechanism couldn't be used with other generic
integrity checking mechanisms, though.


> Having been through the mill a couple of times myself, I can not
> recommend strongly enough, that you try to get at least one
> card-carrying cryptographer to go over the key-handling and the
> cryptographic operations, before you try to standardize anything
> involving a cryptographic algorithm.

This isn't my first barbecue either.

--
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

123