Re: ECC vs RSA, and Similar Conflicts

In my mind, this gets closer to the "High Value Transaction" case.

At the risk of creating more ontologies, and truly just throwing out a
strawman here, I see three types of keys:

   - Origin-bound: These are keys generated via .generateKey() [or whatever
   it becomes], that are bound to a single origin. They may be short-lived
   (session cookie style?), they may be long-lived (persistent cookie style).
   They may be cleared when the user chooses to clear data. They may be not
   persisted when using "private" browsing
      - Use case: DHE/ECDHE/PAKE key agreement for opportunistic encryption
      of chat over Websockets, where the intermediary is not trusted.
      - Use case: Perhaps some binding of a user login/cookie data to some
      encrypted context. The key is only as useful as long as the cookie lives,
      and vice-versa.
   - Persistent: These are keys that are effectively super-cookie, in that
   they don't follow the same "personal data cleanup" rules that might apply
   to cookies/cache/other data.
      - Use case: You may wish to create and register an "identity key"
      with a service. Possession of this key is now a strong connector to some
      concept of 'identity' (putting the cryptopolitics of this concept aside).
      This identity might be used for mail signing, HTML5 file storage, online
      chat, etc
      - This key may be bound to a single origin, it may be allowed to be
      shared with multiple origins, or it might be allowed to be
shared with all
      origins.
      - Because of the sensitivity of this, this would likely require user
      confirmation/assent, much like other APIs such as Geolocation or
increased
      storage do in browsers today.
      - Keys may be stored in software (managed by the UA), in the OS or
      some global key store (making them available to other applications beyond
      the UA), in "the cloud" as part of some sync service, or even stored on
      another device such as TPM or smart card.
      - Use Case: For embedders (such as Netflix), keys may be
      pre-provisioned and pre-bound to certain origins.
      - Use Case: Users may wish to purchase USB TPMs (as you mentioned) as
      a portable way to transfer these keys between machines they authenticate
      with.
   - High Value: These are the keys that have a strong correlation to
   certain high value transactions - particularly where force of law is
   involved. Unlike the above 'persistent' keys, HVKs are strongly correlated
   to identity, and may reflect government or financial services issuance.
      - These keys will typically be stored on smart card or TPM, where the
      provisioner has previously guaranteed that the key storage and generation
      matches their criteria. Specifically, I'm *not* trying to get into
      the side debate about provisioning, end to end protocols, PoP, and that
      whole mess, as has been discussed and rightfully discouraged/discarded in
      the past here.
      - Use Case: Signing a legal document - tax forms, contract, etc
      - Use Case: Performing 'sensitive' transactions (bank transaction
      confirmation, etc)
      - While I don't know if it can be stated as MANDATORY, I think the
      assumption is that there MUST be user interaction throughout the process,
      and likely custom chrome to facilitate these sorts of HVTs.
      - The API for interacting with them is likely very different than the
      above two key types, due to the nature of what's being done with them.

AIUI, David's strawman is focused exclusively on the first type
(Origin-bound) at present. Netflix's use case best fits within the second
type (persistent).

For my take, I believe we're best served focusing on the first two types. I
would prefer that the API, as much as possible, make the distinction
between the two invisible. I only imagine the edges between the two will
show up when discussing the API for key generation and the detection of
existing keys. For everything else, referring to a "key id" has an added
benefit of hiding the distinction between the two.

On Thu, May 10, 2012 at 10:41 AM, Cullen Jennings <fluffy@cisco.com> wrote:

