PKCS#11 F2F Minutes – February 8, 2017


Roll call

Roll called (Valerie) and introductions from members present.Quorum achieved

Review/approve agenda,

Motion to approve Agenda - Tim H Moves, Jeff B seconds, no comments, objections or abstentions. Agenda approved.

Review/approve minutes from Jan 25, 2017

Motion to approve Minutes January 25, 2017 - Tim H Moves, Jeff B seconds, no comments, objections or abstentions. Minutes approved.

Discuss leadership roles

-Valerie is leaving Oracle after RSA (Hai May will remain as designated contact)-Valerie stated that she will be stepping down as co-chair with immediate effect.-Valerie called for nomination for Co-Chair and nominated Tony Cox and called for other nominations – none made. Motion to appoint Tony Cox as co-chair - Valerie Moves, Bob R seconds, no comments, objections or abstentions. Appointment approved.Motion to recognise and thank Valerie for her contributions to the TC with a statement visible on the TC page- Tim H Moves, Jeff B seconds, no comments, objections or abstentions. Motion approved.Motion to appoint Valerie as secretary – Tim Moves, Hai May seconds, no comments, objections or abstentions. Appointment approved.

Set deadlines for new proposals, final ballots, target draft of 3.0

-Agreed target would be to go into final OASIS spec review in December 2017-Agreed content should be locked down by July· Meet weekly in May· Mini-face-to-face possibly around ICMC (mid may)· 1 May: Last new proposal concepts· 15 May: last new review ready/spec diff proposals· 15 June: Last motions approved or rejected· July: Committee Draft· Sept: face-to-face if needed· November: give draft to OasisMotion to state a deadline by May 1st, 2017 – Tim Moves, Jeff B, no comments, objections or abstentions. Motion approved.

PKCS11 RSA Demonstration, final update

-Tony provided an update on the RSA2017 interop.

Discuss Jaroslav's comments against PKCS#11 2.40 - next steps?

- Jaroslav provided comments on 2.40 and the TC elected to leave addressing the issues until v3.0 (given the low impact and severity).-The 21 items do need to rolled into the next WD of the specification-Agreed to review the items and hand them out to TC members to action.-Tim displayed the items:

Darren J: Additional ECC curves for v3.0

Current documents don’t fit Edwards and Montgomery curve. Created new key types and mechs. Edwards/Montgomery not recommended for use with ECDSA, so should separate from existing curves.Bob to share w/Darren NSS’s implementation to see if that might demonstrate how to handle this with existing spec, or if modifications are still needed. In NSS 3.2.8, Bob believes.Valerie asks if we do bring this forward, to include the NIST or other standard reference names for new curves, as comments.

Darren J: EncryptCancel/DigestCancel/etc

Tim: Why not call final with all NULL parameters? Or C_CancelFunction (now deprecated).Bob: C_CancelFunction was to cancel something we don’t do anymore. (callback functions, to work with systems that didn’t do native threading)Some vendors working around this by sending garbage to one of the other functions to get it to give up.Tim: could this be a usage guide?Maybe: C_SessionCancel, where we specify the session and what to clear (everything?), will take operation flags from mechanism issue, and flags.If you try to cancel a combo operation, you are essentially finalizing that one half = behaviour may be unexpected by the token.

Profile Assertions, Anthony Berglas

Could we have a formal testing language, to help eliminate inconsistency. For example, set up profiles.. Formalizing our profiles with some test cases. Should be obvious, even if you don’t know the language of the profile test.Mark J. volunteering to work with Anthony on coming up with some examples, as they already have some of this defined. XML based data driven testing. David G. will work together on this.This can help with formalizing interoperability demonstration. Once defined, Tim H. will help hook this into profiles.

Bob R.: AEAD/AES GCM proposal/Extending Function Table/Forking - finish up proposal

Single part messages are covered with functions like C_EncryptMessage. Tim was asking about how we handle tags, that’s all mechanism specific. The tag is sent with the data, going to move the tag into the param block. The param block will also be moved into the next interface as well. pParameter and ulParemeterLen added to the one function that didn’t have them (C_EncryptMessageNext).Tim to shop proposal to a FIPS lab or consultancy to see if our AES-GCM IV generation cuts the mustard.

