Re: Charter and the NetFlix UC

On Thu, Feb 16, 2012 at 5:11 AM, timeless <timeless@gmail.com> wrote:

> One thing that NetFlix brought up which I'm hitting in [1] is the
> ability to enable public caching of "signed" content.
>
> Roughly, this is something like:
>
> getCachableBlobViaHttp(http_url, handleSuspectBlob)
>
> function handleSuspectBlob(suspectBlob) {
>  navigator.crypto.detaintWithSignatureCheckedAgainstCAList(suspectBlob,
> limitedListOfCAs, detaintCallback);
> }
>
> function detaintCallback(detaintedBlobOrNull, signingCert, suspectBlob) {
>  if (detaintedBlobOrNull) {
>  /* yay, the resource as  detaintedBlobOrNull can be used to not void
> the Blue/Green/Purple seal on our web page */
>  myImage.src = convertBlobToURL(detaintedBlobOrNull);
>  }
> }
>
> To make a purple state (instead of Blue/Green), I'm envisioning a call:
> navigator.crypto.loadPageWithStrictResourceSignatures(limitedListOfCAs,
> optionalURLdefaultingToCurrentURLifNull) which would cause the page to
> navigate to optionalURLdefaultingToCurrentURLifNull and the only HTML,
> CSS, or Images that could load would be from limitedListOfCAs. XHR to
> other resources would be allowed but would be tainting (breaking the
> purple seal) unless they were passed via
> navigator.crypto.detaintWithSignatureCheckedAgainstCAList.
>
> This isn't something I'm a big fan of, but I think it enables the UC
> that NetFlix has in mind as well as NFC cards...
>
> There's some overlap to WebApps or WebAppsSec and possibly HTML.
>
> Perhaps this sort of thing is already in scope for WebAppsSec - I
> haven't looked there....
>
> [1]
> http://lists.w3.org/Archives/Public/public-device-apis/2012Feb/0051.html
>
> --
> Sent from my mobile device
>
>
Not to be dismissive, but there seems to be a whole lot of hand waving
here, particularly around areas where many a standards battle has been
waged and won/lost (depending on which side you took).

For example, "detainWithSignatureCheckedAgainstCAList" can mean many
things. Should you apply PKIX rules? RFC 3280? 5280? Are you treating the
CAs as simply public-key-and-subject delivery mechanisms, or do you treat
them as public-key-and-subject-and-constraints? Is it using CMS? PKCS#12?
JOSE? Custom? Are you checking against the entire contents of the blob
(CMS-style signatures) or do you need to have media-type awareness so that
meta-data can be delivered in-band (Authenticode-style signatures).

Further, this idea of detainting something and blue/green/purple states
seems to go into the current out of scope list item of "functions in the
API that require smartcard or device-specific behaviour." At the last, a
sealed execution environment, or even just resource loading, seems to touch
much broader than just figuring how the crypto might deliver such sealed
resources.

I'm just trying to highlight that it's very easy for
"detaintWithSignatureChecked...", as some sort of intrinsic function as
part of the Web Cryptography API, can very easily spiral out of control, so
it might be in our best interest to work on the 'simple' things like
working out a basic API for signing/encrypting/hashing and the ability for
cryptographic agility before we work up to that point.

For the UX and page security of resource loading (either active or passive
content) and how that affects the execution environment, that's likely a
combined effort of the IETF's WebSec group (HTTP Strict Transport Security
and Certificate Pinning both come to mind) and WebAppSec (Content Security
Policy, etc), as you note. The fact that such a thing may be enabled by
crypto is somewhat secondary, and not really in scope for what at least the
draft charter is proposing.