RE: Wrap/Unwrap with DH

> 
> I seem to be believing that we've discussed this before.
> 
> Virally propagating extractability unconditionally isn't desirable - you
may wish
> to use a non-extractable key to derive an extractable key.

Do you have a use case where this is true?  I seem to be unable to think of
one easily.

> 
> However, I do agree that this also highlights why treating extractability
as a
> property delivered via JWK, as proposed by Netflix, rather than associated
> with/through some aspect of the API, is an undesirable solution limited to
a
> very specific use case, rather than being of general use.

I think that a large part of this might have to do with the fact that this
API is not keeping a strong distinction between keys and data.  There is a
large part of the security world that believes that one should not be able
to mix keys and data when doing processing.  This means that they believe
that an encryption algorithm should be able to only process data or only
process keys.  In this world the use of a JWK to deliver a key is normally
thought of as being data.

In this world view an algorithm would have at most one of encrypt and
wrapKey set.  This means that one would need to name two different
algorithms if one wished to have AES-GCM encrypt both keys and data.  (Note
that this is the approach that is being taken by the JOSE working group.)
If one does then then propagation of the extractable attribute is trivial as
one always propagates it when doing a key unwrap and it cannot be propagated
when decrypting the data.  

One still might have a question of how far one carries it for derivations,
the first one would be non-extractable but subsequent derivations might be
extractable.  It might also matter what method of derivation one provided as
well.

Jim

Received on Thursday, 18 July 2013 22:21:52 UTC