Charter and the NetFlix UC

[timeless]

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

[Ryan Sleevi]

Post by timeless
One thing that NetFlix brought up which I'm hitting in [1] is the
ability to enable public caching of "signed" content.
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);
}
}
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.

[Anders Rundgren]

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

Post by timeless
One thing that NetFlix brought up which I'm hitting in [1] is the
ability to enable public caching of "signed" content.
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);
}
}
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.

[Ron Garret]

Post by Anders Rundgren
I would personally have started with naive questions such as
"What's wrong with signText?"

For starters, it's not documented anywhere that I could find. domcrypt.org forwards to http://mozilla.ddahl.com/domcrypt/demos/demo.html, which gives a 404.

rg

[David Dahl]

Sorry about that, my server is being moved, in the meantime, check the demos code here:

https://github.com/daviddahl/domcrypt/blob/master/demos/demo.js#L47

All of the demos do not conform to the current spec. I am working as fast as I can to implement new code and new demos.

Cheers,

David

----- Original Message -----
From: "Ron Garret" <ron-***@public.gmane.org>
To: "Anders Rundgren" <anders.rundgren-***@public.gmane.org>
Cc: rsleevi+w3c-F7+***@public.gmane.org, public-identity-***@public.gmane.org
Sent: Friday, February 17, 2012 12:19:27 PM
Subject: Re: Charter and the NetFlix UC

Post by Anders Rundgren
I would personally have started with naive questions such as
"What's wrong with signText?"

For starters, it's not documented anywhere that I could find. domcrypt.org forwards to http://mozilla.ddahl.com/domcrypt/demos/demo.html, which gives a 404.

rg

[Anders Rundgren]

Post by Ron Garret

Post by Anders Rundgren
I would personally have started with naive questions such as
"What's wrong with signText?"

For starters, it's not documented anywhere that I could find.

Eh? I explicitly referred to the 1996 version:
https://developer.mozilla.org/en/JavaScript_crypto

Poorly documented but actually used and even requested:
http://www.google.az/support/forum/p/Chrome/thread?tid=3506388787b6fb7d&hl=en


domcrypt.org forwards to http://mozilla.ddahl.com/domcrypt/demos/demo.html, which gives a 404.

Post by Ron Garret
rg

[Ron Garret]

Post by Anders Rundgren

Post by Ron Garret

Post by Anders Rundgren
I would personally have started with naive questions such as
"What's wrong with signText?"

For starters, it's not documented anywhere that I could find.

https://developer.mozilla.org/en/JavaScript_crypto

Yes, I looked at that page. The only occurrence of the string "signtext" on that page is this:

DOMString signText(DOMString stringToSign,
DOMString caOption /* ... */);

And the only occurrence of the string "caOption" is in that excerpt as well. That is not what I would consider adequate documentation.

Post by Anders Rundgren
http://www.google.az/support/forum/p/Chrome/thread?tid=3506388787b6fb7d&hl=en

Look, you asked what was wrong with signText. That it is "poorly document" is one of the things that is (currently) wrong with it. The problem is not that it is impossible to do crypto in Javascript. Javascript is after all a Turing-complete language. The problem is that it is (currently) *hard* to do crypto in Javascript. And signText does not (currently) make it any easier, partly because it is not (currently) adequately documented.

It is possible that the solution to all our problems is simply to document signText. I doubt it, but if you disagree the way to resolve the dispute is not to argue about it but to go write some documentation.

rg

[Anders Rundgren]

On 2012-02-17 20:00, Ron Garret wrote:
<snip>

Post by Ron Garret
It is possible that the solution to all our problems is simply to document signText.

I just mentioned that there are a bunch of "standards" out there already.

If I were to create a standard I would begin with researching these to see
if there is something worth stealing :-)

https://github.com/daviddahl/domcrypt/blob/master/demos/demo.js#L47

I don't know how window.mozCipher.pk.sign works but signText(v1996) uses X.509
certificates which I believe what is generally requested.

Anders




I doubt it, but if you disagree the way to resolve the dispute is not to argue about it but to go write some documentation.

Post by Ron Garret
rg

[Ron Garret]

Post by Anders Rundgren
<snip>

Post by Ron Garret
It is possible that the solution to all our problems is simply to document signText.

I just mentioned that there are a bunch of "standards" out there already.

And what does the existence of "a bunch of standards" have to do with what is wrong with signText?

Post by Anders Rundgren
If I were to create a standard I would begin with researching these to see
if there is something worth stealing :-)

