Re: Charter and the NetFlix UC

Ryan,
I fully agree with your analysis of the NextFlix UC.

However, the current charter's signed financial transactions
opens an even bigger can of worms which may very well sink the
rest of the effort.  The problem is as I see it that there already
are a lot of local/national/community standards in place as well
as several proprietary alternatives.  There is also signText ()
which has been available in Navigator/Firefox since 1996 or so.
I would personally have started with naive questions such as

      "What's wrong with signText?"

to see where that had taken me.  In the EU XAdES has become the
signature format of choice.  Signed PDF is though by far the most
popular format.  It is hard to see how this fits DOMCrypt's JSON-
centric world.

Anders

On 2012-02-16 20:29, Ryan Sleevi wrote:
> On Thu, Feb 16, 2012 at 5:11 AM, timeless <timeless@gmail.com <mailto: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.

Received on Friday, 17 February 2012 12:52:45 UTC