Re: [W3C Web Crypto WG] - Comments on Draft API v21

On Mon, Aug 27, 2012 at 10:42 AM, Ali Asad <Asad.Ali@gemalto.com> wrote:
> Thanks to the editors for putting together the draft API document.
>
>
>
> Here are some comments on the Draft API, I looked at version 21 from Aug
> 23rd. Some are editorial while other may require some discussion.
>
>
>
> General, sample code:
>
> It will be good if some sample source code can be included to help
> developers better understand the API. Perhaps we create an action item for
> this?
>
>
>
> Section 4, Scope:
>
> I suggest that an overview of the API and its capabilities could be included
> in the scope section.
>
> Here is one suggestion :
>
> “The Web Crypto API allows applications to generate keys with usual
> characteristics such as algorithm, usage, etc. However, some additional
> attributes can also be associated with keys, thereby allowing applications
> to do thing such as: indicate the origin(s) permitted to use the key (under
> definition); the rights for application to extract the key value; the key
> validity period; the duration of the key (is it temporary or does it exist
> across browser session). The API will also be offering the capabilities to
> query keys (under definition), to clone keys, to neuter keys, to import or
> expert keys. Those last features are under discussion in the Web Crypto
> Working Group.”

I'm concerned about adding too much normative text for open ISSUES.
It's a reasonable perception that once text has appeared within a
draft, then there's more work to "remove" it then to add it in.
Equally, I'm sure that some may perceive by it not being there, it's
presuming it won't be implemented, and thus it's harder to get
agreement on.

Given how broad and wide this API already is, I'd rather err on the
side of caution, and thus simply highlight existing ISSUES, without
committing via text to one position or another. Cloning, neutering,
and multi-origin are three examples of areas where consensus has not
yet been reached about whether to support them at all - let alone
their semantics if they are.

>
> I think this was also mentioned earlier in one of Virginie’s mails to
> improve wording for defining in-scope and out-of-scope
> http://lists.w3.org/Archives/Public/public-webcrypto/2012Aug/0134.html
>
>
>
> Section 5.1, security considerations:
>
> This section has the following text in the third paragraph,
>
>
>
> “Such mitigations may include restricting a generic key ("tainting") once it
> has been used with a specific algorithm or operation, and only permit
> applications to use that key with that same algorithm or operation in the
> future.”
>
>
>
> This mitigation suggestion is misleading. The reader may understand that the
> tainting could be made by the user agent. If it were the case, it would
> introduce fragmentation in application behavior. The tainting should be
> under the control of the application itself and should not fall in the scope
> of user agent initiative.

It's not misleading. That was the intent. The user agent SHOULD handle tainting.

This is especially critical if multi-origin access is to be permitted,
since there is no way for multiple origins to agree upon the
acceptable usage of a shared key - and worse, if they could, it may
offer a side-channel for communication that undermines the browser
privacy/security model.

If this justification isn't enough, we should open an ISSUE on it, but
I think this one is important, and perhaps normatively so. If it's
controversial, we can remove it, but I think any hope of multi-origin
access MUST have this.

Further, the only reliable place to store this tainting information is
within the key attributes, assuming we implement them. Because keys
may live longer than other storage mechanisms (eg: IndexedDB, Web
Storage), the only way to reliably store tainting information is with
the key. Thus, is it reasonable to expect every other application to
do this same thing?

Note that the concept of tainting is not unique to this proposal, and
other proposals (notably, anything related to CORS) already requires
user agents implement such mechanisms, although doing so regarding
origins.

It does sound like an ISSUE needs to be open about this.

>
>
>
> Suggestion : Move the sentence to 5.2 (security considerations for
> developers) section where it seems to be more relevant.
>
>
>
> In section 5.2, security considerations:
>
> This section talks about key security from a developer’s perspective, but
> does not mention that key can be stored securely in a secure element such as
> a smart card. While developers have no guarantee that keys residing in local
> storage, or indexed DB are safe, secure element storage does offer this
> assurance. This scenario should be pointed out here.
>
>
>
> Suggestion : raise an issue, so that correct working can be agreed on.

Please do raise such an issue.

User agents are NOT required to implement support for secure elements
or smart cards, nor (again, speaking as one implementation) if they do
implement, are they likely to expose it to 'any' web origin. Thus, I
don't know how well this can be promoted as a general purpose solution
- it's very much tied to particular implementations.

