RE: ISSUE-17: Key Attributes - Proposed resolution

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?