W3C home > Mailing lists > Public > public-webcrypto@w3.org > October 2013

RE: ACTION-114: Make proposal to amend api

From: Hutchinson Michael <Michael.Hutchinson@gemalto.com>
Date: Sat, 12 Oct 2013 01:00:17 +0200
To: Ryan Sleevi <sleevi@google.com>
CC: Mark Watson <watsonm@netflix.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Message-ID: <AA393B9CFBFD084C9700F56093098004020E62DCD5A2@CROEXCFWP03.gemalto.com>
Hi Ryan,

> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Friday, September 27, 2013 4:41 PM
> To: Hutchinson Michael
> Cc: Mark Watson; public-webcrypto@w3.org
> Subject: Re: ACTION-114: Make proposal to amend api
>
> Hi Michael,
>
> It's a bit hard to understand without the diff. That said, thanks for
> taking the time to write this up.
>
> Perhaps unsurprisingly, given the concern I expressed during the F2F
> regarding exposing certificates, I do not believe your proposal is
> sufficient nor a good fit. However, it's helpful to understand what you
> see is missing.
>
> On Thu, Sep 26, 2013 at 5:52 PM, Hutchinson Michael
> <Michael.Hutchinson@gemalto.com> wrote:
> > Mark,
> >
> >
> >
> > This is my suggestion as to how to amend the WebCrypto Key Discovery
> > document to support the home automation use case; as requested in
> > ACTION-114.
> >
> >
> >
> > Abstract
> >
> >
> >
> > This specification describes a JavaScript API for discovering named,
> > origin-specific pre-provisioned cryptographic keys for use with the
> > Web Cryptography API. Pre-provisioned keys are keys which have been
> > made available to the UA by means other than the generation,
> > derivation, importation functions of the Web Cryptography API.
> > Origin-specific keys are keys that are available only to a specified
> > origin. Named keys can be identified by their name or their id. The
> > name can either be provisioned by the origin with the key or derived
> > by the UA from information stored within a certificate associated with
> > the key. The id corresponds to a unique identifier for that specific
> > key amongst all pre-provisioned keys from the same origin.
> >
> >
> >
> > 1. Introduction
> >
> >
> >
> > This section is non-normative.
> >
> >
> >
> > The Web Cryptography API [WEBCRYPTO] describes a JavaScript API for
> > performing basic cryptographic operations in web applications.
> > Cryptographic keys in are represented in this API using Key objects.
> > The API provides methods to generate, derive or import cryptographic
> > keying material, so creating Key objects.
> >
> >
> >
> > This document concerns the discovery of cryptographic keys which are
> > made available to the UA by other means. Specifically, this document
> > provides an API for the discovery of cryptographic keys which have
> > been pre-provisioned into a UA or device for use by a specific origin.
> > Such keys are identified by names or ids which are assumed to be known
> > to the origin in question and thus they are referred to as named
> origin-specific pre-provisioned keys.
> >
> >
> >
> > This enables web applications to establish secure proof that the UA
> > has access to a particular pre-provisioned key. Depending on the
> > nature of the key and its associated storage - for example within a
> > Hardware Security Module or available only within a Trusted Execution
> > Environment - further properties of the device on which the UA is
> running may be inferred.
> >
> >
> >
> > The use of pre-provisioned keys requires the informed consent of the
> > user, because such keys may be used for tracking and may reveal
> > information about the users device. The privacy implications of
> > origin-specific pre-provisioned keys are discussed further in Security
> > and Privacy Considerations.
> >
> >
> >
> > 2.1 Out of band key provisioning
> >
> >
> >
> > Web applications may wish to use keys that have been provisioned
> > through means outside the scope of the WebCrypto API. This may include
> > keys that are provisioned through platform-specific native APIs,
> > stored in secure elements such as trusted platform modules (TPMs),
> > individually bound to devices at time of manufacturing or otherwise
> > installed via device-specific provisioning protocols.
> >
> >
> >
> > Such keys may, for example, be used to assist in identifying a device
> > to a specific web service. User agents may choose to expose such keys
> > to web applications after implementing appropriate security and
> > privacy mitigations, including gaining user consent.
> >
> >
> >
> > In this scenario, a web application discovers a pre-provisioned key
> > based on its name 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 the key's provisioning to
> > make access control and policy decisions, such as inferring the
> > identity of the device and customizing its responses based on that.
> >
> >
> >
> > 2.2 Certificate based key provisioning
> >
> >
> >
> > Web applications may wish to use keys associated with certificates.
> > These certificate keys may have been provisioned through means outside
> > the scope of the WebCrypto API. This may include keys that are
> > provisioned through platform-specific native APIs. These type of keys
> > could be stored in secure elements such as trusted platform modules
> > (TPMs), otherwise installed via device-specific provisioning
> protocols.
> >
> >
> >
> > Such certificate keys may, for example, be used to assist in
> > identifying a specific device to a specific web service. User agents
> > may choose to expose such keys to web applications after implementing
> > appropriate security and privacy mitigations, including gaining user
> consent.
> >
> >
> >
> > In this scenario, a web application discovers certificate keys via a
> > function to return either all or a subset based on either the key name
> > or id. The discovered key can then be used to perform authorized
> > cryptographic operations as part of a protocol with a server. The
> > server may utilize knowledge obtained out-of-band regarding the key's
> > provisioning to make access control and policy decisions, such as
> > inferring the identity of the device and customizing its responses
> based on that.
> >
> >
> >
> > Note: If a User Agents (UA) needs to generate the association between
> > a certificate and the certificate key it does so by extracting the
> > subject CN value and the extended key usage (id-ce 37) into the
> > NamedKey name field and the certificate issuer CN and certificate
> > serial number into the NamedKey id field.
>
> I strongly oppose any further use of the subject common name field.
> It's way too overloaded.
>
> Further, this is completely underspecified with respect to the wide
> variety of forms that may appear within the CN and the EKU.

