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

I meant the counter method for generateKey();

erasing key means not for the pointer (reference) of the key, but for the
key object itself.

when the key is generated by API, it will create the key object that is not
pointer of existing key.

but erasing generated key is out of scope?

logically there's a missing point.



On Thu, Apr 25, 2013 at 12:10 PM, Ryan Sleevi <sleevi@google.com> wrote:

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



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