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

Re: ACTION-114: Make proposal to amend api

From: Ryan Sleevi <sleevi@google.com>
Date: Tue, 15 Oct 2013 18:46:22 -0700
Message-ID: <CACvaWvatTzneiTRJKLeK562v4sDFX2E37wOeHEmyzFJ0C5GEjQ@mail.gmail.com>
To: Hutchinson Michael <Michael.Hutchinson@gemalto.com>
Cc: Mark Watson <watsonm@netflix.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
On Fri, Oct 11, 2013 at 4:00 PM, Hutchinson Michael <
Michael.Hutchinson@gemalto.com> wrote:

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

Why?

We should use proper structures for binary data - eg: ArrayBuffer /
Uint8Array.

Why force a copy to base64 from the original contents, and then from base64
when a user wishes to decode?


> I was trying to keep the UA requirement to a minimum and put the onus on
> the web application to manage the data itself.
>

Why is the UA required to do anything here? This seems like it can entirely
be implemented in the web application.


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

I suspect there's some fundamental misunderstanding of certificates, but
the pair of issuer distinguished name + serial number are "supposed" to be
unique (as they feed into CRLs and OCSP), but in practice even some CAs
have trouble with this.

Regardless, using the CN rather than the DN is just a recipe for disaster.
A huge number of intermediate and root CA certificates entirely omit the CN.


>
> >
> > 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 was suggesting this is the wrong approach. This has nothing to do with
NamedKeys, it would seem.


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

I wouldn't want to see this WG take up the Certs-as-NamedKeys.


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

Both privacy and performance reasons -
http://www.w3.org/2001/tag/doc/privacy-by-design-in-apis#action-based-availability

I do not at all see the necessity for why a site would need to 'discover' a
certificate or key it specifically pre-provisioned; that's the entire point
of "Named" keys - there's no discovery necessary because it's known a
priori.


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

If you propose that SOP means that only foo.com's keys are accessible,
there is no need for discovery - you know the data beforehand, when you
pre-provisioned.

For example, a hypothetical server that co-operates with a hypothetical
user agent, where keys named "foo" are provisioned via NamedKey, the server
can always look up the associated certificate (or any other metadata) on
the backend by examing the name/ID and looking that up in a table of
[name/id]->[certificate].

There's no need for the client to store or expose the associated
certificate.

I dislike the general idea of named keys, since it obviously implies UAs
doing site-specific hacks that prevent a global and interoperable web, but
if you're going to go down that road, then in for a penny, in for a pound.


>
> > 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 Wednesday, 16 October 2013 01:46:50 UTC

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