Also, with the above text, "local storage, or indexed DB" is a
misinterpretation of the text. It's talking about device storage.
"local storage, or indexed DB" are two different APIs for storing
name/value pairs (where name is typically called 'key', but for
purposes of disambiguation, shall be called name). Just wanted to make
sure we're on the same page.

Equally, secure element access has its own security considerations, as
mentioned in 5.2, so the overall recommendation stands regardless of
device storage vs secure element.

It would be helpful if you could propose some text that you think
might address these concerns.

>
>
>
> Section 6, privacy consideration:
>
> In this section the definition of ‘origin associated with a key’ is missing.
>
>
>
> Suggestion : Perhaps include an overview of the different characteristics of
> the API in the section 4 related to the scope. Also see the comment related
> to section 4 above.

I'm not sure I follow this comment. Do you have proposed text?

>
>
>
> Section 18, method naming:
>
> This section defines the  crypto interface, some method names may be
> confusing to developers. For example, createEncryptor() returns a
> CryptoOperation object which is then used to actually do the encryption.
> This is logical. However, generateKey() actually returns a key generator
> object. The caller then invokes generate() on this object to actually
> generate the key. We need to review the method naming and make it
> consistent, e.g. perhaps calling this method createKeyGenerator().

Agreed. This general API needs work.

However, I'll also note I really dislike the create* foo naming, so
I'll open an ISSUE on the broader concern.

>
>
>
> Section 18.1.3, typo:
>
> In this section the first hyperlink to CryptoOperation is broken. It is
> missing a # tag. [Just a note for the editors]

Thanks

>
>
>
> Section 18.1.6,  generateKey() method:
>
> ISSUE-26 : About the origin definition, I think we should have an origin
> associated with a Key, which will be read only. In case multiple origins are
> associated with the Key, then specific key usage should be specified for
> each origin.

1) We've not yet decided on how multi-origin will work, so I'm
hesitant to introduce any normative text
2) Can you provide a use case that clearly demonstrates where distinct
key usages per origin would be appropriate and/or necessary?

Key Usage at it's core is, I believe, a functional attribute. There is
a specific set of Key Usages that define how (all) applications may
use it. This is equally a concept that is consistent across a
wide-variety of cryptographic APIs, where key usage means literally
that - the usage for the key. Not "the usage for the key for the
application"

If we want to tighten that up for different origins, then that's
something we can discuss, but as it is, I have trouble seeing the use
case. And again, multi-origin access is unspecified at present.

Just wanted to make sure I understood this to be a comment specific
for ISSUE-26, and not a proposed change in functionality. If the
latter, it may be good to raise it in a new mail tagged as ISSUE-26
for further discussion.

>
>
>
> Section 18.1.10 , keys attribute:
>
> It is not clear what granted access mean in the sentence : “The keys
> attribute provides access to the persistent key storage for a particular
> origin. Keys that have been generated by, imported into, or otherwise had
> access granted to a particular origin will be available via this attribute.”
>
>
>
> Does the granted access include the mutual authentication before accessing
> smart card content for example ?

No.

How a user agent "grants access" to a pre-provisioned key is something
that will be implementation specific, because the very nature of
pre-provisioned key storage is implementation specific.

The minimal implementation intended would simply be an association of
metadata "If you see this key on this particular smart card, Origin A
is authorized to use it". No communication with the smart card is
needed. In fact, the smart card may not even be present at the time
that Origin A enumerates window.crypto.keys, nor at the time it tries
to create a CryptoOperation from it. When Origin A attempts to use it,
the user agent MAY decide to prompt the user (based on its
foreknowledge of how the key is stored in a way relevant to the user
agent) to insert the card. Or it MAY fail the operation.

Alternatively, a user agent MAY require that before exposing a key to
window.crypto.keys, that mutual authentication has been performed with
the smart card and that the session is authenticated.

The performance characteristics of this ONLY become an issue IF an
origin is using pre-provisioned keys AND and the user agent supports
them. Thus, it's an issue between the origin and the user agent to
decide the most appropriate way of exposing/communicating this.

Further, I believe user agents will agree upon (without needing to
mandate) the "right" behaviour, in as much as you don't need to turn a
Key into an underlying "cryptographic handle" until it's used within a
CryptoOperation, so the "cost" of initializing window.crypto.keys with
all authorized keys should be 0 (or "no more than document.cookie or
document.location")

Received on Monday, 27 August 2012 22:12:08 UTC