OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

pkcs11 message

[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

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.

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. 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. 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). 

Making it optional defeats that purpose. 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)

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. 


On Wed, Aug 17, 2016 at 10:35 AM, Valerie Fenwick <valerie.fenwick@oracle.com> wrote:
Submitter's message
Hi folks -

Here is the proposal on CKA_UUID attribute. please take a look.

-- Valerie Fenwick
Document Name: CKA_UUID Proposal from John Leser

Proposal to add CKA_UUID attribute. Red text is the new text being
Download Latest Revision
Public Download Link

Submitter: Valerie Fenwick
Folder: Documents
Date submitted: 2016-08-16 17:35:22

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]