Re: Proposal for ISSUE-25 (Globally unique pre-shared keys)

On Mon, Oct 29, 2012 at 9:07 AM, Mark Watson <watsonm@netflix.com> wrote:
>
> On Oct 29, 2012, at 4:10 PM, Ryan Sleevi wrote:
>
<snip>
>> That is, the language "pre-shared keys"
>> implicitly presumes (global? user-specific? multi-origin?) pre-shared
>> keys, and then describes a function on how to get "unique
>> origin-specific pre-shared keys".
>>
>> It seems to me that your requirements for both user-access and
>> derivation are thus *not* related to pre-shared/pre-provisioned keys,
>> but more generally concerns regarding keys shared between origins.
>> That's why I think it's a weird fit for where you put it.
>
> Ok, well, I could move it, or even remove it (the transformation) because it was just an example.

SHOULD is more than just an example. It's a language that says "This
is more or less a MUST, but we'll leave you a little bit of wiggle
room". An example, particularly one where there seem to be a large
number of use cases that run counter to it, would nominally be a MAY,
or simply called out as just that - an example.

If anything should be a SHOULD, it would seem like "ensuring the key
is unique per origin", but while I understand that intent, I'm not
sure it's well understood enough to include that as a SHOULD yet.

<snip>
>> Right - so this really is a distinction between origin-specific and
>> origin-shared keys, and not pre-shared vs generated keys.
>
> IIUC, you're suggesting that any key shared across origins could be made origin-specific with a technique like this. That's fine. I wouldn't even call that an origin-shared key because there's no difference (as far as applications are concerned) between this case and keys which are totally independent.
>
> There may be a difference as far as the user is concerned, as the user may know that both keys are ultimately generated from the same passphrase, for example.

That wasn't quite what I was suggesting, merely trying to make sure I
was understanding what *you* were suggesting :)

It seem(s/ed) to me like your construct regarding the function
transformation has *nothing* to do with pre-shared/pre-provisioned
keys, and is entirely about ensuring origin-unique keys are the only
keys used, which I'm not sure (yet) if it is workable.

To put differently, it seems your entire note about security is not
re: pre-shared keys, and is entirely about origin-specific keys - a
different (although possibly overlapping) class.

<snip>
>> I'm saying that the certificates associated with a key may not be
>> stored with the key itself, nor is it a static list. For example, new
>> certificates may be deployed via application/x-x509-user-cert (for
>> user agents supporting it) at any point. What is the value of the
>> attribute as keys are added? As they're removed?
>>
>> Does accessing the object force the user agent to query all (external)
>> certificate storage mechanisms to discover if any certificates have
>> been added or removed? I fear under the current language, it does, and
>> that's not an acceptable solution.
>>
>> Alternatively, it requires the user agent to store within its own
>> persistence store a static list of all associated certificates with a
>> key, and that's not a solution I can see as workable either.
>
> I didn't intend either of the above. The intent was that, for these pre-provisioned keys the UA would not even process the certificate - it's just a blob of bytes associated with the key and obtained from the same place the key was obtained from.

That isn't what I meant.

>
> I think having the UA maintain certificate chains, handle revocation, renewal and do the things above is a whole other topic.

That wasn't at all what I was suggesting.

>
> I'm assuming that this certificate is pre-provisioned, renewed etc. in the same way as the pre-provisioned key itself, not by the UA.

And I'm saying that the sources of storage for certificate is
different than the sources of storage for keys, that there may be more
certificates than keys, and that certificates may exist in multiple
storage systems that all have private keys in a single store element.

As I understand your proposal, you're trying to say that "Only the
certificate that is stored in the key storage is exposed", and I don't
think that's a particularly useful or complete API, nor do I think
it's compatible with the asynchronous interfaces being attempted here.
For the Key, none of the actual key storage needs to be communicated
with until a cryptographic operation begins (an asynchronous,
user-initiated event). The user agent meta-data about how a key can be
used can (and arguably SHOULD) be stored outside of key storage - in a
user agent maintained store.

Your proposal to expose certificates forces one of two things:
- Every time a Key object is created, the certificate(s) need to be
discovered from key storage (a blocking operation) and serialized into
the attribute
- The browser must cache the value of certificate(s) in browser
storage after obtaining them from key storage - which creates a cache
incoherency issue that I suspect is more common in practice than you
may realize.

