Re: Use Cases | ACTION-13 Revisited

Vijay,

This text looks good to me as well, though I would still like us to be clearer about the fact that in practice the pre-provisioned key will very often be associated with an identity. There are privacy and security issues associated with that which deserve recognition and discussion and my concern is that people reading the text below may not realize the implications in terms of identity.

Perhaps insert after the second sentence of the second paragraph: "Such keys may be associated with a pre-provisioned identity (for symmetric keys) or certificate (for public/private key pairs)." and then s/utilize knowledge/utilize this identity/certificate together with knowledge/

…Mark

On Sep 6, 2012, at 11:31 PM, Vijay Bharadwaj wrote:

> Ryan, your wording seems less clear to me, primarily because it uses "web application" sometimes to mean the client-side application and sometimes to mean the server backend. How about this revised and condensed version?
> 
> Out-of-Band Key Provisioning
> 
> Web applications may wish to use keys that have been provisioned through means outside the scope of this API. This may include keys that are provisioned through platform-specific native APIs, stored in secure elements such as smart cards or trusted platform modules (TPMs), or individually bound to devices at time of manufacturing. User agents may choose to expose such keys to web applications after implementing appropriate security and privacy mitigations, such as gaining user consent or other out-of-band authorization.
> 
> In this scenario, a web application discovers a pre-provisioned key based on its attributes and uses it to perform authorized cryptographic operations as part of a protocol with a server. The server may utilize knowledge (obtained out-of-band) regarding how the key was provisioned to make access control and policy decisions. For example, the server may wish to restrict an application to a certain class of devices, and may use a cryptographic challenge to establish the user agent's access to a particular device-specific key.
> 
> 
> -----Original Message-----
> From: Mark Watson [mailto:watsonm@netflix.com] 
> Sent: Wednesday, September 5, 2012 4:43 PM
> To: Ryan Sleevi
> Cc: public-webcrypto@w3.org Working Group; Arun Ranganathan; estark@mit.edu; Vijay Bharadwaj; Mitch Zollinger
> Subject: Re: Use Cases | ACTION-13 Revisited
> 
> 
> On Sep 5, 2012, at 4:17 PM, Ryan Sleevi wrote:
> 
>> On Tue, Sep 4, 2012 at 4:38 PM, Mark Watson <watsonm@netflix.com> wrote:
>>> 
>>> On Sep 4, 2012, at 4:04 PM, Ryan Sleevi wrote:
>>> 
>>>> - The existing use cases try to describe novel constructions of a 
>>>> series of operations, whereas the Netflix proposal seems to broadly 
>>>> focus on everything, but without quite describing what operations 
>>>> are actually necessary to perform.
>>> 
>>> MW> Is this concern addressed if we're more specific in the use-case about the operations needed ?
>> 
>> Consistent with the other use cases, describing the use case solely in 
>> operations / classes of operations seems more useful to understanding 
>> the purpose of the API, and provides enough context for readers to 
>> understand the functionality without having to interpret or disconnect 
>> the supplementary reasons that can be inferred or that have not 
>> affected the design of the API.
>> 
>> Plus, it's shorter that way.
> 
> I don't see how it could be shorter, but I'll try.
> 
> Generally, a use-case is quite the opposite of this: it describes what you want to achieve without pre-supposing a solution. Check almost any bug response from Hixie for a more detailed description of what qualifies as a use case ;-)
> 
>> 
>>>> - The existing use cases try to describe generic services that can 
>>>> be implemented whether you're 15 or a Fortune 500. The Netflix use 
>>>> case does seem inherently tied to pre-provisioned keys 
>>>> (exclusively), and thus is not something that anybody can necessary 
>>>> implement, since they have to work with device manufacturers-et-al 
>>>> to actually discover these pre-provisioned relationships.
>>> 
>>> MW> This is true today, but there is no technical reason why devices couldn't mint new origin-specific pre-provisioned keys on demand.
>> 
>> This is also true, but in order to have any use for "device 
>> authentication", the origin would have to know the provenance of the 
>> key is a device. Whether this means knowing the key derivation/minting 
>> algorithm or knowing the master key is supplementary.
>> 
>> This is fundamentally a *different* use case than using device storage 
>> for keys (such as TPMs or other secure elements). This is about the 
>> manufacturer of a device (or some other party in the supply chain) 
>> directly provisioning keys out of band, and having service providers 
>> recognize the provenance of such keys. This "know the provenance" is 
>> the part that I think rules it out from being generally useful, since 
>> it requires specific out of band information that, for privacy 
>> reasons, may not be (and arguably should not be) generally available.
> 
> Nevertheless, this is a capability that we would need to port our application to the web. And I suspect anyone else with similar security requirements. I doubt that's a small set. We're talking here about applications enjoyed by tens of millions of people on thousands of different devices that are already mostly based on web technologies. There are just a few missing pieces to make them entirely web-based. Note that I'm mostly NOT talking about desktop browsers.
> 
> We've been clear about this requirement since the very beginning of this work some 18 months ago. There was consensus on the call to include this use-case. I want to be sure we have a proper discussion of the issues this raises - for example privacy issues - and excluding a description of the functionality is not a good way to engender debate.
> 
>> 
>>> 
>>>> 
>>>> Broadly speaking, I think the API use cases should focus on use 
>>>> cases that can operate regardless of the provenance of the key - 
>>>> that is, whether it be pre-provisioned or generated.
>>> 
>>> MW> Why ? This seems an arbitrary place to draw the line on what is included.
>> 
>> For the same reasons we don't focus on Crypto Providers: The key 
>> provenance is left to implementation specific details. Trying to 
>> specify a use case that hinges on provenance, a point specifically not 
>> addressed, seems counter-intuitive, because it directly highlights an 
>> piece of functionality that is both optional and implementation 
>> dependent. It's not addressed by the API.
> 
> It seems we just disagree about this aspect of the scope. As I said it's something we've been very clear about since the very beginning.
> 
>> 
>>> 
>>>> Obviously pre-provisioned
>>>> can be used to bootstrap some trust, but the more focus on 
>>>> pre-provisioned we as a WG place, the further away from having any 
>>>> compelling story to be said to the broader Internet community about 
>>>> the interoperability of these APIs.
>>> 
>>> MW> I don't understand why that would be the case. Inclusion of material on pre-provisioned keys does not take away from any of the other features. We're not suggesting this should be a "special focus" of the group, just that it is one feature which should be included.
>>> 
>>>> 
>>>> In looking at the existing use cases, I'm trying to figure out what 
>>>> operations that are present in the Netflix case that are not already 
>>>> captured. The use of pre-provisioned keys is mentioned in the 
>>>> Multi-Factor Auth use case, and then again in the Document Signing 
>>>> use case. The key derivation scheme has been previously acknowledged 
>>>> as something more Netflix specific, so I'm not sure if it needs a 
>>>> special use case. Are there other operations you desire?
>>>> 
>>> 
>>> MW> The use of pre-provisioned symmetric keys to perform device authentication.
>>> 
>>> ...Mark
>> 
>> So "Multi-factor Authentication", with wording tweaks, essentially. A 
>> use case that's already arguably too long and too specific.
>> 
>> What about the proposed text then, in attempt to reduce the Netflix 
>> case to the "bare essentials" while also attempting to address the 
>> specific needs that Netflix feels have not already been captured in 
>> the existing use cases, which also make efforts to highlight the 
>> possibility of pre-provisioned keys.
>> 
>> I'd like to note that the inclusion of a Netflix specific use case 
>> does not feel appropriate here in this spec, and would object to 
>> publishing a FPWD with such a use case.
> 
> Again, we're not asking for anything Netflix-specific. This use-case is applicable to any application that needs device authentication. That's a very large class, including most commercial video services, many financial services and other things that cannot be implemented with web technologies today.
> 
> You should see the APIs we started from when originally thinking about what to propose for this work - they certainly were "Netflix specific" ;-)
> 
>> 
>> I've attempted to try and find some happy medium, but I remain 
>> unconvinced that such a specific use case belongs in the API, because 
>> it is inherently non-portable and implementation-specific.
> 
> I agree that something "specific", "non-portable", "implementation-specific" should not be in the API, but I disagree that what we're asking for fits those descriptions (for reasons we've gone over several times). 
> 
>> 
>> "Out-of-Band Key Provisioning
>> 
>> Web applications may wish to use keys that have been provisioned 
>> through means other than this API. This may include keys provisioning 
>> or storage through platform-specific native APIs, the use of keys 
>> storage in secure elements such as smart cards or trusted platform 
>> modules (TPMs), or keys that are individually bound to devices at time 
>> of manufacturing. While not required to be supported by this API, and 
>> though it introduces a number of security and privacy concerns, user 
>> agents may choose to expose such keys to web applications, potentially 
>> after gaining user consent or other out-of-band authorization.
>> 
>> Web applications may utilize knowledge obtained out-of-band regarding 
>> the how the key was provisioned or was stored to make local policy 
>> decisions. For example, a web application may wish to restrict access 
>> to users that can prove access to a key that was provided out-of-band 
>> to the user by the application provider, such as via a smart card.
>> Alternatively, an application may wish to be restricted to a certain 
>> class of devices, and may use a cryptographic challenge to establish 
>> the user agent's access to a particular device-specific key.
>> 
>> The web application must be able to determine if the user agent 
>> supports such externally-provisioned keys, locate any appropriate 
>> keys, and perform authorized cryptographic operations such as signing 
>> or encrypting on the keys, as if it had directly generated or imported 
>> the key."
>> 
>> The above tries to:
>> - Highlight that pre-provisioned keys may exist
>> - Highlight that it's implementation dependent
>> - Highlight that it opens up new security and privacy concerns
>> - Highlight that it can be used to support "enhanced" authentication 
>> such as smart cards OR device authentication
>> - Highlight that the operations may include both symmetric and 
>> asymmetric operations.
>> 
>> Would the above meet your needs?
> 
> Yes, I believe so, though I feel it is less clear that the proposal I made, in terms of what the application is actually trying to achieve. The main difference is that my text is more explicit about device identity. You say "particular device-specific key", which implies some notion of identity in practice. If that is clear, the text is ok.
> 
> ...Mark
>> 
> 
> 
>

Received on Friday, 7 September 2012 16:29:10 UTC