I actually intentionally underspecified it; I was hoping to elicit a discussion on the best approach.

>
> For example, is it mandatory that a UA normalize a T61String to...
> what, UTF-8? ... and concat that in?
>
> How are the EKU OIDs handled? Is the binary data dropped into the name
> field, or do you express the EKU OIDs in dotted form? What about 'well
> known' OIDs - are they treated as a string (eg:
> "clientAuthentication") or their octet form? How is this decided and
> where is it documented?

My initial theory was that the binary data, as retrieved from the certificate, would be Base64 encoded in order to fit into the DOMString format.
I was trying to keep the UA requirement to a minimum and put the onus on the web application to manage the data itself.
I am open to alternate suggestions.

>
> The issuer CN + serial number is vastly insufficient to uniquely
> identify certificates. Minimally, the entire issuer DN + serial number
> would be required, but even that is insufficient as a disambiguator,
> because two conflicting CAs may issue certificates with the same DN,
> which can then issue sub-certificates with the same CN and serial.

Within the context of SOP would the CN + serial number really not be sufficient to uniquely identify the certificate?
I would be OK with using DN if it was required.

>
> Your design appears to have overloaded "name" and "id" merely because
> they were there, rather than considering what they signified or how they
> would apply to other forms of keys.

Agreed; but these fields do serve my purpose specifically for RSA based certificates.
If others can be specified then we can add them in.

> I would much rather see a separate
> proposal altogether for dealing with certificates (perhaps using the
> supplemental interface to indicate its relation to CryptoKeys), rather
> than trying to shoehorn certificates (which are not NamedKeys) into the
> NamedKey notion.

Maybe this can be done with a future W3C working group.

>
> Also, APIs that enumerate all of [x] are strongly discouraged for
> privacy reasons. Because of this, something like getKeys() strikes me as
> a further API that may be a poor choice.

As with all usages specified in this WG, the intent is that only keys within the SOP would be returned.

>
> If your intent is to present a UI in-band, then I would argue that you
> *do not* want the Keys themselves, but instead want metadata about the
> key, to allow the user to choose, and then request specific access to a
> key the user has chosen.

There needs to be an association between keys and certificates and this is my way of specifying it.

> This ensures that the user doesn't have to
> grant access to, say, their bank signing key, in order for Joe's Social
> Network to be able to locate their Joe's Social Network Key.
>

SOP should prevent the granting issues you propose.

> This is just the tip of the spec issues. I realize I'm purely pointing
> out flaws here, rather than offering a counter-proposal, which may seem
> overly negative. That said, I'm wanting to make sure that we evolve a
> secure-by-default API, and I'm not sure this API quite hits there.

