W3C home > Mailing lists > Public > public-webcrypto@w3.org > August 2012

Re: ISSUE-17: Key Attributes - Proposed resolution

From: Ryan Sleevi <sleevi@google.com>
Date: Fri, 31 Aug 2012 14:31:31 -0700
Message-ID: <CACvaWvaBaf5tbvs-MG+C2+aN46VxxiNwoHdJEBdoynqNy7_K9g@mail.gmail.com>
To: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Cc: "public-webcrypto@w3.org" <public-webcrypto@w3.org>, Mitch Zollinger <mzollinger@netflix.com>, Mark Watson <watsonm@netflix.com>, Arun Ranganathan <arun@mozilla.com>
On Tue, Aug 28, 2012 at 7:41 AM, Vijay Bharadwaj <
Vijay.Bharadwaj@microsoft.com> wrote:

> Can we use "name-value pairs" instead of "key-value pairs" to avoid
> confusion about which type of "key" we're talking about?
> This doesn't match my read of the API:
> > Such attributes may be initialized during the provisioning of the Key
> object as part of the generateKey(), importKey(), or deriveKey() operations.
> AFAICT, generateKey() for example doesn't provide a way for specifying
> attributes during the generation. Should it?
> Other than that, I agree it captures the distinctions well. It does seem
> to leave a lot to the implementation with regard to deciding which
> attributes are read-only and which ones are not. I'd hope that after FPWD
> we can specify that in a little  more detail to avoid inconsistent
> implementations.

Curious what you meant by this.

For pre-provisioned keys (which are implementation dependent), I don't
think there's any way we can define what attributes are read-only without
defining an exhaustive set of what attributes may be needed, which may
require an exhaustive set of what types of keys may be pre-provisioned,
which may require an exhaustive set of defining what types of keys there
are. All problems I hope to avoid ;-)

For keys that are generated by this API, I would think that they would be
any attributes explicitly supplied during the (generate, import, derive)
phases, for which there is, admittedly, not a way to define those yet.
Alternatively, depending on ISSUE-38, we may go a different route, where
attributes can be defined until the key is "finalized".

Was there some other concern regarding implementation dependence though?
Received on Friday, 31 August 2012 21:31:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:01:26 UTC