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: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Date: Thu, 25 Apr 2013 18:56:38 +0000
To: Ryan Sleevi <sleevi@google.com>, Mountie Lee <mountie@paygate.net>
CC: Web Cryptography Working Group <public-webcrypto@w3.org>
Message-ID: <41cc121582404c20bc8159869447882f@DFM-DB3MBX15-07.exchange.corp.microsoft.com>
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 18:58:27 UTC

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