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

Hi.
I understand the scoping.

but

please share the idea that
how the "key material" can be erased when user need or agree / or web
application need or agree?

regards
mountie.


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

> On Thu, Apr 25, 2013 at 1:40 PM, Mountie Lee <mountie@paygate.net> wrote:
> > I meant the counter method for generateKey();
> >
> > erasing key means not for the pointer (reference) of the key, but for the
> > key object itself.
>
> The comments from Vijay, Michael, and myself all reflected that
> understanding - we're talking about the key material, not the key
> object. All of our comments are consistent with that.
>
> >
> > 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?
>
> Yes.
>
> >
> > logically there's a missing point.
> >
>
> No. Hopefully the above replies will make more sense when understood
> that we were all on the same page of talking about key material.
>
> >
> >
> > 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
> >
>



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