OASIS PKCS 11 TC

Hi folks- We want to really start moving forward on 3.0, and we have a few items that are approaching readiness for ballot. But, we really don't want to take things to ballot if they need changes before they can be approved :-) to that end, please take time before our next meeting to review and give feedback to the authors on. I have provided the public links as well, if you find that useful: * New function proposal draft 3(Bob R): WG link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=58225 PUblic Link: https://www.oasis-open.org/committees/document.php?document_id=58225 * Updated AEAD Proposal (Bob R.): WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=57976 Public Link: https://www.oasis-open.org/committees/document.php?document_id=57976 * AES GCM Changes form AEAD API (Bob R.): WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=57637 Public Link: https://www.oasis-open.org/committees/document.php?document_id=57637 * PKCS11 Wrapping with templates - v2 (Graham S): WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=58092 Public link: https://www.oasis-open.org/committees/document.php?document_id=58092 * Adding attributes to wrapped keys - (Graham S): WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=58091 Public Link: https://www.oasis-open.org/committees/document.php?document_id=58091 Please complete your review by Monday, June 6, to give the author time to incorporate your suggested changes and have a moment for you to we review that they got them right before our next meeting on June 8. Thank you so much! There is a lot here, but once we start knocking some of these things off, there will be less :-) If I missed one of the documents we're currently reviewing, please let me know. I know documents like the DSA one are awaiting further updates. I hope to have my proposal for constant identifier allocation out shortly. Valerie -- Note: I am using voice recognition software. Forgive any strange words. Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva Solaris Cryptographic & Key Management Technologies, Manager Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.

of course I find the missing one as soon as I hit send: * This is the ECDH key derivation proposal draft 1.(Dieter) WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=57917 Public link: https://www.oasis-open.org/committees/document.php?document_id=57917 Thank you, Valerie On 5/31/2016 2:45 PM, Valerie Fenwick wrote: Hi folks- We want to really start moving forward on 3.0, and we have a few items that are approaching readiness for ballot. But, we really don't want to take things to ballot if they need changes before they can be approved :-) to that end, please take time before our next meeting to review and give feedback to the authors on. I have provided the public links as well, if you find that useful: * New function proposal draft 3(Bob R): WG link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=58225 PUblic Link: https://www.oasis-open.org/committees/document.php?document_id=58225 * Updated AEAD Proposal (Bob R.): WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=57976 Public Link: https://www.oasis-open.org/committees/document.php?document_id=57976 * AES GCM Changes form AEAD API (Bob R.): WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=57637 Public Link: https://www.oasis-open.org/committees/document.php?document_id=57637 * PKCS11 Wrapping with templates - v2 (Graham S): WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=58092 Public link: https://www.oasis-open.org/committees/document.php?document_id=58092 * Adding attributes to wrapped keys - (Graham S): WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=58091 Public Link: https://www.oasis-open.org/committees/document.php?document_id=58091 Please complete your review by Monday, June 6, to give the author time to incorporate your suggested changes and have a moment for you to we review that they got them right before our next meeting on June 8. Thank you so much! There is a lot here, but once we start knocking some of these things off, there will be less :-) If I missed one of the documents we're currently reviewing, please let me know. I know documents like the DSA one are awaiting further updates. I hope to have my proposal for constant identifier allocation out shortly. Valerie -- Note: I am using voice recognition software. Forgive any strange words. Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva Solaris Cryptographic & Key Management Technologies, Manager Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.

