[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [pkcs11] Groups - CKA_UUID Proposal from John Leser uploaded
Hi Tim,Thanks for the great feedback, my comments are in-line. As Valerie mentioned, I'm definitely looking for feedback to get his proposal in the best possible shape to meet everyones needs. This will (hopefully) become a core feature to PKCS#11, so its important to get it right.
On 08/16/16 08:54 PM, Tim Hudson wrote:
As per the previous discussions on the topic, I think the proposal mixes up a couple of different concepts - and I don't think we adequately captured the "requirements" from the last discussion so I've attempted to do so below.
It's true, I don't know all of the requirements here. I am familiar with the previous UUID discussion on one of the PKCS#11 lists. One of my primary motivation for this proposal is to enable movement of objects from PKCS#11 into other stores (KMIP, database, etc) and back reliably.
Basically the existing CKA_ID and CKA_LABEL values are unsuitable for uniquely identifying and object on a given token as they are both not required to be set, and is not required to be unique, and are allowed to be modified.
What the original concepts where around the CKA_UUID discussion was to basically have a value that must be present, is provider-assigned, and is unique for the given provider - so that for any use referencing and object on a provider (either token or non-token) you can safely identify the same object across multiple sessions. This is the issue for which multiple vendors have provided their own approaches - and is relatively easy for implementations to support.
I think the proposal is OK wrt. these requirements.
The concept was also (like in KMIP) to not specify the format of the unique identifier (as we don't currently specify that for the CKA_ID or CKA_LABEL and we don't specify that in KMIP) so that whatever implementation limits exist within a provider are able to be handled.
I personally disagree a bit with the direction KMIP went in this regard.I like the idea specifying the format on the data, especially maximum field size, so that applications can guarantee that they will be able to store and compare identifiers originating from any token. I like RFC 4122 UUIDs because 128 bits is enough to choose identifiers randomly with sufficient likelihood of success. Allowing more space than this seems to gain us nothing, while making all code that handles object UUIDs more complex.
For vendors that have already implemented a non-standard unique ID, RFC 4122 section 4.3 describes methods for converting those names into a UUID via hashing.
However, I think my proposal goes wrong by implying that one of the RFC 4122 methods must be used to generate the UUID. As a minimal case for supporting the feature, it should be permissible for devices with stable storage to treat the 128-bit field as a simple counter. This guarantees IDs that are unique to on the token, placing minimum hardware requirements on the token.
Does it make more sense to describe the CKA_UUID field as an opaque, 16 byte value, rather than an RFC 4122 UUID, then recommend RFC 4122 generation methods in the description? If we do that, do we need to provide a way for applications to determine whether or not the ID is a genuine UUID (And is therefore likely to be unique globally)?
Whether and object is a token-object or not the same applies - we need to be able to uniquely reference it - in a reliable cross-application manner (although cross-application doesn't apply to non-token objects the concept isn't limited to token-only objects).
I disagree here somewhat. Typically, applications use session objects via their handles. Generating a UUID may introduce unwanted overhead for what are essentially ephemeral objects. I couldn't think of any use case for the CKA_UUID attribute on a session object, so it felt odd to require it.
Making it optional defeats that purpose.
I agree, and hoped we'd consider making them required for PKCS#11 3. I was under the impression we couldn't do so for 2.x, so it seemed reasonable to introduce it as optional to ease the transition.
Forcing a particular format (RFC 4122) will break the ability to implement for a large range of devices (dependency on a clock or on a specific unique device identifier). Leaving it such that basically current vendor approaches can be easily mapped is an advantage (and those range from a simple unique incremented integer, through to GUIDs)
I agree, and I've hopefully addressed this above.
Importing and exporting of objects between providers and attempting to provide a guaranteed universally unique identifier is a separate topic and should be kept separate IMHO - as it hits the whole issue of what are we attempting to achieve if we want to move objects between providers while preserving their entire state - and there is more to the state in most implementations that what is reflected in PKCS#11 currently.
Are you suggesting two additional identifiers? Given the growing needs of organizations to do complex management (backup, escrow, etc) of objects (keys), I don't really see the point of adding another identifier that is not sufficiently specified for use as a GUID. That's why I added words to ensure that C_CreateObject and C_UnwrapKey do the right thing WRT importing and generating CKA_UUID values.
Tim. On Wed, Aug 17, 2016 at 10:35 AM, Valerie Fenwick <email@example.com <mailto:firstname.lastname@example.org>> wrote: /Submitter's message/ Hi folks - Here is the proposal on CKA_UUID attribute. please take a look. Valerie -- Valerie Fenwick *Document Name*: CKA_UUID Proposal from John Leser <https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=58729> ------------------------------------------------------------------------ *Description* Proposal to add CKA_UUID attribute. Red text is the new text being proposed. Download Latest Revision <https://www.oasis-open.org/apps/org/workgroup/pkcs11/download.php/58729/latest/CKA_UUID-Rev1.doc> Public Download Link <https://www.oasis-open.org/committees/document.php?document_id=58729&wg_abbrev=pkcs11> ------------------------------------------------------------------------ *Submitter*: Valerie Fenwick *Group*: OASIS PKCS 11 TC *Folder*: Documents *Date submitted*: 2016-08-16 17:35:22