So, did you? Is there?

Post by Anders Rundgren
https://github.com/daviddahl/domcrypt/blob/master/demos/demo.js#L47

All I see is a bunch of uncommented Javascript code. How that is intended to address the issue that signText is undocumented I do not understand. I might be able to back out an API by reverse-engineering this code, but that would be missing the point rather badly.

Post by Anders Rundgren
I don't know how window.mozCipher.pk.sign works but signText(v1996) uses X.509
certificates which I believe what is generally requested.

Personally, I think X.509 is part of the problem, not the solution. But that is a different issue altogether.

rg

[Anders Rundgren]

Post by Ron Garret

Post by Anders Rundgren
<snip>

Post by Ron Garret
It is possible that the solution to all our problems is simply to document signText.

I just mentioned that there are a bunch of "standards" out there already.

And what does the existence of "a bunch of standards" have to do with what is wrong with signText?

Post by Anders Rundgren
If I were to create a standard I would begin with researching these to see
if there is something worth stealing :-)

So, did you? Is there?

It's called gap analysis and is a given task for a *proposer*.

Post by Ron Garret

Post by Anders Rundgren
https://github.com/daviddahl/domcrypt/blob/master/demos/demo.js#L47

All I see is a bunch of uncommented Javascript code. How that is intended to address the issue that signText is undocumented I do not understand. I might be able to back out an API by reverse-engineering this code, but that would be missing the point rather badly.

Post by Anders Rundgren
I don't know how window.mozCipher.pk.sign works but signText(v1996) uses X.509
certificates which I believe what is generally requested.

Personally, I think X.509 is part of the problem, not the solution. But that is a different issue altogether.
rg

[Ron Garret]

Post by Anders Rundgren

Post by Ron Garret

Post by Anders Rundgren
If I were to create a standard I would begin with researching these to see
if there is something worth stealing :-)

So, did you? Is there?

It's called gap analysis and is a given task for a *proposer*.

That's right. And are you not proposing something? (And if not, what are you doing?)

rg

[Anders Rundgren]

Post by Ron Garret

Post by Anders Rundgren

Post by Ron Garret

Post by Anders Rundgren
If I were to create a standard I would begin with researching these to see
if there is something worth stealing :-)

So, did you? Is there?

It's called gap analysis and is a given task for a *proposer*.

That's right. And are you not proposing something? (And if not, what are you doing?)

I'm reviewing the charter and some documents that
presumably was the background for it.

ar

Post by Ron Garret
rg

[David Dahl]

Also, the current (incomplete) draft spec for DOMCrypt is here:

https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

Here is the sign and verify interface:

interface CryptoSign {
void sign(ArrayBuffer keyID, ArrayBuffer plainText, PKSignCallback callback);
void verify(ArrayBuffer signature, ArrayBuffer pubKey, ArrayBuffer plainText, PKVerifyCallback callback);
};

The browser stores your signing keys outside the reach of the unprivileged content DOM, you only have to provide the ID of the keypair. This discussion is useful as I have not specified an additional method that will be needed:

void GenerateSignatureKeyPair(long aAlgorithm, CSGenerateKeyPairCallback callback); // the callback is handed a keyID and publicKey

The thinking right now is that this API is bound by the same-origin policy. Which I think makes sense in order to control the scope. I am not too worried about incompatibility with older, onerous standards that are not in widespread use anyway. Perhaps I am naive? No, I know am naive, that is the only way I could have proposed this API:)

Regards,

David

----- Original Message -----

Sent: Friday, February 17, 2012 1:35:10 PM
Subject: Re: Charter and the NetFlix UC

Post by Anders Rundgren
<snip>

Post by Ron Garret
It is possible that the solution to all our problems is simply to document signText.

I just mentioned that there are a bunch of "standards" out there already.

And what does the existence of "a bunch of standards" have to do with
what is wrong with signText?

Post by Anders Rundgren
If I were to create a standard I would begin with researching these to see
if there is something worth stealing :-)

So, did you? Is there?

Post by Anders Rundgren
https://github.com/daviddahl/domcrypt/blob/master/demos/demo.js#L47

All I see is a bunch of uncommented Javascript code. How that is
intended to address the issue that signText is undocumented I do not
understand. I might be able to back out an API by
reverse-engineering this code, but that would be missing the point
rather badly.

Post by Anders Rundgren
I don't know how window.mozCipher.pk.sign works but signText(v1996) uses X.509
certificates which I believe what is generally requested.