That's why I object to certificates. I don't see blocking on key
storage (whether the place the key is directly stored, or all possible
key storage mechanisms) to discover certificates a viable option, and
I definitely know from experience that having the browser storage
cache certificates will lead to incorrect and user-unfriendly results.

<snip>
> I'm more than happy to talk about alternative APIs for exposing the certificate. I would say that I think the problem of exposing a certificate associate with a pre-provisioned key and maintained in the same way as the key itself is an easier task than more general handling for certificates. Particularly because that maintenance is than out of scope for us.

For the reasons above, I do not believe the pre-provisioned key is any
different than any other certificate management issues - in fact, the
issues are at the very heart the same. Coupling it to pre-provisioned
keys seems like an unnecessary bolt-on.

<snip>
>> Respectfully, I think the point "If the choices made by implementors
>> are arbitrary, then this is still useful" is wrong. I think arbitrary
>> choices make this useless and dangerous to the spec, because it
>> provides effectively no portability for implementations in terms of
>> something spec'd in the standard. This is exactly why we're trying to
>> define, as absolutely and concretely as possible, how RSA, AES, ECC,
>> etc are performed - so that they're compatible across implementations.
>
> There's an important difference. In the case of all the algorithms, if different implementors made different choices it would be very hard, if not impossible, for me as an application running on those implementations to accommodate those differences.
>
> This is not the case with choice of unique identities. I'm just going to provision those things into my back-end database. It doesn't matter what they are (within reason - if the identity was 2MB in size, that might be a problem), so long as I know their general properties (which I use to inform my offline decision on the authorization and other policies to apply to those devices).
>
> On the other hand, if we don't specify anything, then the choices of attribute will also be arbitrary and that is a problem for me to cope with on the application side.

Respectfully, you're proposing a solution that we have established, in
this thread, cannot be compatibly implemented between user agents, is
not required to be implemented, and, at least as far as user agents
attempting to use common cryptographic APIs without needing specific
knowledge of every individual secure element vendor and every
individual key provisioning scheme, cannot be implemented.

I think at the size and scope of our API, we absolutely MUST NOT be
introducing optional features without strong support within the
working group, from both implementors and users, as a must have
feature. We have established, in past threads, that this is absolutely
something that web developers can standardize independent of the W3C
process. If we have any hope of shipping a version 1 of this API (or
even a version 2), then I would again suggest we consider this out of
scope.

Considering our exit criteria include multiple interoperable user
agents implementations, I do not see how this criteria can be met with
your current proposal - and thus, would block the entire spec from
progressing. I do not want to see that happen. Without strong support
from potential user agent implementors (which so far, only Netflix has
been active in supporting this), it seems very likely that this will
be the blocking point.

I should note that I also would be very sad to see a "spec" that
contains 10 optional features, with exit criteria of two compatible
implementations *per feature*, and having 6 different user agent
implementations that collectively do not overlap on any two features.
That, to me, is a complete failure of the WG. I see proposing that
this be a detachable "feature" of the spec is to encourage that, even
more than the optional-to-implement algorithm specifications (which
already suffer from this problem).

<snip>
>> As an implementor, I think the only time the "uid" can be reasonably
>> exposed then is by Netflix and those working with Netflix.
>
> Well, this set includes all the major TV manufacturers, so we're talking 100s of millions of browser instances by the time this is implemented.
>
> Even accepting your position, you can extend to all other websites that also work with those manufactures, which now includes all the major streaming video providers.
>
>> The
>> proposed wording provides no guidance whatsoever for Mozilla,
>> Microsoft, Chromium, Apple, Opera, Intel, or any other potential
>> implementor.
>
> I disagree - see below.
>
>> It's fully compliant with the spec to not implement it.
>
> Right. That's what optional means ;-)

And we need fewer optional things.

>
>> It's fully compliant with the spec to implement different things.
>
> Yes and no. All implementations are different in some respects. Probably all distinct implementations of anything in the web platform have different behaviors in some aspect - performance for example - but that doesn't matter from an interoperability perspective except at the extremes.
>
> Similarly the differences in implementation that would be allowed under this proposal don't affect the usefulness of the feature, as I described above.

Please see above.

Received on Tuesday, 30 October 2012 10:28:40 UTC