Hi Dieter,
great feedback, as always.
For the two key derivation attribute rules, lets discuss it some more. I'm not sure I agree with your proposed changes.
I've tried to provide a better/different explanation as to why I think it should be they way I've documented it. Hopefully that helps you understand my mindset. and will help you either agree with me, or help you point out my misunderstanding.
Thanks
Darren
Key Derivation Attribute Rules (section 6.42.7) 2nd bullet, 2nd sentence
I wonder whether "If the base key or one of the additional input keys has itstheir CKA_ALWAYS_SENSITIVE attribute set to CK_TRUE, then ..." is correct. In order to declare the opposite case of the 1st sentence, I think we must state "If the base key and all of the additional input keys has itstheir CKA_ALWAYS_SENSITIVE attribute set to CK_TRUE, then ...". Must we?
[DJ]
I think my mistake is in the first sentence, and the second sentence is fine. So I think it should be like this.
If the base key and all of the additional input keys have their CKA_ALWAYS_SENSITIVE attribute set to CK_FALSE, then the derived key(s) will as well. If the base key or one of the additional input keys have their CKA_ALWAYS_SENSITIVE attribute set to CK_TRUE, then the derived key(s) will have their CKA_ALWAYS_SENSITIVE attribute set to the same value as its CKA_SENSITIVE attribute
So my reasoning is the same as I use just below. For the first sentence, if all the input keys all ALWAYS-SENSITIVE=false, then we must force the derive keys to be ALWAYS-SENSITIVE=false. But if one of them is ALWLAYS-SENSITIVE=true, then we don't need to force the derived keys to be ALWAYS-SENSITIVE=false.
For the second sentence I believe it is the same. If at least one of the input keys is ALWAYS-SENSITIVE=true, then the derived keys can be ALWAYS-SENSITIVE=true as well. So the derived keys will be set base on their value of CKA_SENSITIVE.
Key Derivation Attribute Rules (section 6.42.7), 3rd bullet
This is even more complicated due to the inverse logic of NEVER_EXTRACTABLE. If any of the base or additional keys has ever been extractable, then I have to set NEVER_EXTRACTABLE for the derived key(s) to FALSE. Picking up your proposal, I think we must state "Similarly, if the base key or any of the additional input keys has itstheir CKA_NEVER_EXTRACTABLE attribute set to CK_FALSE, then the derived key(s) will, too. If the base key and all of the additional input keys has itstheir CKA_NEVER_EXTRACTABLE attribute set to CK_TRUE, then the derived key(s) has its will have their CKA_NEVER_EXTRACTABLE attribute set to the opposite value from its CKA_EXTRACTABLE attribute."
[DJ] For the first sentence, I still think it should be "and all". Because if any of the input keys are NEVER-EXTRACTABLE=TRUE, that is all we need for the derived keys to be NEVER_EXTRACTABLE=true. If any of the input keys are NEVER-EXTRACTABLE=true, we don't need to force all of the derived keys to be NEVER-EXTRACTABLE=false. There is no way to use the other input keys that might have been extracted to compromise or recover the derived keys because one of the input keys is NEVER-EXTRACTABLE=true. This is similar to any counter/concatenation KDF where you have one secret value and some other fixed/known/context data. Because one piece of input is kept secret, that means that the derived key(s) are secret.
Given that understanding, that means that we would need ALL of the input keys to be NEVER-EXTRACTABLE=FALSE for the derived keys to be forced to be NEVER-EXTRACTABLE=FALSE.
I think the same logic carries over to the second sentence. If at least one input keys NEVER-EXTRACTABLE=TRUE, that is enough to allow the derived keys to be NEVER-EXTRACTABLE=!CKA_EXTRACTABLE. We have one secret value and some other publicly known values all passed to a KDF; and the resulting derived key(s) are still secret.
------------------------------
Darren Johnson
THALES
------------------------------
Original Message:
Sent: 04-16-2024 10:33
From: Dieter Bong
Subject: Additional Input Key Handles for SP800-108 KDF uploaded
Hi Darren,
Here are my questions and suggestions to your Key Handles proposal.
Your question in table 193 "Data Field Types"
the description is not too complicated but may IMHO nevertheless be simplified a bit, like "Identifies the key handle for an object with CK_OBJECT_CLASS set to CKO_SECRET_KEY. If specified, this data type will be interpreted as an instance of CK_SP800_108_BYTE_ARRAY where pValue points to the buffer containing the CKA_VALUE attribute of the provided key handle, and ulValueLen is assigned the value of the CKA_VALUE_LEN attribute of the provided key handle." (italics font indicates modified wording).
Key Derivation Attribute Rules (section 6.42.7) 2nd bullet, 2nd sentence
I wonder whether "If the base key or one of the additional input keys has itstheir CKA_ALWAYS_SENSITIVE attribute set to CK_TRUE, then ..." is correct. In order to declare the opposite case of the 1st sentence, I think we must state "If the base key and all of the additional input keys has itstheir CKA_ALWAYS_SENSITIVE attribute set to CK_TRUE, then ...". Must we?
Key Derivation Attribute Rules (section 6.42.7), 3rd bullet
This is even more complicated due to the inverse logic of NEVER_EXTRACTABLE. If any of the base or additional keys has ever been extractable, then I have to set NEVER_EXTRACTABLE for the derived key(s) to FALSE. Picking up your proposal, I think we must state "Similarly, if the base key or any of the additional input keys has itstheir CKA_NEVER_EXTRACTABLE attribute set to CK_FALSE, then the derived key(s) will, too. If the base key and all of the additional input keys has itstheir CKA_NEVER_EXTRACTABLE attribute set to CK_TRUE, then the derived key(s) has its will have their CKA_NEVER_EXTRACTABLE attribute set to the opposite value from its CKA_EXTRACTABLE attribute."
Error codes
I am ok with simply returning CKR_KEY_HANDLE_INVALID in all cases.
I am ok if the error returned does not make a distinction between attributes of base key and additional key(s).
General suggestion
I suggest to define a generic type CK_KEY_HANDLE instead of CK_SP800_108_KEY_HANDLE. This opens the possibility to use a key handle in other (key derivation) mechanisms in future.
Best regards / Viele Grüße,
Dieter
Utimaco IS GmbH
Germanusstr. 4, D.52080 Aachen, Germany, Tel: +49-241-1696-0, www.utimaco.com
Seat: Aachen – Registergericht Aachen HRB 18922
VAT ID No.: DE 815 496 496
Managing Directors: Stefan Auerbach, Martin Stamm, Hacan Tiwemark
You will find our data protection information for customers and business partners here.
This communication is confidential. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. Please inform us immediately and destroy the email.
Original Message:
Sent: 4/10/2024 4:56:00 PM
From: Darren Johnson
Subject: Additional Input Key Handles for SP800-108 KDF uploaded
Document Name: Additional Input Key Handles for SP800-108 KDF
Description
This proposal suggests adding a new data type "CK_SP800_108_KEY_HANDLE"
to the list of supported CK_PRF_DATA_TYPES currently supported by the
PKCS#11 v3.x specification. The new data type "CK_SP800_108_KEY_HANDLE"
can be used to specify a handle for an existing symmetric key object that
is already on the token that is to be included in the constructed PRF input
data
Download Latest Revision
Public Download Link
Submitter: Mr. Darren Johnson
Group: OASIS PKCS 11 TC
Folder: Working Drafts
Date submitted: 2024-04-10 20:55:54
|
---------------------------------
Darren Johnson
THALES
---------------------------------