About my work item (Key Wrapping with encoded attributes) - I have already noted (thanks to Tim Hudson) to change the tags in section 4.1 to become standard tags in KMIP as well. Previously they were in the « vendor defined » range which will cause problems. - However there is a more subtle crypto/security point which I’ve come across while addressing another of Tim’s points: The idea of this wrapping method is to offer a higher level of security than existing schemes where the template for the new key is supplied on unwrapping. This means protecting against attacks where an intruder with access to the PKCS#11 interface may make a second copy of the key with some of the attributes changed - SENSITIVE turned off for example - in order to get hold of the encrypted key value. The method relies on the new «  authenticated encryption » methods added to v2.40: GCM and CCM. Both of these are counter modes, which means that they work by calculating a key stream from the IV + a counter, and then XOR this against the plaintext to obtain the ciphertext. The problem is that if the attacker controls the IV, he can control the key stream. This means he can use the encrypt operation to decrypt, by giving the cipher text as the plaintext and reusing the same IV. In the context of PKCS11 wrap and unwrap, this mean he could decrypt a wrapped key if he can wrap a known key value. It may be possible to avoid the possibility of wrapping a known value by making heavy usage restrictions on the API, but if we introduce the new wrapping mechanism where attributes (known data for the most part) are included in the plaintext, this is no longer possible. Options include: make the IVs for this wrap mechanism token-generated (probably a good idea anyway for NIST compliance), add a mode with automatic deterministic nonce calculation like SIV (designed for key-wrap), use an AEAD mode so that attributes are treated as public data. Thoughts? Thanks,  Graham Steel +33 (0)9 72 42 35 31 https://discovery.cryptosense.com On 31 May 2016, at 23:45, Valerie Fenwick < valerie.fenwick@oracle.com > wrote: Hi folks- We want to really start moving forward on 3.0, and we have a few items that are approaching readiness for ballot. But, we really don't want to take things to ballot if they need changes before they can be approved :-) to that end, please take time before our next meeting to review and give feedback to the authors on. I have provided the public links as well, if you find that useful: * New function proposal draft 3(Bob R): WG link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=58225 PUblic Link: https://www.oasis-open.org/committees/document.php?document_id=58225 * Updated AEAD Proposal (Bob R.): WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=57976 Public Link: https://www.oasis-open.org/committees/document.php?document_id=57976 * AES GCM Changes form AEAD API (Bob R.): WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=57637 Public Link: https://www.oasis-open.org/committees/document.php?document_id=57637 * PKCS11 Wrapping with templates - v2 (Graham S): WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=58092 Public link: https://www.oasis-open.org/committees/document.php?document_id=58092 * Adding attributes to wrapped keys - (Graham S): WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=58091 Public Link: https://www.oasis-open.org/committees/document.php?document_id=58091 Please complete your review by Monday, June 6, to give the author time to incorporate your suggested changes and have a moment for you to we review that they got them right before our next meeting on June 8. Thank you so much! There is a lot here, but once we start knocking some of these things off, there will be less :-) If I missed one of the documents we're currently reviewing, please let me know. I know documents like the DSA one are awaiting further updates. I hope to have my proposal for constant identifier allocation out shortly. Valerie -- Note: I am using voice recognition software. Forgive any strange words. Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva Solaris Cryptographic & Key Management Technologies, Manager Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054. --------------------------------------------------------------------- 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: signature.asc Description: Message signed with OpenPGP using GPGMail

On 06/02/16 14:42, Graham Steel wrote: Options include: make the IVs for this wrap mechanism token-generated (probably a good idea anyway for NIST compliance), add a mode with automatic deterministic nonce calculation like SIV (designed for key-wrap), use an AEAD mode so that attributes are treated as public data. A token generated IV makes sense, since as you point out due to the NIST requirements for FIPS 140-2 that might be a requirement for many vendors anyway (if PKCS#11 is the FIPS 140 crypto boundary rather than some higher level part of the product). -- Darren J Moffat

AES GCM Changes for AEAD: The description of MessageEncrypt (line 33) doesn't mention C_MessageEncryptInit. Is that where the AAD gets passed in? Similar comment for MessageDecrypt. Just say the key type for K must be CKK_AES rather than saying indirectly that it must be compatible with CKM_AES_ECB. This is on lines 57-59. Mark On May 31, 2016, at 2:45 PM, Valerie Fenwick <valerie.fenwick@oracle.com> wrote: > Hi folks- > > We want to really start moving forward on 3.0, and we have a few items that are approaching readiness for ballot. But, we really don't want to take things to ballot if they need changes before they can be approved :-) to that end, please take time before our next meeting to review and give feedback to the authors on. > > I have provided the public links as well, if you find that useful: > > * New function proposal draft 3(Bob R): > WG link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=58225 > PUblic Link: https://www.oasis-open.org/committees/document.php?document_id=58225 > > * Updated AEAD Proposal (Bob R.): > WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=57976 > Public Link: https://www.oasis-open.org/committees/document.php?document_id=57976 > > * AES GCM Changes form AEAD API (Bob R.): > WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=57637 > Public Link: https://www.oasis-open.org/committees/document.php?document_id=57637 > > * PKCS11 Wrapping with templates - v2 (Graham S): > WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=58092 > Public link: https://www.oasis-open.org/committees/document.php?document_id=58092 > > > * Adding attributes to wrapped keys - (Graham S): > WG Link: https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?document_id=58091 > Public Link: https://www.oasis-open.org/committees/document.php?document_id=58091 > > > > Please complete your review by Monday, June 6, to give the author time to incorporate your suggested changes and have a moment for you to we review that they got them right before our next meeting on June 8. > > Thank you so much! There is a lot here, but once we start knocking some of these things off, there will be less :-) > > > If I missed one of the documents we're currently reviewing, please > let me know. I know documents like the DSA one are awaiting further updates. > > I hope to have my proposal for constant identifier allocation out shortly. > > Valerie > -- > Note: I am using voice recognition software. Forgive any strange words. > Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva > Solaris Cryptographic & Key Management Technologies, Manager > Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054. > > --------------------------------------------------------------------- > 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

