- From: Mark Watson <watsonm@netflix.com>
- Date: Wed, 22 Aug 2012 00:15:55 +0000
- To: Ryan Sleevi <sleevi@google.com>
- CC: Web Cryptography Working Group <public-webcrypto@w3.org>
On Aug 21, 2012, at 4:09 PM, Ryan Sleevi wrote:
> On Tue, Aug 21, 2012 at 3:29 PM, Mark Watson <watsonm@netflix.com> wrote:
>>
>> On Aug 21, 2012, at 2:32 PM, Ryan Sleevi wrote:
>>
>>> <snip>
>>
>> MW> Ok, to clarify, either of the following things would be sufficient:
>>
>> (1) Keep KeyAttributes and add text defining that for pre-provisioned symmetric keys the associated identity should appear as a read-only entry in the KeyAttributes (we can discuss later whether we need to define the name for that attribute or whether that is implementation-specific).
>
> I think we're still at a disconnect on whether every pre-provisioned
> symmetric keys actually needs an associated identity, so I think I'd
> still suggest that's an implementation specific detail.
See below about whether an associated identifier is always needed.
Either way, there's a huge gap between "not every application needs X" and "X is application- or implementation- specific".
Generally something is left implementation-specific if there are many ways to achieve the same thing without the application needing to care which way is chosen. Application-specific would mean there is essentially only one application with that requirement.
Neither of those apply here.
>
> However, I think if the WG decides we should - and to be clear, I
> think this use case is a very compelling use case about why we do, and
> why existing key/value stores are insufficient - then I would think
> it'd be sufficient to describe that there may be attributes that are
> read-only, as was discussed at the face-to-face.
>
> Since the provenance of the (some) pre-provisioned keys is contingent
> upon (device manufacturer, existing business relationships, user
> interaction, etc), it would seem that a web application (content
> script or host) already has some a-priori knowledge about what
> constitutes an identity, thus have an idea of how that identity is
> exposed via the API.
Yes, but it would be arduous for the script to have to support many different ways to expose the same identity, if each manufacturer chose a different way.
>
> To be clear, what I really, really don't want to see, is the spec
> saying something like "For pre-provisioned symmetric keys, all keys
> must have an attribute named 'identity' which exposes a 128-bit
> sequence that uniquely identifies the keys source. If the key is
> derived from a master key, this sequence will contain the identifier
> of the master key.' or whatever.
How about "If supported, pre-provisioned symmetric keys may be accompanied by a globally unique, origin-specific, identifier which should be exposed as a key attribute with named 'id'".
It should always be origin-specific, never the identifier of the master key if that exists.
>
> As you point out, not every 'pre-provisioned' key is going to be a
> device key. It might have been imported by the user, possibly from
> another user agent. It might be present on a smart card or secure
> element. It might have been stored within the OS before the user agent
> was installed. Thus, even the notion that the user agent has access to
> such an identity is, at best, a stretch.
Some will, some won't.
>
> If Netflix (or more likely, their device manufacturers) wanted to
> expose device unique keys, then I would propose that they could
> together propose text on how devices supporting such keys
> 1) Be exposed to user agents
> 2) Be exposed to web applications if supported by user agents.
> Including, but not limited to:
> 2a) Their presence in window.crypto.keys (or some other object that
> implemented the KeyStorage interface)
> 2b) The presence of read-only KeyAttributes
> 2c) Optionally, the 'well-known names' of these attributes, along
> with their possible values
>
> Such an effort would be complementary to the Web Crypto API, but not
> an essential part of it for implementers. That seems to highlight your
> remarks as an "optional" piece.
>
> I would rather the spec, to the degree possible, focus entirely on the
> mandatory parts that MUST be implemented by conforming user agents.
> That is, this is how the interfaces MUST behave and this is what MUST
> be exposed, and to the best degree possible, avoid any MAY language.
I appreciate the desire to maximize the normative mandatory capabilities and minimize the normative optional capabilities. But there are inevitably going to be normative optional capabilities (as you say, "UAs MAY implement X like this…" means either you don't implement it or you implement exactly what is specified.).
There may be advantage in editorially separating the normative mandatory from the normative optional. Maybe separate documents, maybe a separate section in our one document. Normative mandatory parts will likely be implemented first. This is something we should discuss with the group. But it's unrealistic that the normative optional set is empty.
I'm perfectly happy to propose text as you describe above for the normative optional part, but it should be part of our activity here, not outside the W3C.
>
> To that end, I would go as far to suggest that the algorithm
> specifications could/should be themselves supplementary documents (eg:
> IF you're going to implement AES, THEN this is how it MUST look). This
> is also why I have trouble normatively spec'ing something as "MAY" -
> including pre-provisioned keys - since the value added compared to the
> complexity and inflexibility is, I believe, not worth it. The fact
> that it can exist and conform to the API is useful, but until we
> actually have implementations doing it, or more participants with this
> particular use case, I'd really like to avoiding spec'ing how it MUST
> work when it MAY be implemented.
>
> My desire for doing so is to reduce as much as possible what the spec
> normatively require (including optional parts, which are still
> normatively spec'd), and then enhance and refine as the spec is
> implemented and adopted, rather than trying to do a monolithic spec
> that accomplishes all use cases but at the risk of spending another
> year hammering out details for edge cases that may or may not be
> adopted.
>
>>
>> or
>>
>> (2) Remove KeyAttributes (in favor of Local Storage for application-defined attributes) and define an alternative way to obtain the identity associated with a PSK (could be a new attribute on Key, or something else well-defined, I don't much mind. I just want it to be defined, not left as implementation-specific).
>>
>> btw, I agree this has implications for progression to FPWD, but not that it can prevent implementation, since supporting PSKs should be optional.
>>
>>>
>>>>
>>>>
>>>> It's in the implementation gray area - there's nothing in LocalStorage
>>>> or in IndexedDB preventing pre-provisioning either. Politics of
>>>> specifying another WG's interface aside, if we accept that
>>>> pre-provisioned keys are a detail that user agents may or may not
>>>> implement, and that the knowledge about whether the keys were or were
>>>> not pre-provisioned relies on the peer (the web application) having
>>>> some out-of-band knowledge, then it seems reasonable to think that the
>>>> user agent and the web application could cooperate on any Web Platform
>>>> API, to the betterment or worsening of the platform.
>>>>
>>>>
>>>> I don't think that's sufficient. The specification needs to say how
>>>> pre-provisioning will look to the script, not least so that the script can
>>>> tell if pre-provisioned keys are present (for its origin).
>>>>
>>>> An application using PSKs will have out-of-band knowledge of those identity
>>>> and key values and properties of the devices they were pre-provisioned into,
>>>> but a script running on a device has no idea what kind of device that is and
>>>> whether it has pre-shared keys. If I have to work with N different ways keys
>>>> and their identities are pre-provisioned for N different devices then I'd
>>>> need to trial-and-error through all those options when starting my script.
>>>> Even if I did know the type of device, I'd have to code N different
>>>> approaches.
>>>>
>>>> So, I don't think it should be left implementation-dependent.
>>>>
>>>>
>>>>
>>>>
>>>> That said, is there any reason why such an ID needs to be any
>>>>
>>>> different from any other pre-provisioned attribute?
>>>>
>>>>
>>>> What other pre-provisioned attributes ?
>>>>
>>>>
>>>> Whatever a user agent that wishes to implement pre-provisioning may support.
>>>>
>>>>
>>>> Ok, so that should be standardized, for the reason above.
>>>
>>> I'm having trouble interpreting your response.
>>>
>>> Is this a request then that, under ISSUE-17, there be explicit Key Attributes?
>>>
>>> Or are you proposing that a new WebIDL needs to be introduced to address this.
>>
>> MW> Either. See above.
>>
>>>
>>>>
>>>>
>>>>
>>>> Is this really a
>>>>
>>>> question about unique IDs (as has been framed by yourself and Mitch
>>>>
>>>> several times), or can your need simply be addressed by having
>>>>
>>>> whomever is doing the pre-provisioning of keys (an industry and
>>>>
>>>> application-specific act) also provision those attributes?
>>>>
>>>>
>>>> Where ? As I've said, pre-provisioning of Local Storage is not something
>>>> mentioned in the Local Storage specification and may be viewed as rather
>>>> odd.
>>>>
>>>>
>>>>
>>>> I'd like to focus on this specific point, since I strongly feel the
>>>>
>>>> needs you have identified are already readily addressed by the spec,
>>>>
>>>> and what you're wanting to do is already possible, and without having
>>>>
>>>> to introduce any special handling for pre-provisioned keys, nor
>>>>
>>>> require any language changes to the spec.
>>>>
>>>>
>>>> Could you explain in more detail why you believe that ?
>>>>
>>>>
>>>> I am beginning to feel that we need a specific section on pre-provisioned
>>>> keys, since there's clearly a wide variance in the assumptions people have
>>>> about them.
>>>>
>>>>
>>>> Text welcome at an informative level, but again, I think that
>>>> pre-provisioning is a concept that is inherently non-portable. It may
>>>> simply be sufficient to describe it as "It can happen". Much like the
>>>> only discussion about platform-originated keys (eg: native keys) are
>>>> only mentioned in the Scope section, as informative, and as a
>>>> security/privacy concern. I see pre-provisioned keys as being a
>>>> function of 'native cryptographic module' (eg: they weren't expressly
>>>> requested by the web application), but perhaps that's a semantic
>>>> distinction that isn't shared.
>>>>
>>>>
>>>>
>>>> To be completely unambiguous: pre-provisioned keys are inherently
>>>>
>>>> implementation specific, and thus I believe any attempt to define a
>>>>
>>>> common nomenclature for them is fatally flawed.
>>>>
>>>>
>>>> I disagree. The notion of a pre-provisioned symmetric key with an associated
>>>> identity is straightforward and application-independent and we can easily
>>>> specify is, just as is done for TLS PSK. Just because it is an optional
>>>> feature doesn't make it's definition 'implementation-specific'.
>>>>
>>>>
>>>> In my original message, I provided examples of exactly how it is
>>>> application dependent.
>>>>
>>>>
>>>> And I described why your examples were not quite correct: how a key is
>>>> pre-provisioned is device-manufacturer specific (not application specific).
>>>> How a key identity is shared with an application is an agreement between
>>>> device manufacturer and application provider (you could call that
>>>> application-specific). But what a pre-provisioned key *is* and the fact that
>>>> it needs to be accompanied by an identity, are generic and universal.
>>>
>>> I'm sorry, but I believe we're talking past eachother.
>>>
>>> Let me try to be clear: Anything that is not part of the user-agent
>>> behaviour, but instead particular to an "application" (in this case,
>>> "Netflix", in their entire client and server implementation and
>>> deployment), is what I call "application specific".
>>
>> MW> Sure. But I don't think the concept of pre-provisioned symmetric keys falls into that category. Such keys are very common in the world across very many domains and applications.
>>
>>>
>>> Not every use of pre-provisioned keys is going to rely on device
>>> manufacturers. Therefore, not every pre-provisioned key is
>>> manufacturer specific.
>>
>> MW> Agreed. I give device manufacturers as one example of the source of pre-provisioned keys. Keys on smartcards are also a form of pre-provisioned key. If they're symmetric they have an associated identity and this time the application provider needs to get the ( identity, key ) pairs from whomever provisioned the smartcard.
>
> No, they don't always have an associated identity.
>
> While I agree that, in order to effectively use symmetric keys, you
> need to know which key you're talking with, I disagree that "identity"
> is instrinsic to all symmetric keys, and equally disagree that it's
> intrinsic to even the subset of symmetric keys that are
> pre-provisioned.
MW> What I mean is that some way to identify the key being used to the server is needed. I think we agree on that.
I agree to that there are several ways to do that. But if we restrict to the cases where you actually need the properties that come with a pre-shared symmetric key (compared to a client generated one) and we want a generic solution, we end up with an identity as I proposed. See below ...
>
> The concept of "identity" is context dependent. In some, it might be
> free of any associated (key) metadata, because it's implied by other
> context (for example, the username the user logs in as, or, as in
> IPSec, the IP of the peer). For some, it might be contingent upon some
> explicit meta-data, such as a symbolic name ('foo-key') or other
> scheme ('1, 2, 3'), that are not in themselves unique, but combined
> with other signals (again: username, ip, some cookie presented by the
> user), represent a unique-to-the-peer identity.
>
> As what I believe is proof of why this is not intrinsic to the key,
> one could easily imagine a scenario where these TV manufacturers
> extended the window object with "device ID" - eg: an origin could
> access window.deviceid and get a unique ID for the device.
MW> This would certainly be a solution for a subset of use-cases. It addresses cases where there is a single monolithic "device" and the key is bound to that (= difficult to extract from that device). Certainly this is the case today for TVs etc.
But it is not a generic solution. There are an increasing number of devices containing more and less secure components. For example one processor running a general-purpose OS and another (possibly virtual) running a secure OS that is responsible for media decryption, decoding etc.
A pre-provisioned key in the secure component should have an identifier that identifies that secure component, not the whole device, since it would be relatively easy to migrate that component into another device (virtually, if not physically).
The point is that the identifier should be associated with the key, in that it is something which identifies the component to which that specific key is bound.
I appreciate that one can imagine use-cases for pre-shared symmetric keys where there is no such binding (i.e. it is easy to extract the key). But in this case I question whether this key has any properties that are different from a client generated one ? If there is a binding then it is a binding to *something* and that something needs to be identified.
I don't propose to specify what form that identifier takes, but it certainly exists.
>
> If an application submitted this as part of a request, along with a
> message encrypted with a pre-provisioned key, then the choice of which
> key to use would be implicit from the context of the message.
>
> Different applications have differing needs for such context, nor does
> every key (pre-provisioned or not) have the same context requirements.
> That's why I have trouble with the notion of identity as a functional
> attribute of the key.
>
> TLS-PSK decided to make the context explicitly supplied by the peer.
> IPSec chose to make the context implicit, based on the identity of the
> peer. TLS-SRP, which also uses a pre-shared key (the user's password)
> chose to make the identity an explicit username, which is an attribute
> not necessarily stored by the client. These are just three examples
> that show why not all pre-provisioned/pre-shared keys need to have
> explicit identifiers associated with them, but they MAY.
But in all these examples there exists (implicit or explicit) some kind of identifier which identifies the place(s) where the pre-shared key has been stored. The user's password is stored in their brain (hopefully, or on a piece of paper they own) and the brains of people they've told. This set of places is identified by their username.
In all cases, whomever provisions the pre-shared keys needs to tell both the keys and their associated identifiers to the server side.
It's key to my argument that in using PSKs there's an intention to make use of the binding between the keys and the place they are pre-provisioned to. So you need an identifier for that place. It's a physical place to which the UA has access. It's not restricting or app-specific to expose the identifier for that place in all cases.
If you *don't* intend to make use of that binding - if the key you pre-provision is also stored somewhere else (like the user's brain) - then you're right that there isn't a single identity. But why do you want to do that ? You might as well just import the key through the API.
But anyway, at the very least it will be very common that when using PSKs you want to identify the place it is stored and there does exist an explicit identity for this (the one you give out-of-band to the server). It's a simple and generic solution to expose this.
…Mark
>
>>
>>> For Netflix, every device manufacturer is
>>> responsible for pre-provisioning keys. Therefore, it is
>>> manufacturer-specific. However, because this is specific to Netflix
>>> and the ecosystem of manufacturer relationships they have developed,
>>> and thus not applicable to say, OTR messaging or Google Mail, it is
>>> application-specific.
>>
>> MW> I am not trying to embed anything specific to our business relationships in the spec. This is an example of how pre-provisioned symmetric keys are used, but it is not the only way and I'm not proposing anything specific to how we do it.
>>
>> If Google Mail wanted to use pre-provisioned symmetric keys they would have the same need to obtain the keys and their associated identities from whomever was provisioning them. The businesses and their relationships may be application-specific, completely different from Netflix, but the need for the keys and their identities to be discoverable on the API is not.
>>
>>>
>>> For something not to be application specific, it needs to apply to
>>> every single consumer of this API, for every possible use case.
>>
>> MW> That's clearly not true. Not every consumer of the API will need every feature of the API.
>>
>> A feature is application-specific it requires implementation of functionality that will only be used by one application. If Netflix had our own key derivation function, say, not standardized or used by anyone else, and we asked for that to be supported by the API, that would be application specific.
>>
>> Pre-shared symmetric keys are a well-established and widely used way of establishing security associations. Sure, we only have one formally submitted use-case for this feature, but we pretty much have only one formally submitted use case for each of the other features.
>>
>> It sounds like you're arguing the pre-shared symmetric keys should be out-of-scope altogether ?
>>
>>> The
>>> need to represent a Cryptographic Operation is one such example. The
>>> need to represent a Key is (with the exception of hashing), another
>>> such example.
>>
>> MW> How about the need to represent a KeyImporter capability ? That's not needed by every single consumer. Any consumer who does't need key import doesn't need that. How about the ability to represent DH parameters ? The ability to do public/private key operations ? The ability to do symmetric key operations ? Support for pre-shared symmetric keys ?
>>
>> But we're catering to a variety of consumers who need to do different, overlapping but not identical things. So we have support for features that not everyone will need.
>>
>>>
>>>>
>>>> Even the use of TLS PSK is
>>>> application/implementation dependent - the same key identifier used
>>>> for TLS PSK is not necessarily usable for any other purpose, nor is
>>>> the same identifier used by one TLS PSK peer equivalent to the
>>>> identifier used when negotiating (with the same key, if you were that
>>>> dangerous) to another peer.
>>
>> MW> And yet the concept of an identity associated with a key is deemed sufficient generic in TLS PSK they they describe in some detail what implementations must support.
>>
>> Not that it matters much, but my reading of that RFC is that the identity *is* associated with the key, so that if a client uses the same key with different servers it uses the same identity in each case. The RFC describes the management interface whereby the ( key, identity ) pair is pre-provisioned (Section 5.4).
>>
>>>>
>>>>
>>>> Again, the concept of a PSK and associated identity are sufficiently generic
>>>> that explicit support for the identity is embedded in the TLS PSK
>>>> specification. Yes, a lot of other things are applications specific. I am
>>>> not asking for more than TLS PSK does.
>>>>
>>>>
>>>>
>>>>
>>>> Assume we resolve ISSUE-17 and agree that, indeed, it's necessary to
>>>>
>>>> have a specific attribute store for keys (for which the only use case
>>>>
>>>> I seems to be pre-provisioned keys...). As discussed previously, the
>>>>
>>>> KeyAttributes interface (
>>>>
>>>> http://www.w3.org/2012/webcrypto/WebCryptoAPI/#dfn-KeyAttributes )
>>>>
>>>> fully supports read-only properties. That's why explicit
>>>>
>>>> getters/setters were defined, since WebIDL makes it clear that any
>>>>
>>>> accesses will be redirected through these getters/setters (
>>>>
>>>> http://www.w3.org/TR/WebIDL/ ) and that they need not support the
>>>>
>>>> operation.
>>>>
>>>>
>>>> Yes, if you have the KeyAttributes interface, everything is fine (modulo the
>>>> descriptive text which I think it would be wise to add on this issue). There
>>>> is no need to say what the "name" of the key id is, since whomever
>>>> pre-provisions the id itself can tell me what the name is as well.
>>>>
>>>>
>>>> We could consider keeping KeyAttributes only for functional or read-only
>>>> attributes and require applications to use Local Storage for
>>>> application-specific stuff.
>>>>
>>>>
>>>>
>>>> Possible ways that Netflix can do what they want without a spec change:
>>>>
>>>> * Presume a pre-provisioned Master Key (MK) which is secret from all
>>>>
>>>> applications
>>>>
>>>> * Goal is a pre-provisioned Origin Key (OK), which is origin-specific
>>>>
>>>>
>>>> Option 1: Implicit keys on demand:
>>>>
>>>> - When the UA navigates to one of the authorized origins
>>>>
>>>> - If an OK does not yet exist, generate one
>>>>
>>>> - Pre-provision an attribute/value pair with "MKID" and the ID
>>>>
>>>> of the master key
>>>>
>>>> - Pre-provision an attribute/value pair with "OKID" and whatever
>>>>
>>>> industry-specific origin key
>>>>
>>>> - Expose it via window.crypto.keys
>>>>
>>>> Option 2: Explicit key derivation
>>>>
>>>> - When the UA navigates to one of the authorized origins
>>>>
>>>> - Expose the MK as a handle via window.crypto.keys
>>>>
>>>> - Implement a custom key derivation mechanism ("Netflix-TV-keys")
>>>>
>>>> - Have your application request that a key be derived from the MK
>>>>
>>>> - The user agent performs the following steps:
>>>>
>>>> - Take the origin of the currently executing script (which all
>>>>
>>>> UAs must track anyways), and feed that as input into your derivation
>>>>
>>>> scheme. Thus, it's *never* necessary the application provide it
>>>>
>>>> - Derive the OK from the MK
>>>>
>>>> - On the generated OK, set the OKID and MKID as appropriate
>>>>
>>>> - Return the OK to the application
>>>>
>>>> - The key is now available to the application, and may be
>>>>
>>>> available later via window.crypto.keys (if the caller requested the OK
>>>>
>>>> be persistent)
>>>>
>>>>
>>>> Both assume that there is a sensible place to pre-provision attributes.
>>>> Local Storage is a sensible place for the application to store stuff, but I
>>>> don't think it works for pre-provisioning key attributes.
>>>>
>>>>
>>>> So then is this just ISSUE-17? It seems the argument is that existing
>>>> storage mechanisms are unsuitable for pre-provisioning, ergo a new
>>>> mechanism is needed. That's a fine argument to make, but does seem to
>>>> get at the heart of ISSUE-17.
>>>>
>>>>
>>>> No, ISSUE-17 says: "For attributes defined by the application, the question
>>>> is…"
>>>>
>>>> So, ISSUE-17 is constrained to attributes defined by the application, which
>>>> I take to mean those where the JS script wants to attach its own attributes
>>>> to a key for later retrieval. If that is the problem, then I agree with your
>>>> arguments that Local Storage seems sufficient.
>>>
>>> "Application" represents both the server operator and the executing
>>> client script.
>>
>> MW> Ok, so that's a different interpretation of ISSUE-17. No matter, there's two issues, whatever number we give them:
>> (i) key attributes created by the script on the client
>> (ii) key attributes pre-provisioned against the key by <whomever>
>>
>> In the ISSUE-17 discussion I agreed that (i) can be done with Local Storage. I don't think Local Storage is appropriate for (ii).
>>
>>>
>>> The key is pre-provisioned by the server operator (Netflix), by
>>> contractually delegating that provisioning through to device
>>> manufacturers. Thus, it's "Application specific", but that does not
>>> mean positively or negatively that it may be altered by the content
>>> script executing as part of that application.
>>
>> That is what we do today, as a private arrangement between ourselves and device manufacturers. But what we have consistently described in this WebCrypto activity, from early last year, through the charter discussion, and consistently every time this has come up, is a generalized capability for pre-provisioned symmetric keys. I fail to see how that general concept is application-specific.
>>
>>>
>>>>
>>>> The global identity for a pre-shared symmetric key is not one of those
>>>> attributes. It does not start life in the script or even with the
>>>> application-provider. It's pre-provisioned, probably by the device maker.
>>>
>>> Who, through relationship with the application-provider, exposes it to
>>> the application provider.
>>>
>>> Does every device manufacturer make such keys widely available to
>>> every possible application?
>>
>> If we defined a generalized capability as we proposed it would make sense for them to do so, yes.
>>
>>>
>>> Does every single device on the Internet have such a key?
>>
>> No, and nor do we expect them to. This is an optional capability.
>>
>>>
>>> If not, then I think it is implementation and application specific.
>>
>> There are many non-implementation- and non-application- specific capabilities that are not supported by every single device on the Internet.
>>
>>>
>>>>
>>>> If ISSUE-17 includes pre-provisioned information then I would argue that
>>>> Local Storage is unsuitable for that, unless the Local Storage specification
>>>> is amended to make that use-case clear.
>>>
>>> It does, and I think that's a fair comment.
>>>
>>>>
>>>>
>>>> That said, the proposal for KeyAttributes being *explicitly* read-only
>>>> is interesting as well. For example, WebIntents does this via the
>>>> 'extras' member of the IntentParameters, which is a key/value map of
>>>> extra meta-data to be sent with the Intent. That said, I understand
>>>> there is some ongoing discussion/controversy regarding it, so it may
>>>> not be the best API to cite.
>>>>
>>>>
>>>> I think both options could work, with some tweaks. If by 'ID of the master
>>>> key' you mean a global id for that, then I would not expect that to be
>>>> exposed. The idea of explicitly exposing a key derivation function that
>>>> factors in the current origin is interesting. That could be under the covers
>>>> (the application only ever knows about the OK), but there may be some
>>>> advantage in giving the application control of the derivation. You'd need to
>>>> derive an orgin-specific key identifier too.
>>>>
>>>>
>>>> In fact if we could specify the above approach that would make things
>>>> significantly easier for device manufacturers.
>>>>
>>>>
>>>> I think that the MK/OK scheme is something specific to a given
>>>> implementation, and highlights both the flexibility and dangers of the
>>>> API.
>>>>
>>>>
>>>> It could be left implementation specific. But we could also decide to
>>>> standardize it if we thought it was generically useful. We don't need to
>>>> have that debate right now.
>>>>
>>>> This similarly relates to the discussions about MUST vs SHOULD
>>>> for algorithms, since the concern was raised that if anyone can
>>>> implement any algorithm, then you'll have new implementations
>>>> effectively barred from entry or working with a site, due to their
>>>> lack of support for a given algorithm.
>>>>
>>>> If we can reach consensus that the fundamental API is flexible enough,
>>>> and possible to standardize, then I think we could begin discussions
>>>> about whether it's worthwhile to specify such a key
>>>> agreement/negotiation scheme that is specific to the context of user
>>>> agents and the security boundaries they operate in (eg: having
>>>> unspoofable inputs from the U-A in addition the the web application's
>>>> inputs). This is similar to the PBKDF2 text in the current draft.
>>>>
>>>> Like all crypto-politics, I imagine that conversation will be a fun
>>>> one, so I would rather wait until we've shipped something (eg: not
>>>> just FPWD) before going down that road.
>>>>
>>>>
>>>>
>>>>
>>>> Again, pre-provisioned keys are user-agent specific.
>>>>
>>>>
>>>> Support of pre-provisioned keys is user-agent-specific. That's different.
>>>>
>>>>
>>>> There is no way
>>>>
>>>> to have pre-provisioned keys to universally work across user agents,
>>>>
>>>> since that universally assumes the same key storage and access APIs,
>>>>
>>>> which is simply impossible. So your user agent can do whatever it
>>>>
>>>> wants - because it's the only one who understands this concept.
>>>>
>>>>
>>>>
>>>> But there are some concepts which are generic, which we can standardize. We
>>>> could standardize the origin-specific key derivation function and the
>>>> concept of a common Master Key as you describe above. We would not make any
>>>> statements about the properties this key has. Some implementations might
>>>> just re-generate it randomly every time. Especially if you're in "incognito
>>>> mode". Others would have it stored in hardware. Doesn't matter because the
>>>> API is not guaranteeing any special properties for this key. Any special
>>>> properties are learned out-of-band.
>>>>
>>>>
>>>> If we had consensus to do so, yes. I don't believe attempting to
>>>> define a new cryptographic algorithm for user agents to derive keys
>>>> from origin inputs is something as an implementor we'd be interested
>>>> in standardizing at this time.
>>>>
>>>>
>>>> OK, let's leave the MK -> OK derivation for later.
>>>>
>>>> …Mark
>>>>
>>>
>>
>
Received on Wednesday, 22 August 2012 00:16:38 UTC