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