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

RE: ISSUE-17: Key Attributes - Proposed resolution

From: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Date: Tue, 4 Sep 2012 09:04:50 +0000
To: Ryan Sleevi <sleevi@google.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>
Message-ID: <382AD43736BB12439240773F68E90773AC9D6E@DF-M14-23.exchange.corp.microsoft.com>
I just think we need some kind of rule(s) for deciding when a given attribute on a key is read-only. Simple is fine (and in fact perhaps better). This isn't specific to pre-provisioned keys - in fact, I am hoping that pre-provisioning can simply leverage the same mechanism by "pre-marking" appropriate attributes as read-only.

Possible rules for when an attribute is read-only:

-          Attributes supplied in (generate, import, derive) phases are read-only. (I don't think finalizing changes this discussion - if you still need some attributes to be mutable after finalize, you still need a rule for deciding which these are.)

-          All attributes on a pre-provisioned key are read-only.

-          All attributes on a key used by more than one origin are read-only.

-          All attributes on all keys are read-only except before finalization.

-          All attributes on a key are read-only if the key has the "read-only" attribute set to true.

Would defining a constraint like the above make life easier for developers dealing with multiple browsers/platforms?

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Friday, August 31, 2012 2:32 PM
To: Vijay Bharadwaj
Cc: public-webcrypto@w3.org; Mitch Zollinger; Mark Watson; Arun Ranganathan
Subject: Re: ISSUE-17: Key Attributes - Proposed resolution

On Tue, Aug 28, 2012 at 7:41 AM, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com<mailto: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 Tuesday, 4 September 2012 09:06:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:13 UTC