W3C home > Mailing lists > Public > public-webcrypto@w3.org > June 2012

Re: Use case classification, and associated security models

From: Ryan Sleevi <sleevi@google.com>
Date: Wed, 13 Jun 2012 18:03:09 -0700
Message-ID: <CACvaWvYJv64y60ZF2CDpSXe3M-Uz-B3uyz5Vht7yDKMPYGPPdA@mail.gmail.com>
To: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Cc: Wan-Teh Chang <wtc@google.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Wed, Jun 13, 2012 at 5:46 PM, Vijay Bharadwaj <
Vijay.Bharadwaj@microsoft.com> wrote:

>  Sorry, my original statement was not worded very well.****
>
> ** **
>
> The idea I had in mind was that the scope of the name in scenarios #1 and
> #2 need not (should not?) exceed the scope of the key. In #1 the key is
> only meant to be used by the one app, and therefore itís okay if it cannot
> be referred to outside that app. Therefore in general other servers cannot
> probe for it. In #2 there is nothing to name. The key is not persisted -
> the app is just creating a key object by importing a blob received through
> some other means, and once itís done using it the key object can go away.*
> ***
>
> ** **
>
> In other words Iím trying to limit consideration of cross-application
> long-lived keys (and hence the key querying issues) to scenario #3.****
>
> ** **
>
> Does that make more sense?
>

Hi Vijay,

I'm still not sure I understand the motivation for what seems like
essential limitations.

For example, for scenario #1, I imagine the possibility may arise that the
user wishes to re-use the key across multiple origins. It does not fit into
your scenario #3 model - specifically, it is not pre-provisioned by some
signing provider. It's a key that lives in the browser.

Let's use secure messaging as an example, since that touches on both
scenario #1 and scenario #2, and I think may aptly illustrate my thoughts.

Scenario #1:
- Alice and Bob exchange authenticated messages via Carol's web service.
Alice and Bob are not particularly concerned with privacy, but they are
concerned with authenticity. Using a particularly hand-wavey mechanism,
when Alice and Bob were registering with Carol's service, they created some
public/private key pairs to be used to authenticate their messages. They
may have generated these keys via their UA when registering with Carol's
site, they may have exchanged them in-band (trust on first use) or
out-of-band (key signing parties?), regardless, Alice and Bob both have
public keys for eachother.
- Alice and Bob decide that Carol's service is no longer up to the task of
serving their needs, so they wish to migrate to Charlie's site, which
offers services similar to Carol's.
- Can Alice and Bob continue using their keys, originally created/"bound"
to Carol's site, with Charlie's site?
- If not, why not?

Scenario #2:
- Alice and Bob are again exchanging secure messages via Charlie, an
intermediary, this time using Off the Record messaging (ala TextSecure
et-al), meaning the focus is also on encryption and key derivation.
- Alice and Bob decide to migrate from Charlie's service to Carol's.
- Can Alice and Bob continue using their derived keys?
- If not, why not? Does this mean they need to redo key exchange in order
to migrate to Carol?

I don't think I see the special distinction between Scenarios #1 - #3, as
you outlined them. I think the re-use of keying material will be an
important part of flexibility between web sites and services. Yes, I
realize it opens possible privacy concerns, but I don't believe any more
than Scenario #3, and I think fundamentally it serves the users and site
operators if keys are portable between origins, with the appropriate
security constraints.

Further, in my above example, consider the example where Carol and Charlie
are the same site operator/legal entity, and they simply are going through
a rebranding effort. In the origin-bound/domain-bound security model, with
no key portability, it creates an artificial cost for operators who may
wish to shard domains / change domains / etc.

Cheers,
Ryan


> ****
>
> ** **
>
> *From:* Ryan Sleevi [mailto:sleevi@google.com]
> *Sent:* Wednesday, June 13, 2012 10:50 AM
> *To:* Vijay Bharadwaj
> *Cc:* Wan-Teh Chang; public-webcrypto@w3.org
>
> *Subject:* Re: Use case classification, and associated security models****
>
> ** **
>
> On Wed, Jun 13, 2012 at 7:57 AM, Vijay Bharadwaj <
> Vijay.Bharadwaj@microsoft.com> wrote:****
>
> One more clarification - I'm also implicitly making the assumption that
> keys used in scenarios #1 and #2 are not eligible for naming (at least as
> exposed outside the app), and cannot be queried for by a server. Names are
> only for long-term persisted keys with trusted provenance as in scenario
> #3. Specifically, keys that are provisioned out-of-band or created as part
> of something like a certificate enrollment operation signed by an
> out-of-band provisioned key.****
>
> ** **
>
> Could you explain a bit more about this?****
>
> ** **
>
> I would think that some form of symbolic naming will be an important part
> of making a usable API. I'm not sure the use case for why they wouldn't be
> needed?****
>
> ** **
>
> If a web application wishes to use multiple RSA keys, which it provisioned
> via scenario #1 during some prior visit, what is the intended way for it to
> disambiguate the keys.****
>
>  ****
>
>
> -----Original Message-----
> From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com]****
>
> Sent: Wednesday, June 13, 2012 7:23 AM
> To: Wan-Teh Chang
> Cc: public-webcrypto@w3.org
> Subject: RE: Use case classification, and associated security models
>
> The only API-level difference between #1 and #2 in my mind was that #1
> talked about a GenerateKey operation (and sort of implied an ExportKey
> operation) whereas #2 talked about ImportKey. So from an API perspective,
> the difference is that #1 requires a strong source of randomness and an
> ability to generate keys (including things like prime number generation and
> so on) whereas #2 doesn't.
>
> >From the perspective of key provenance, in #1 the key is generated within
> the app so the browser knows who generated the key and can tag it with
> appropriate metadata. In #2 the browser doesn't necessarily know where the
> key came from - it is embedded in some protocol that is run by the app - so
> the browser cannot validate provenance. However, I don't think this needs
> to be reflected in the API separately - the fact that an app does an
> ImportKey operation should indicate that the app is responsible for
> ensuring the provenance of the key.
>
> -----Original Message-----
> From: Wan-Teh Chang [mailto:wtc@google.com]
> Sent: Tuesday, June 12, 2012 4:54 PM
> To: Vijay Bharadwaj
> Cc: public-webcrypto@w3.org
> Subject: Re: Use case classification, and associated security models
>
> Hi Vijay,
>
> Thank you for writing this up.
>
> I agree that the design of the Web Cryoto API can be divided into two
> parts:
> - key management
> - the actual crypto operations that take a key object
>
> As for the three scenarios of key management you described, the difference
> between scenario 1 (Ephemeral or local-only keys) and scenario 2 (Ephemeral
> keys obtained through key agreement) does not seem important for the API
> design. How do you think the API should reflect the different security
> models between scenario 1 and scenario 2?
>
> To me, the important distinction is between scenarios 1 & 2 and scenario
> 3. In scenarios 1 & 2, the browser knows which website generates or
> imports/derives the key.  That knowledge is recorded persistently and can
> be used to determine which website is authorized to open or use a key in
> the future if the key is persistent.
>
> Wan-Teh
>
>
>
> ****
>
>  ** **
>
Received on Thursday, 14 June 2012 01:03:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 14 June 2012 01:03:41 GMT