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

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

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.



On Wed, Aug 17, 2016 at 10:35 AM, Valerie Fenwick
<valerie.fenwick@oracle.com <mailto: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
    *Group*: OASIS PKCS 11 TC
    *Folder*: Documents
    *Date submitted*: 2016-08-16 17:35:22

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