I'm glad someone looked at it and happy that it raised comments/concerns.
This is how it gets better!

>
> I'm happy to critique further design proposals, that allow you to
> iterate and refine the use case as well as understand some of the
> natural concerns these proposals raise.

Thanks!

Regards,
        Michael

>
> Cheers,
> Ryan
>
> >
> >
> >
> >
> >
> > 7.3 CryptoKeys interface
> >
> >
> >
> > WebIDL
> >
> >
> >
> > [NoInterfaceObject]
> >
> > interface CryptoKeys {
> >
> >     Promise getKeys();
> >
> >     Promise getKeyByName (DOMString name);
> >
> >     Promise getKeyById (DOMString id);
> >
> > };
> >
> >
> >
> > 7.3.1 Methods
> >
> >
> >
> > getKeys
> >
> >
> >
> >        When invoked, this method must perform the following steps:
> >
> >
> >
> >        1. Let promise be a new Promise and resolver its associated
> > resolver
> >
> >        2. Return promise and continue executing the following steps
> > asynchronously:
> >
> >            1. Search for keys.
> >
> >
> >
> >               If one or more keys are found
> >
> >                   1. Let the result be an object of type NamedKey[]
> > containing the keys
> >
> >                   2. Execute resolver's resolve(value) algorithm with
> > result as the value argument
> >
> >
> >
> >               Otherwise
> >
> >                   Execute resolver's resolve(value) algorithm with
> > null as the value argument
> >
> >
> >
> > Parameter       Type            Nullable        Optional
> Description
> >
> > N/A
> >
> >
> >
> > Return type: Promise
> >
> >
> >
> > Note: There should be no change to getKeyByName...just copied here for
> > completeness
> >
> > getKeyByName
> >
> >        When invoked, this method must perform the following steps:
> >
> >
> >
> >        1. Let promise be a new Promise and resolver its associated
> > resolver
> >
> >        2. Return promise and continue executing the following steps
> > asynchronously:
> >
> >            1. Search for a key matching the name specifier provided in
> name.
> > A name specifier matches the name of a key if they are identical when
> > expressed as a string of unicode characters.
> >
> >
> >
> >               If a key is found
> >
> >                   1. Let the result be an object of type NamedKey
> > representing the key
> >
> >                   2. Execute resolver's resolve(value) algorithm with
> > result as the value argument
> >
> >
> >
> >               Otherwise
> >
> >                   Execute resolver's resolve(value) algorithm with
> > null as the value argument
> >
> >
> >
> > Parameter       Type            Nullable        Optional
> Description
> >
> > name              DOMString       ✘               ✘
> >
> >
> >
> > Return type: Promise
> >
> >
> >
> > getKeyById
> >
> >        When invoked, this method must perform the following steps:
> >
> >
> >
> >        1. Let promise be a new Promise and resolver its associated
> > resolver
> >
> >        2. Return promise and continue executing the following steps
> > asynchronously:
> >
> >            1. Search for a key matching the id specifier provided in
> > id. A id specifier matches the id of a key if they are identical when
> > expressed as a string of unicode characters.
> >
> >
> >
> >               If a key is found
> >
> >                   1. Let the result be an object of type NamedKey
> > representing the key
> >
> >                   2. Execute resolver's resolve(value) algorithm with
> > result as the value argument
> >
> >
> >
> >               Otherwise
> >
> >                   Execute resolver's resolve(value) algorithm with
> > null as the value argument
> >
> >
> >
> > Parameter       Type            Nullable        Optional
> Description
> >
> > id                      DOMString       ✘               ✘
> >
> >
> >
> > Return type: Promise
> >
> >
> >
> >
> >
> >
> >
> > Regards,
> >
> > Michael
> >
> >
> > ________________________________
> > This message and any attachments are intended solely for the
> > addressees and may contain confidential information. Any unauthorized
> > use or disclosure, either whole or partial, is prohibited.
> > E-mails are susceptible to alteration. Our company shall not be liable
> > for the message if altered, changed or falsified. If you are not the
> > intended recipient of this message, please delete it and notify the
> sender.
> > Although all reasonable efforts have been made to keep this
> > transmission free from viruses, the sender will not be liable for
> > damages caused by a transmitted virus

This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited.
E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender.
Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus
Received on Friday, 11 October 2013 23:00:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:19 UTC