[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Question w.r.t CKM_AES_KEY_WRAP_PAD
Hi Darren, we are in preparation for the implementation of CKM_RSA_AES_KEY_WRAP and CKM_ECDH_AES_KEY_WRAP, that's when our R&D team came across the questions about padding. It would be great to get whatever background info from Doron Cohen, thank you for getting in touch with him. I hope other TC members will provide feedback as well, and I'm copying the full committee. Thanks, Dieter -----Original Message----- From: Johnson Darren [mailto:darren.johnson@gemalto.com] Sent: Montag, 16. Januar 2017 15:51 To: Dieter Bong <Dieter.Bong@utimaco.com> Subject: RE: Question w.r.t CKM_AES_KEY_WRAP_PAD Ahh, well you've got me there :-) I had not really looked at those two mechanisms yet (CKM_RSA_AES_KEY_WRAP and CKM_ECDH_AES_KEY_WRAP) as our team has yet to make use of them here. I would agree 100% that those two are using RFC5649... however it is in direct contrast as to how CKM_AES_KEY_WRAP_PAD is . Those two mechanisms were added much more recently (2013) than CKM_AES_KEY_WRAP_PAD, so I wonder if we can dig up how added those? I did some poking around the document and email archive, and it turns out that they were added by "Mr Doron Cohen", with an email addred of Doron.Cohen@safenet-inc.com. So apparently he used to work with SafeNet. I should be able to find out something from him... maybe find out why he referenced the RFC. It turns out that he was a VP of Technology... so I can't grill him too hard :-). The good news is that if these mechanisms did come from SafeNet, and was more for internal use then it might be less painful to modify them vs changing the way CKM_AES_KEY_WRAP_PAD is documented. It's too bad he didn't publish his proposal to the rest of the engineering team at SafeNet to get feedback from a wider audience before pushing it to the PKCS11 committee. Maybe we would have spotted this inconsistency. Personally I think the two new mechanisms should be updated to remove reference to the RFC as CKM_AES_KEY_WRAP_PAD already documents how it pads (in my opinion). The fact that CKM_AES_KEY_WRAP_PAD is documented as supporting an optional IV as input (which is allowed by [AESKEYWRAP]) means that it is not compliant with the RFC. We should also update the CKM_AES_KEY_WRAP_PAD section to be more clear and not say "the usual padding" as that is way too vague for a standard. Whatever solution we pick will have no direct impact on my division as we implemented 800-38F variant. But some other SafeNet/Gemalto teams may be making use of it. So that may alter my opinion based on the best interest of our various teams :-) Maybe we should put out an email to the committee asking how the various teams have chosen to implement this (CKM_AES_KEY_WRAP, CKM_RSA_AES_KEY_WRAP, CKM_ECDH_AES_KEY_WRAP,. Depending on the outcome of that, a majority rules might be an acceptable solution if it also presents the less pain/problesm. Has your team started to use these mechanisms yet? Also, I just noticed that I replied directly to you on my initial response... we should probably push this thread to the full committee email list, agreed? DJ From: Dieter Bong [mailto:Dieter.Bong@utimaco.com] Sent: Monday, January 16, 2017 3:47 AM To: Johnson Darren <darren.johnson@gemalto.com> Subject: RE: Question w.r.t CKM_AES_KEY_WRAP_PAD Hi Darren, Thank you very much for your feedback. We were under the impression that RFC5649 is meant as padding mechanism, because sections 2.1.21 and 2.3.12 bring CKM_AES_KEY_WRAP_PAD into direct relation with RFC5649 when stating "Wraps the target key with the temporary AES key using CKM_AES_KEY_WRAP_PAD (RFC5649) ." , which I read as "CKM_AES_KEY_WRAP_PAD is doing RFC5649 padding on the RSA/EC target key to be wrapped". With that assumption, I have read "padding is done by the token before being passed to the AES key wrap algorithm" as "when calling CKM_AES_KEY_WRAP_PAD, the token performs RFC5649 padding and then wraps this padded input as specified in [AES KEYWRAP]". As the key wrap mechanisms have already been introduced by RSA Labs in PKCS#11 2.30 draft, it might be a bit difficult finding somebody to clearly stating the intention from back in 2009, but we'll see. And if no clarity can be reached within the next few weeks, I suggest to make this a topic for the f2f meeting. Thanks, Dieter From: Johnson Darren [mailto:darren.johnson@gemalto.com] Sent: Freitag, 13. Januar 2017 19:28 To: Dieter Bong <Dieter.Bong@utimaco.com> Subject: RE: Question w.r.t CKM_AES_KEY_WRAP_PAD Hi, In my opinion we should never silently ignore any input parameter, especially something like an IV as it gives the caller the wrong impression as to what is going on. I would answer this by saying that CKM_AES_KEY_WRAP and CKM_AES_KEY_WRAP_PAD follow the algorithm outlined in [AESKEYWRAP], which is the NIST draft spec. Not RFC5649 and not NIST SP800-38F... although SP800-38F does include and expand on the functionality in the draft spec. From the way I read the section on CKM_AES_KEY_WRAP_PAD, I don't think it is referring to the "AES Key Wrap with Padding Algorithm" that is outlined in either SP800-38F nor RFC5649. The PKCS spec reads "It does the usual padding", which I understand to mean the same PKCS padding scheme that is used by CBC_PAD. The NIST draft spec describes keywrap as being suitable for encrypting/wrapping structured/formatted data which supports the idea of pre-padding data it is encrypted/wrapped using the algorithm in the draft spec. The PKCS spec also reads "padding is done by the token before being passed to the AES key wrap algorithm" which I think also supports this interpretation. Unfortunately this is all just my interpretation and the interpretation we took on our teams, right or wrong. Because of the slight differences in the draft, SP800-38F and the RFC, we have added to additional vendor defined mechanisms to represent AES-KW and AES-KWP that are defined in SP800-38F. Does anyone remember who initially added the key wrap section? They might be able to clear up what their intent was. Thanks Darren From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On Behalf Of Dieter Bong Sent: Friday, January 13, 2017 11:20 AM To: pkcs11@lists.oasis-open.org Subject: [pkcs11] Question w.r.t CKM_AES_KEY_WRAP_PAD All, we came across the following question w.r.t PKCS#11 V2.40, chapter 2.14 AES Key Wrap: Section 2.14.2 "AES Key Wrap Mechanism parameters" gives the possibility of specifying some initial value. That makes sense for CKM_AES_KEY_WRAP, and is in line with [AES KEYWRAP]. The way we understand this section is that such initial value could also be provided as mechanism parameter for CKM_AES_KEY_WRAP_PAD. Yet RFC5649 does not foresee any "external" IV. How to deal with this? Just ignore any IV specified as mechanism parameter for CKM_AES_KEY_WRAP_PAD? Or be more restrictive and return an error? Or do we get something wrong? Can somebody please advise. Thanks, 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 Managementboard: Malte Pollmann (Chairman) CEO, Dr. Frank J. Nellissen CFO This communication is confidential. We only send and receive email on the basis of the terms set out at https://www.utimaco.com/en/e-mail-disclaimer/ _____ This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. _____ 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: Malte Pollmann (Chairman) CEO, Dr. Frank J. Nellissen CFO This communication is confidential. We only send and receive email on the basis of the terms set out at https://www.utimaco.com/en/e-mail-disclaimer/ ________________________________ This message and any attachments are intended solely for the addressees and may contain confidential information. Any unauthorized use or disclosure, either whole or partial, is prohibited. E-mails are susceptible to alteration. Our company shall not be liable for the message if altered, changed or falsified. If you are not the intended recipient of this message, please delete it and notify the sender. Although all reasonable efforts have been made to keep this transmission free from viruses, the sender will not be liable for damages caused by a transmitted virus. ________________________________ 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: Malte Pollmann (Chairman) CEO, Dr. Frank J. Nellissen CFO This communication is confidential. We only send and receive email on the basis of the terms set out at https://www.utimaco.com/en/e-mail-disclaimer/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]