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

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
>

Received on Thursday, 25 April 2013 20:54:39 UTC