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

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.

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.

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

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.


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.

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

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

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?

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.

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


Is there a use case for a session seal key?

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


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.

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.

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:

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