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] Re: Updates to CKA_GLOBAL, CKM_CERTIFY_KEY and CKM_SEAL_KEY

On 6/4/2013 1:28 AM, Darren Krahn wrote:
I think these mechanisms are interesting.  I missed any original discussion on these but here are a few questions / comments:


The term 'HSM' seems specific, should we consider a more general term?  Perhaps 'device' would fit, it seems in line with the base spec.

Maybe cryptographic module or security module.  Device is too generic.

1.1.1 / 1.1.2 Token / Platform Identity:

This kind of permanent identifier can be a privacy concern.  It would be nice to see some kind of configurable access control on these objects instead of mandatory public access.

This was sort of what happened with the TPM, but the model here is quite a bit different.  The TPM is tied to individual PCs which tend to be assigned to individuals and that has some interesting privacy concerns.  That said, I think the TCG went off the rails on how they solved that problem.  And you still have the concept of an EK (endorsement key) and EK cert (which *is* signed by the manufacturer).  This is a first cut to get an EK and EK Cert into the device.  If someone else wants to write up the TPM CreateIdentity and ActivateIdentity stuff later, that shouldn't be precluded.

"The certificate shall be signed by the manufacturer of the HSM":  This seems overly restrictive.  It would be good to include TPM-like endorsement models where the issuer of the identity certificate may be independent of the manufacturer and where the identity certificate is not hardware-permanent.

This is the TPM EK, not a TPM AIK.  And I think the AIK model is just weird.

2 Mechanisms for per token...

Can these be folded into section 1.1 Valid object IDs?

3 Key Certification Mechanism

This looks like duplicated content from the certify key doc.

I attached the wrong document.  Here's the right one.  This one expands the set of global objects and types of global objects.


It doesn't seem very useful to certify keys with a signing key which can also sign arbitrary data.  We could do something like define a CKA_CERTIFY attribute which is [recommended to be] mutually exclusive with CKA_SIGN.

Actually, the way you handle this is by limiting the mechanisms allowed for those keys.  But I take your point that a certify key should only be used with the CKM_CERTIFY_KEY mechanism.  I'll note this for change.

Is there a compelling reason to make CKA_PUBLIC_KEY_INFO a mandatory certified attribute?

In the TPM, the public key is always part of the private key, and what you certify is the public data of the private key.  In PKCS11 we only have a weak relationship between a public key object and a private key object, and I don't see any reasonable way to cryptographically link the two in a certify blob.  What I want to do is certify that the private key associated with a specific public key is locked to a specific token (e.g. if I'm issuing a certificate, I'd really rather not issue one to a soft token). That means I need to certify data that is enforceably part of the private key.  Hence CKA_PUBLIC_KEY_INFO (or rather the actual contents of that attribute) as the base data to be certified.

Should we define a variant, or another similar mechanism, to support opaque output formats or other standards (e.g. TPM_CERTIFY_INFO)?

I hope not.

In addition to CKA_LOCAL, CKA_ALWAYS_SENSITIVE and/or CKA_NEVER_EXTRACTABLE may also be good attributes to recommend.  Also, can we clarify 'valid cryptographic relationship'?


I'm probably missing something, but I don't see why the random nonce as suggested in the last paragraph is useful enough that we would recommend it as good practice.  It may be equally useful to have a certification blob that is independent of the original requester, no?

Both are useful.  The nonce one allows you to lock the certify operation to a particular point in time from the acceptors POV.  It may be important to know that the key existed at one specific point in time.  And it makes sense for the general contract for C_Sign.

Regarding the format of signed data, we may want to specify that attributes which are of type CK_ULONG are encoded as 32-bit values.

Not necessary.  The receiver has to get all of the data that was signed so that it can verify the signature.  That includes the length of the object.

Regarding array attributes, since we've defined how to serialize a list of attributes it seems natural to allow them as blobs serialized using the same technique.  We may want to limit depth though (i.e. array attributes must not contain array attributes).

You mean like CKA_WRAP_TEMPLATE?  :-)


Is there a use case for a session seal key?

Yup.  I need to generate 10K session keys for various purposes.  I can't store them in the HSM because I only have space for 1K keys.  I want to make sure the keys are unusable after the session ends.

Is there a compelling reason to limit seal keys to CKO_SECRET_KEY?

Mechanisms are generally tied to a particular class of object.  This mechanism is a secret key mechanism.  Mostly I can't see much use for a public key version of this for this specific type of mechanism.



Should we add some way to input implementation-specific configuration / measurement data?  An implementation may use such data to control the conditions under which the key can be unsealed.  If we do this then we may also want to define a similar CKM_SEAL_DATA encryption mechanism.

Later maybe.  I touch on it briefly in the CKA_GLOBAL document, but that's a whole new set of things we don't do here.

Mostly I'd add the whole measurement stuff as a new set of hardware class objects, and then add specific mechanisms to fold those measurements in.

I can see the use for sealing non-extractable keys but we may want to leave it up to the implementation as to whether any particular key can or cannot be sealed.

Yes, but mostly the seal mechanism is less useful if you don't implement this.  Use a normal wrapping mechanism instead.

On Tue, May 28, 2013 at 10:56 AM, Michael StJohns <msj@nthpermutation.com> wrote:
On 5/15/2013 11:28 AM, Michael StJohns wrote:
See attached.  This is a reorganization along the lines suggested by Tim, with some additional text and clarifications.

These documents are somewhat tied to each other as there are references that go both ways in the body of each text.


I've seen no comments at all on this re-working. Is there no interest?  Anti-interest?  Pro-Interest?


To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:

Attachment: pkcs11-global-values.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document

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