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:
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.
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.
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.
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'?
Ok.
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? :-)
ckm-seal-key.docx:
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.
By CKA_EXPORTABLE do you mean CKA_EXTRACTABLE?
Yes.
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 <>
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.
Mike
I've seen no comments at all on this re-working. Is there no
interest? Anti-interest? Pro-Interest?
Mike
---------------------------------------------------------------------
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:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Attachment:
pkcs11-global-values.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document
