I think these mechanisms are interesting. I missed any original discussion on these but here are a few questions / comments:
pkcs11-global-values.docx:
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.
ckm_certify_key.docx:
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).
ckm-seal-key.docx:
Is there a use case for a session seal key?
Is there a compelling reason to limit seal keys to CKO_SECRET_KEY?
By CKA_EXPORTABLE do you mean CKA_EXTRACTABLE?
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.