All, here are my comments. Updated AEAD Proposal (not repeating what other people already commented) * Page 2, bottom, "For most mechanisms, C_EncryptMessage is equivalent to C_EncryptMessageBegin followed by a sequence of C_EncryptMessageNext operations. " : It would be useful to mention in which cases C_EncryptMessage is NOT equivalent to C_EncryptMessageBegin followed by a sequence of C_EncryptMessageNext operations, if any. Idem for decryption (page 7), signing (page 13) . * Page 6, line 8: continues o rfinishes -> continues or finishes * Page 6, line 14: dot at the end of the line. * Page 11, line 7: signs as ingle-part -> signs a single-part * Page 11, line 18: MessagedSignInit -> MessageSignInit * Page 13, lines 14 and 19: insert space in pParameterand, ulParameterLenspecify and pParametermay * Page 17, line 13: for for -> for * Page 19, line 18: .. -> . * Page 20, lines 4-8: insert space between parameter type and name * Page 20, line 15: pSignatureargument -> pSignature argument * Page 21, table 8: CKF_MULTI_MESSGE -> CKF_MULTI_MESSAGE. * Page 22: C_SignRecover is possibly a left-over from the original table 30? * Throughout the whole document : Consistently use Courier font for parameter names inside the text. AES GCM Changes: * I have added my feedback using track changes (only up to and including page 11) * Page 3 and 5: The meaning of the following section is not clear to me: " The key type for K must be compatible with CKM_AES_ECB and the C_EncryptInit/C_DecryptInit calls shall behave, with respect to K, as if they were called directly with CKM_AES_ECB, K and NULL parameters. " Thanks, Dieter On May 31, 2016, at 2:45 PM, Valerie Fenwick <valerie.fenwick@oracle.com> wrote: > Hi folks- > > We want to really start moving forward on 3.0, and we have a few items that are approaching readiness for ballot. But, we really don't want to take things to ballot if they need changes before they can be approved :-) to that end, please take time before our next meeting to review and give feedback to the authors on. > > I have provided the public links as well, if you find that useful: > > * New function proposal draft 3(Bob R): > WG link: > https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?docu > ment_id=58225 PUblic Link: > https://www.oasis-open.org/committees/document.php?document_id=58225 > > * Updated AEAD Proposal (Bob R.): > WG Link: > https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?docu > ment_id=57976 Public Link: > https://www.oasis-open.org/committees/document.php?document_id=57976 > > * AES GCM Changes form AEAD API (Bob R.): > WG Link: > https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?docu > ment_id=57637 Public Link: > https://www.oasis-open.org/committees/document.php?document_id=57637 > > * PKCS11 Wrapping with templates - v2 (Graham S): > WG Link: > https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?docu > ment_id=58092 Public link: > https://www.oasis-open.org/committees/document.php?document_id=58092 > > > * Adding attributes to wrapped keys - (Graham S): > WG Link: > https://www.oasis-open.org/apps/org/workgroup/pkcs11/document.php?docu > ment_id=58091 Public Link: > https://www.oasis-open.org/committees/document.php?document_id=58091 > > > > Please complete your review by Monday, June 6, to give the author time to incorporate your suggested changes and have a moment for you to we review that they got them right before our next meeting on June 8. > > Thank you so much! There is a lot here, but once we start knocking > some of these things off, there will be less :-) > > > If I missed one of the documents we're currently reviewing, please let > me know. I know documents like the DSA one are awaiting further updates. > > I hope to have my proposal for constant identifier allocation out shortly. > > Valerie > -- > Note: I am using voice recognition software. Forgive any strange words. > Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva Solaris > Cryptographic & Key Management Technologies, Manager Oracle > Corporation: 4180 Network Circle, Santa Clara, CA, 95054. > > --------------------------------------------------------------------- > 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 --------------------------------------------------------------------- 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 ________________________________ Utimaco IS GmbH Seat: Aachen – Registergericht Aachen HRB 18922 VAT ID No.: DE 815 496 496 Managementboard: Malte Pollmann (Chairman) CEO, Dr. Frank J. Nellissen CFO Wichtiger Hinweis: Diese E-Mail kann Betriebs- und Geschäftsgeheimnisse oder sonstige vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die E-Mail. Der Absender hat alle erdenklichen Vorsichtsmaßnahmen getroffen, dass die Anlagen dieser E-Mail frei von Computerviren o. Ä. sind. Gleichwohl schließen wir die Haftung für jeden Schaden aus, der durch Computerviren o. Ä. verursacht wurde, soweit wir nicht vorsätzlich oder grob fahrlässig gehandelt haben. Wir raten Ihnen, dass Sie in jedem Fall Ihre eigene Virenprüfung vornehmen, bevor Sie die Anlagen öffnen. Vielen Dank. Important Notice: The information contained in this email message may be confidential information. 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. We have taken every reasonable precaution to ensure that any attachment to this email has been swept for viruses. However, we cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment. Thank you for your cooperation. Attachment: aes_gcm_proposal_DBO.doc Description: aes_gcm_proposal_DBO.doc