>
> So if I plug in a USB TPM to my computer with some private keys on it, can
> any website ask for somehting to be encrypted with theses keys? That seems
> like it would be a problem (as well as super cookie).
>
>
> On May 10, 2012, at 10:55 AM, Alex Radutskiy wrote:
>
> > I believe it is a very important use case to be able to create a key
> that is secured by hardware such as TPM or smart card. Even software keys
> isolation (i.e. keeping key material in a separate process from the
> application that is using it) will be useful. For example, if an
> application is compromised it will not be possible to extract a key and
> send it somewhere for later use.
> >
> > In all of those examples, you need a model that can simply reference
> keys by some IDs when performing crypto operations without directly
> interacting with key material.
> >
> > Thank you,
> >
> > Alex Radutskiy
> > Senior Program Manager, Windows PKI
> >
> > alex.radutskiy@microsoft.com
> >
> >
> >
> > -----Original Message-----
> > From: David Dahl [mailto:ddahl@mozilla.com]
> > Sent: Thursday, May 10, 2012 9:35 AM
> > To: Cullen Jennings
> > Cc: Richard L. Barnes; Nadim; public-webcrypto@w3.org
> > Subject: Re: ECC vs RSA, and Similar Conflicts
> >
> > If you are referring to the Netflix use-case, the browser in question is
> an embedded webkit browser inside a blu-ray player. The Netflix use case is
> about identification of said blu-ray player to know what kind of streams it
> can accept and if it is authorized to view streams in the first place. The
> keys are pre-positioned by the blu-ray manufacturer.
> >
> > I doubt this API will be used to decode encrypted video produced in
> Hollywood, I could be wrong.
> >
> > David
> >
> >
> > ----- Original Message -----
> > From: "Cullen Jennings" <fluffy@cisco.com>
> > To: "David Dahl" <ddahl@mozilla.com>
> > Cc: "Richard L. Barnes" <rbarnes@bbn.com>, "Nadim" <nadim@nadim.cc>,
> public-webcrypto@w3.org
> > Sent: Thursday, May 10, 2012 11:15:51 AM
> > Subject: Re: ECC vs RSA, and Similar Conflicts
> >
> >
> > I get what you are saying but I would like to push on making sure we
> have a complete solution. How do the private keys get into the browser? And
> if the private keys are for DRM protected video running in an open source
> browser, what does the whole system look like to make this work.
> >
> > I'm not arguing against something like this, I just want to understand
> the big picture so I understand the requirements for this work.
> >
> >
> >
> > On May 10, 2012, at 8:30 AM, David Dahl wrote:
> >
> >> One of the reasons for establishing this WG is to try and provide a
> more secure way of using crypto on the web. Keeping the private keys
> private is at the top of this list. We can establish a spec that only ever
> references private key IDs, making this much more secure than existing JS
> crypto libraries that have access to private key material.
> >>
> >> David
> >>
> >> ----- Original Message -----
> >> From: "Richard L. Barnes" <rbarnes@bbn.com>
> >> To: "Cullen Jennings" <fluffy@cisco.com>
> >> Cc: "Nadim" <nadim@nadim.cc>, public-webcrypto@w3.org
> >> Sent: Thursday, May 10, 2012 9:18:44 AM
> >> Subject: Re: ECC vs RSA, and Similar Conflicts
> >>
> >> Note, however, that that approach would require that private keys be
> exposed to the JS layer.  It seems like we have at least some use cases
> (e.g., the Netflix cases) where maintaining the secrecy of the private key
> is important.
> >>
> >> --Richard
> >>
> >>
> >>
> >> On May 10, 2012, at 9:42 AM, Cullen Jennings wrote:
> >>
> >>>
> >>> One way to deal with the ECC / RSA issues is instead provide the
> underlining big math libraries that are needed to implement these and leave
> the actually IPR encumbered implementation to an JS library. If done right,
> this would could have approximately the same performance as a native
> implementation.
> >>>
> >>>
> >>> On May 9, 2012, at 11:33 AM, Nadim wrote:
> >>>
> >>>> Hi everyone,
> >>>> I think we need to have a discussion regarding whether the API will
> exclusively implement (and rely on) newer, faster standards (such as ECDH,
> ECDSA) or whether there will be a larger dependence on RSA, either for
> fallback or stronger compatibility reasons.
> >>>>
> >>>> If it is eventually decided that not only the best available per-task
> algorithm is implemented, but rather, all possible algorithms, where do we
> draw the line? Do we implement SHA1 in addition to SHA2? Does that also
> warrant an MD5 implementation?
> >>>>
> >>>> Personally, I believe that focusing only on the newer, more efficient
> standards (such as ECC) is a better idea, but I stand very humbly by my
> opinion and a much more interested in listening to the group's opinions.
> >>>>
> >>>> Thank you,
> >>>> NK
> >>>
> >>>
> >>
> >>
> >
> >
> >
> >
> >
>
>
>