Personally, I think X.509 is part of the problem, not the solution.
But that is a different issue altogether.
rg

[Anders Rundgren]

Post by David Dahl
https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
interface CryptoSign {
void sign(ArrayBuffer keyID, ArrayBuffer plainText, PKSignCallback callback);
void verify(ArrayBuffer signature, ArrayBuffer pubKey, ArrayBuffer plainText, PKVerifyCallback callback);
};
void GenerateSignatureKeyPair(long aAlgorithm, CSGenerateKeyPairCallback callback); // the callback is handed a keyID and publicKey
The thinking right now is that this API is bound by the same-origin policy. Which I think makes sense in order to control the scope. I am not too worried about incompatibility with older, onerous standards that are not in widespread use anyway. Perhaps I am naive? No, I know am naive, that is the only way I could have proposed this API:)

David,

I'm fine with that, it is the following part which I have issues with and as far as I can see made it to the charter

https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest

<FROMTHESPEC>

Possible Additions

One possible addition we might consider is providing the web site with a secure mechanism having the user confirm a transaction. For example, a bank web site might wish to have the user sign a
statement authorizing the transfer of funds from one account to another. Unlike the DOMCrypt APIs described above, this API involves interacting with the user to achieve non-repudiation:
1.[Supplemental]
2.interface CryptoSign {
3.void signWithUserConfirmation(in ArrayBuffer keyID, in DOMString description, in ArrayBuffer data, in PKSignCallback callback);
4.};

The signWithUserConfirmation method causes the user agent to display some user interface element containing the human-readable description. If the user confirms the description, the user agent with
sign both the human-readable description and the binary data with the key designated by the keyId and supply the signature to the caller via the callback. There are still many details to work out,
such as the format of the signed message, but this description is a starting point for discussion.

to deploy this feature to production level, we have to consider following issues.

is passphase of private key safely entered?. means the confirmation screen need anti-keylogger mechanism.

</FROMTHESPEC>

My comments:

There is no passphrase for the keys provisioned by the rest of the API.
Is the user supposed to set the passphrase at his/her whim?
In the bank-world it is the bank who defines and enforces PIN policies.

BTW, anti-keylogger is a [desirable] platform characteristic.
It is not a part of any app-level standard mainly because it can't be
successfully dealt with at the app-level. "Trusted GUI" is a part of
efforts trying to create securer operating systems.

"KeyID", it comes from where?

In all, this design departs considerably from similar stuff that
actually is in pretty big use, onerous or not. They are either
server-based or client-based. The latter are as far as I know (been
into this since 1997) exclusively relying on users having X.509 certificates.

regards,
Anders

Post by David Dahl
David
----- Original Message -----

Sent: Friday, February 17, 2012 1:35:10 PM
Subject: Re: Charter and the NetFlix UC

Post by Anders Rundgren
<snip>

Post by Ron Garret
It is possible that the solution to all our problems is simply to document signText.

I just mentioned that there are a bunch of "standards" out there already.

And what does the existence of "a bunch of standards" have to do with
what is wrong with signText?

Post by Anders Rundgren
If I were to create a standard I would begin with researching these to see
if there is something worth stealing :-)

So, did you? Is there?

Post by Anders Rundgren
https://github.com/daviddahl/domcrypt/blob/master/demos/demo.js#L47

All I see is a bunch of uncommented Javascript code. How that is
intended to address the issue that signText is undocumented I do not
understand. I might be able to back out an API by
reverse-engineering this code, but that would be missing the point
rather badly.

Post by Anders Rundgren
I don't know how window.mozCipher.pk.sign works but signText(v1996) uses X.509
certificates which I believe what is generally requested.

Personally, I think X.509 is part of the problem, not the solution.
But that is a different issue altogether.
rg

[Richard Barnes]

Signing, by definition, uses private keys, which are associated to X.509 certificates; you cannot, however, sign something with a certificate.

To address your problem directly, there are a number of problems with signText(), mainly around the assumptions it makes:
-- The signing key is implicit (the key corresponding the client certificate used to load the page? a smart card key?)
-- The thing being signed is a DOMString, when it should be something like an ArrayBuffer

Note that the latter fix would also address your concerns about digital signature formats. If you can sign octets, then you can implement PDF signing or XAdES.

--Richard

Post by Anders Rundgren
<snip>

Post by Ron Garret
It is possible that the solution to all our problems is simply to document signText.