On 06/06/2016 07:35 AM, Dieter Bong wrote: All, here are my comments. Updated AEAD Proposal (not repeating what other people already commented) * Page 2, bottom, "For most mechanisms, C_EncryptMessage is equivalent to C_EncryptMessageBegin followed by a sequence of C_EncryptMessageNext operations. " : It would be useful to mention in which cases C_EncryptMessage is NOT equivalent to C_EncryptMessageBegin followed by a sequence of C_EncryptMessageNext operations, if any. Idem for decryption (page 7), signing (page 13) . There currently isn't any case. The text says 'for most mechanism'. There are currently only two mechanisms defined for these functions AES-GCM and AES-CCM. The words are there to allow flexibility in case it may make sense for future mechanisms. These should be fixed in the current document * Page 6, line 8: continues o rfinishes -> continues or finishes * Page 6, line 14: dot at the end of the line. * Page 11, line 7: signs as ingle-part -> signs a single-part * Page 11, line 18: MessagedSignInit -> MessageSignInit * Page 13, lines 14 and 19: insert space in pParameterand, ulParameterLenspecify and pParametermay * Page 17, line 13: for for -> for * Page 19, line 18: .. -> . * Page 20, lines 4-8: insert space between parameter type and name * Page 20, line 15: pSignatureargument -> pSignature argument * Page 21, table 8: CKF_MULTI_MESSGE -> CKF_MULTI_MESSAGE. * Page 22: C_SignRecover is possibly a left-over from the original table 30? * Throughout the whole document : Consistently use Courier font for parameter names inside the text. I've left this for the editor as he may have preferred ways of marking these elements in the document. AES GCM Changes: * I have added my feedback using track changes (only up to and including page 11) I'm not sure where those are? * Page 3 and 5: The meaning of the following section is not clear to me: " The key type for K must be compatible with CKM_AES_ECB and the C_EncryptInit/C_DecryptInit calls shall behave, with respect to K, as if they were called directly with CKM_AES_ECB, K and NULL parameters. " This text was from the existing document. I've updated it to say key_type is CKK_AES, but I've kept the 'behavioral' comment with the not that this only applies to Encrypt/Decrypt, not the Message functions. Thanks, Dieter On May 31, 2016, at 2:45 PM, Valerie Fenwick <valerie.fenwick@oracle.com> wrote: Attachment: smime.p7s Description: S/MIME Cryptographic Signature