Re: ISSUE-17: Key Attributes - Proposed resolution

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?