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.

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?

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.

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. 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.

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.

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. 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.

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 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.

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

Received on Friday, 27 September 2013 21:41:47 UTC