Bob R.: Function table:

Vendors have extended the tables themselves, so we can’t really write over that space. We haven’t added a new function in 10+ years, so we want to introduce a new parallel function table that presents a new Function List. (C_GetInterfaces). Can get to old interface (2.40errata1) via the old calls (C_GetFunctionList) or call C_GetInterfaces to access the old 2.40errata1 or 2.20 style API).Bob will update the examples in the function extension table to no longer refer to PKCS11 2.41 and 2.42, since we renamed our version.

Dieter: CKM_AES_KEY_WRAP_PAD: Clarify language and remove reference to RFC discussion.

The text is unclear here – should we clarify? Bob: this is often up to the application to keep track of what it is wrapping, unwrappingThis section references the NIST draft. If it’s no longer draft, it should be updated.It seems that what we are specifying now is confusing. Should be able to implement a NIST compliant version. We could allow something weaker, but should encourage the better. AI: look up what NIST actually specifies and see if we can implement a compliant version. Possibly need to deprecate this mechanism and create a new one.You should be allowed to return the error.AI: Dieter: New mechanism required for AES KEY WRAP following 6.3 KWP in NIST SPEC (Section 6.3 KWP) and Deprecate existing AES_KEY_WRAP_PADThe “usual” padding is confusing in 2.14.3, needs to be more specific. SS 2.1.21 and 2.3.12 should be more specific as to what it means in reference to the RFC. Dieter will own this.Editors: Be aware of using “the usual” J

Tim H.: KMIP Mappings

Vendors have all solved this their same way. For the things that are standard, make sure we have a way of wrapping and unwrapping in a way that makes sense. Can the user override it, or should it be set? Whatever our existing rules for changing an item should still apply. Should CKA_TOKEN and CKA_PRIVATE be treated the same?Table in slides is a way of mapping tag values with PKCS#11 objects. Mapping directly is not straight forward. What about enums in PKCS#11?This all gets harder with vendor extensions; it’s hard to know what the types of those are. Then we’d need to have the typing information in the interface. C_GetAttributeValue/SetAttributeValue has no typing information. Should we fix this in 3.0? Many think yes, but nobody to sign up. AI: add to agenda looking for owner.We would need to define in KMIP: CKA_ as one enumeration, CK_OBJECT_CLASS, CK_KEY_TYPE, CK_MECHANISM_TYPE.... not dealing with mechanism parameters.Need to confirm if the simple mappings are sufficient.Could we define a PK11 object in KMIP? Some things map easily, others not. Need to do work in both standards bodies to resolve. Tony wonders should we do something more formal to have a joint TC meeting?AI: Tim to report back after discussing with KMIP TC.How do we protect ourselves against security attacks?AI: Graham, write about CK_UNIQUE_IDENTIFIER and how this applies.Could items be always sensitive? Why are some attributes always false?

Graham S: Associating Attributes to Wrapped Keys

Cryptosense doesn’t make a product, but does security analysis. This is a problem that banks want to fix. Problem is there no standard way to ensure attributes of unwrapped key at destination are the same as they were at the source.Most keys are decrypted at startup, so meet the deployment checkbox, but not actually secure.Part 1 is done: allowing GCM and CCM modes to be used for C_WrapKey (2.40E1), but now we need an encoding for attributes. Part 3 is to finalize with attribute IDs, etc.New mechanisms: CKM_AES_GCM_WRAP & CKM_AES_CCM_WRAP, we require that the IV is token-generated, otherwise attacks are possible (reuse the IV and generate the same keystream). Bob R. wonders: should this be a random number? AI: Graham will add this for these two modes, length fix, and consider the SIV mode for determining the IV.Since this is a new mechanism, perhaps we should make it the best we can.

Dina K: DSA text improvements