I just mentioned that there are a bunch of "standards" out there already.
If I were to create a standard I would begin with researching these to see
if there is something worth stealing :-)
https://github.com/daviddahl/domcrypt/blob/master/demos/demo.js#L47
I don't know how window.mozCipher.pk.sign works but signText(v1996) uses X.509
certificates which I believe what is generally requested.
Anders
I doubt it, but if you disagree the way to resolve the dispute is not to argue about it but to go write some documentation.

Post by Ron Garret
rg

[Anders Rundgren]

Post by Richard Barnes
Signing, by definition, uses private keys, which are associated to X.509 certificates; you cannot, however, sign something with a certificate.

I think we all know that. However, the corresponding certificate is usually supplied with the signed data.

Post by Richard Barnes
-- The signing key is implicit (the key corresponding the client certificate used to load the page? a smart card key?)
-- The thing being signed is a DOMString, when it should be something like an ArrayBuffer

You mean window.mozCipher.pk.sign() right?

Post by Richard Barnes
Note that the latter fix would also address your concerns about digital signature formats.
If you can sign octets, then you can implement PDF signing or XAdES.

I think you need to rephrase a bit. If you can sign *hashed data* you can do that.

Anders

Post by Richard Barnes
--Richard

Post by Anders Rundgren
<snip>

Post by Ron Garret
It is possible that the solution to all our problems is simply to document signText.

I just mentioned that there are a bunch of "standards" out there already.
If I were to create a standard I would begin with researching these to see
if there is something worth stealing :-)
https://github.com/daviddahl/domcrypt/blob/master/demos/demo.js#L47
I don't know how window.mozCipher.pk.sign works but signText(v1996) uses X.509
certificates which I believe what is generally requested.
Anders
I doubt it, but if you disagree the way to resolve the dispute is not to argue about it but to go write some documentation.

Post by Ron Garret
rg

[timeless]

Sorry for the delay. I've only had mobile devices for a while and have
been busy with trips and other work. My success record using Mobile
clients is clearly poor - I believe I accidentally sent at least one
blank response while just trying to correct the header fields using
this mobile mail client.

Post by Ryan Sleevi
Not to be dismissive,

That's quite alright.

Post by Ryan Sleevi
but there seems to be a whole lot of hand waving here,

I was only interested in describing roughly how the idea could work
from a consumer's perspective.

Post by Ryan Sleevi
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?

I'm pretty sure I don't have an initial opinion. Put differently: if
the working group is interested in furthering an API like this, I
trust the WG to make the right decisions.

Post by Ryan Sleevi
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?

While there is a code signing bit available, we don't typically use
that for Web pages ("web applications"). Is there some other
constraint that specifically interests you?  Not before / not after
should apply...

Post by Ryan Sleevi
Is it using CMS? PKCS#12? JOSE? Custom?

I haven't spent time reading about JOSE. Generally the web seems to
deal in PKCS12.

Post by Ryan Sleevi
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."

I expect that UAs could use soft-tokens, but I've definitely heard
what seemed to be requests for possibly somewhat constrained stuff.

Post by Ryan Sleevi
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.

Yes, it's quite possible that some work would need to be done in another group.

Post by Ryan Sleevi
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,

Given the available W3 WGs, would you rather such a thing be designed
in some other group? Of the available groups, this one seems to have
the right people (being skeptical is important, much better than
gung-ho), and it had a charter under discussion.

Post by Ryan Sleevi
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.

There's a real risk that some vendors will go off and do their own
thing because there's a need, and if there isn't a group interested in
working on standardization, the result will probably be poor, painful,
and yet something everyone will be forced to implement.

Post by Ryan Sleevi
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)

IETF has absolutely nothing to do with DOM.

Post by Ryan Sleevi
and WebAppSec (Content Security Policy, etc), as you note.

What I saw was roughly people wanting to import blobs over e.g. http,
and somehow having established that they are "signed" by the "same"
signer, enable them to run in the same or some similar context.

Post by Ryan Sleevi
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.

I didn't claim the current draft supported the use-case. It's merely a
use-case that I see people wanting. There was a small window in which
the charter could have perhaps been adjusted to consider the UC as a
secondary or tertiary deliverable. I'm well aware that at this point
I've absolutely missed that window, and I'm sorry I didn't spend the
time earlier trying to compose a proper reply.

[timeless]

Post by timeless
One thing that NetFlix brought up which I'm hitting in [1] is the
ability to enable public caching of "signed" content.
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);
}
}
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

Post by timeless
--
Sent from my mobile device