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] Groups - RSA/ECC key agreement - update 1 uploaded


Hi Jonathan,

 

RFC5990 seems to be similar to SP800-56B RSASVE.Generate/Recover, but the actual key agreement also requires SP800-56B KAS1-basic (at least), which includes an nonce. Is this nonce the pSharedData in CK_RSA_KEM_PARAMS?

 

The NIST spec specifies a protocol in section 8.2.2 (figure 6) where the nonce is retrieved in a 2nd step. Therefore, it cannot be part of the parameter. Would it still be compliant if a pubkey and the nonce are retrieved at once and the shared secret is generated in one step?

 

However, we have only created a shared secret now and have to use it in a hybrid key-transport scheme (SP800-56B section 9.3). In a protocol, sending the wrapped key would be the last step since the transport key is already established. However, the goal of the CKM_RSA_AES_KEY_WRAP mechanism was to have an implicit protocol combining the encrypted transport key and the key wrapped with the transport key. CSPs are using it in that way (https://docs.microsoft.com/en-gb/azure/key-vault/keys/byok-specification). This would not be possible with CKM_RSA_KEM.

 

Also, it seems that CKM_RSA_AES_KEY_WRAP is the same as SP800-56B KTS-OAEP (section 9.2). Therefore, just for compliance reasons there is no need for a new RSA-based key wrapping mechanism.

 

The CKM_ECDH1_ONE_PASS_DERIVE mechanism is doing exactly the same as the first two steps of the CKM_ECDH_AES_KEY_WRAP mechanism. The actual key transport part is left as exercise to the user. And therefore, it does not solve the original problem that we had with CKM_ECDH_AES_KEY_WRAP: defining a structure combining the public EC key and the wrapped key in such a way that both parts can be split unambiguously and the key can be unwrapped.

 

So, my overall conclusion would be that we don’t need these mechanisms and we still need to solve the CKM_ECDH_AES_KEY_WRAP problem.

 

Regards,

Daniel

 

 

From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of Jonathan Schulze-Hewett
Sent: Freitag, 18. September 2020 14:27
To: pkcs11@lists.oasis-open.org
Subject: [pkcs11] Groups - RSA/ECC key agreement - update 1 uploaded

 

Submitter's message
Minor update to correct some oversights from yesterday.
-- Mr. Jonathan Schulze-Hewett

Document Name: RSA/ECC key agreement - update 1


Description
Updated to correct the mechanism name and to include references to
standards in all sections.
Download Latest Revision
Public Download Link


Submitter: Mr. Jonathan Schulze-Hewett
Group: OASIS PKCS 11 TC
Folder: Documents
Date submitted: 2020-09-18 05:27:02

 




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
Managementboard: Stefan Auerbach (Chairman) CEO, Malte Pollmann CSO, Martin Stamm CFO

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.


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