Editor note: probabilistic is misspelled throughout document as PROBABILITICBob does not want to add a new mechanism/keytype. Folks are already using the new type. You can tell if you’re doing FIPS by the keysize (you can set keysize to 1024 and not accept older).Dina/Val: If you sign on an older version, you should be able to verify on newer. This is, we believe, allowed by FIPS/NIST.Bob: at the upper level, there aren’t different OIDs for DSA2, it just worked.Anthony: how do you verify? Bob: can just allow all key lengths for verify, restrict for signature. Perhaps we should fix the typos and remove FIPS wording from the document and move to usage guide.Action for Editor: Fix the typos, make changes to usage guide.AI for co-chairs: Allocate another ID with same number but spelled correctly CKM_DSA_PROXXX (spelled differently, but still wrong)

Dina K. : TLS text improvements

Base spec

AI: End sentence on “A Cryptoki interface” in Base Spec, Tim to upload with the strike through. Motion is to approve Dina’s updates to the base specification with Tim’s strike through in the next version of the specification.Tim moves, Gerry seconds, no objections , abstentions or comments. Motion passed

Current Mechanism

Section 2.7: strike the long list of mechs. Tim to upload document.Section 2.28: do we need this long list of mechanisms? They will get out of date. Removing the list as well.bIsExport: Changes to clarify look good.2.29 should all be ‘red’ as it’s all being restored, but the text in red is where we need to edit the original text.New 2.30 (was 2.29 in 2.40Erratta 1) Lots of stuff moved around, folks should take a look. There is a “black box” warning “Note well” in the current specificationDina did rename some mechanisms, can reuse the same number. Bob R. will add it to the database so it gets added to the header file.Everyone: review over next 2-4 weeks to take it to a ballot.


Useful to have a pass through mech that doesn’t do anything, but exercise innards of API.Bob R./Dina: Would be better in miscellaneous mechanism document.Tim: why does it take a parameter? Bob R. Just the meaningful parameter that is expected.Even though it was created due to TLS, would be best in miscellaneous section. Tim H. Would like to see parameters removed.AI for Dina: add what CKM_NULL for each of the functions.

Still interested? C_LoginUser ·

Bob: Interested, but doesn’t seem to be feasible for 3.0, as it’s very complicated?Tim: Simple proposal, have a parameter that specifies username – just one extra parameter, otherwise the same as the previous. Anthony: could you had pLoginInfo?Tim H. Will pick this up!

C_GenerateRandom - Christian/Dieter

Dieter hopes to get a colleague to help, but for now it is on back burner.

C_RenameToken, ChangeLabel and/or ClearToken – Oracle

Deferred for 3.1 – probably start working on it sooner than later.

Open: Additional content to consider for 3.0?

AI Bob: Would like to add IPsec derive mechanism for the keys. Right now IPsec implementations using the primitives. He will own the proposal and move forward. Should be simple.AI Bob: Provisioning issue slides for a disk. Need the primitives for the new functions he’s proposing. We don’t have the multiply or EC point addition operation. Bob will send out the link to the slides, and will work on proposals for the necessary primitivism.Darren: SP-800-108 for KDFs. Allows for variable inputs to account for various KDFs. Would like a mechanism that allows variable input to work with this. Function fixed derivation parameters. Only a subset of the parameters would be NIST approved. You could use a subset in an SP-800-108 compliant method, Sp-800-108 is now standard. This proposal has additional items outside of SP-800-108, that may be useful. Bob R. May be useful, worth pursuing.David: anyone looking at bitcoin, blockchain, bit32. etc ? nobody, yet, so Tim H. recommended an email. “hyperledger” has a PKCS#11 hook. Graham mentioned they are starting to look into this.

Next meeting date

Tim moves to make next meeting March 1, 2017, Gerry seconds. No objections, abstentions, or comments. Motion approved.

Late attendees & adjourn

Tim moves to thank Valerie to host, Jeff seconds. No objections, abstentions, or comments. Motion approved.Tim moves, Jeff seconds. No objections, abstentions, or comments. Motion approved. Adjourned 5:18PM PT.

Meetingminutes/Minutes08022017 (last edited 2017-03-13 22:09:41 by Tony.Cox)