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

Re: do we need secure removal function for keys in low level API?

From: Ryan Sleevi <sleevi@google.com>
Date: Thu, 25 Apr 2013 12:10:13 -0700
Message-ID: <CACvaWvbhGEZpgpG=wLz4ky=inMj0RjvLRib3Q+YuozxXENsxSg@mail.gmail.com>
To: Hutchinson Michael <Michael.Hutchinson@gemalto.com>
Cc: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>, Mountie Lee <mountie@paygate.net>, Web Cryptography Working Group <public-webcrypto@w3.org>
On Thu, Apr 25, 2013 at 12:06 PM, Hutchinson Michael
<Michael.Hutchinson@gemalto.com> wrote:
> In terms of removal...what happens if the key was cloned to IDB multiple times...does there also need to be a note about reference counting by the UA?
>
>>Michael

That's why I would explicitly prefer not to.

A Key object is structured cloneable.

If you vend Key A, then clone it into Key B, and attempt to erase Key
A, what does that mean?
Is Key B valid or not?

This relates to our neutering discussion, but "generally" speaking,
you don't have distinct objects affecting eachother - particularly not
with structured clone.

Expand the thought experiment further:
Key A at origin foo.example.com clones it to Key B at origin bar.example.com

Does foo.example.com attempting to erase A also affect B - a resource
at an entirely different origin?

For these reasons (and I'm sure we can find many more), I'm a huge -1
to the erasure.

I don't think a note for UAs can be suitably descriptive while
flexible - the requirements and nature for key storage have been
(intentionally) entirely omitted from the spec, so there's little that
we can say that doesn't also imply a particular view of key storage,
which I think would only serve to confuse the spec.

>
> -----Original Message-----
> From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com]
> Sent: Thursday, April 25, 2013 1:57 PM
> To: Ryan Sleevi; Mountie Lee
> Cc: Web Cryptography Working Group
> Subject: RE: do we need secure removal function for keys in low level API?
>
> I agree with Ryan that this should not impact the API itself.
>
> Look at the cases when keys are removed:
> 1. Key object is released. This is a UA issue. A careful UA might for example zeroize the memory.
> 2. Key object which was cloned to IDB is deleted from IDB. Again, a UA issue.
>
> At best, we might add a note to Section 5 that implementers should watch out for these.
>
> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Thursday, April 25, 2013 11:49 AM
> To: Mountie Lee
> Cc: Web Cryptography Working Group
> Subject: Re: do we need secure removal function for keys in low level API?
>
> On Wed, Apr 24, 2013 at 10:25 AM, Mountie Lee <mountie@paygate.net> wrote:
>> when key is generated,
>> I think how we can remove keys securely.
>>
>> key is sensitive data.
>> when remove, it should be unrecoverable.
>>
>> any comment?
>> --
>> Mountie Lee
>>
>> PayGate
>> CTO, CISSP
>> Tel : +82 2 2140 2700
>> E-Mail : mountie@paygate.net
>>
>> =======================================
>> PayGate Inc.
>> THE STANDARD FOR ONLINE PAYMENT
>> for Korea, Japan, China, and the World
>>
>
> This seems to be an implementation detail for UAs, not something that needs to be exposed to applications.
>
> The UA is responsible for deciding what keys are exposed and how key storage is maintained. The application does not have any intrinsic guarantees on the nature of keys or their storage - nor can it, given the way the web works, short of out-of-band knowledge (either of the UA and how it is implemented or of the keys, such as pre-provisioned keys).
>
> Further, there's no point specifying an API for secure erasure of key material, since the UA has plenty of opportunity to leak it within its implementation. Applications that are particularly sensitive to the set of regulatory frameworks that "require" secure erasure are thus equally dependent on the UAs operating in a mode compatible with those requirements, so there's nothing the application can or should do.
>
> So -1.
>
>
Received on Thursday, 25 April 2013 19:10:43 UTC

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