- From: timeless <timeless@gmail.com>
- Date: Fri, 16 Mar 2012 00:59:39 -0400
- To: public-identity <public-identity@w3.org>
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.
On Thursday, February 16, 2012, Ryan Sleevi <rsleevi+w3c@chromium.org> wrote:
> Not to be dismissive,
That's quite alright.
> 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.
> 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.
> 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...
> Is it using CMS? PKCS#12? JOSE? Custom?
I haven't spent time reading about JOSE. Generally the web seems to
deal in PKCS12.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
> 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.
Received on Friday, 16 March 2012 05:00:07 UTC