-
Notifications
You must be signed in to change notification settings - Fork 18
Meetingminutes Minutes25022016
Bob Relyea edited this page Mar 5, 2025
·
2 revisions
- Roll call (Valerie)
- Non TC member guests: Burt Kaliski (Verisign), John Leser (Oracle)
- Introductions
- Burt Kaliski, PKCS 25th Anniversary
- Update on PKCS#11 2.40 Errata, next steps
- KMIP Liasison update
- PKCS#11 2.41
- New algorithms:
- Letter to CMVP/NIST
- Graham S.: Associating Attributes to Wrapped Keys
- Bob R.: AEAD (Wan-Teh's 3.0 work)
- Interop update - Tony
- Motion to participate in 2017 Interop at RSA Feb 2017.
- PKCS#11 3.00 topics
- Application/library context
- Set next meeting date , adjourn
- Tim H moves. Mark J seconds. No objections. No abstentions. Agenda approved.
- Introductions made
- 2016 is the 25th anniversary of the PKCS suite
- PKCS11 was added in 1994 and had the most enduring activities
- If anyone has any stories, please send them to Burt to be added to the history and sent out via twitter (@modulomathy)
- Comments received on volume of IP data in the header files
- We did follow OASIS admin's advice - as the suggestion from the comment list has been rejected by OASIS admin in the past
- Agreed to proceed down current path unless OASIS Admin request otherwise
- Otherwise the feedback was good
- Co-Chairs to draft a response and work with Tim H to complete. TC to review
- Valerie to reach out to commenter and ask for which comments are still relevant with explanation that we started from v2.30 (done)
- We need to review references to wiki (non-normative source) in normative text - OASIS are happy with this so we'll need to review that going forward.
- KMIP TC has agreed to include mapping for everything that PKCS11 would want to do within KMIP
- KMIP TC will map in cka_extractable & cka_never_unextractable, cka_sensitive for inclusion KMIP v 1.4
- considered some of the wrapping mechanisms but have deferred for later
- KMIP>PKCS11>KMIP (and derivations thereof) implementations are already in the field
- Templated off RC4
- Chris asked if the Parameters make sense to folks.
- Google is the only entity really pushing it
- Bob R to investigate with some of his contacts
- OpenSSL has implemented CHaCha in v1.1
- Likely that ChaCha and Poly will be kept separate
- Valerie asked anyone bringing forward proposals to also bring forward proposed header file changes at the same time.
- Needs updating to remove "blowfish" reference
- Discussion held Chris to update
- We should be using specific CKK types for each algorithm rather than CKK_GENERIC_SECRET and parts of the specification still have the older approach which BobR is looking into
- Bob R described the work he did on SHA3
- Bob R needs to add the CKD values to go into the header file
- From Tim H.
- The SHA2 versions of two of the sets of identifiers you didn't see iN the specification are in the header files.
- From Tim H.
#define CKK_SHA256_HMAC 0x0000002BUL #define CKK_SHA384_HMAC 0x0000002CUL #define CKK_SHA512_HMAC 0x0000002DUL #define CKK_SHA224_HMAC 0x0000002EUL #define CKD_SHA224_KDF 0x00000005UL #define CKD_SHA256_KDF 0x00000006UL #define CKD_SHA384_KDF 0x00000007UL #define CKD_SHA512_KDF 0x00000008UL
- We are indeed missing the CKM KEY_GEN versions - tied into the change from CKK_GENERIC_SECRET to specific key types.
- PBKDF2: in spec, but not in header file? Need to look into this.
- Document is missing sections in 2.40 that should have been left in as per 2.20.
- Appears that these sections were still there in 2.30.
- Dina to make a proposal containing the diffs of the things that were left out.
- NIST wants to move the IV inside the boundary which won't work for most folks.
- Darren M suggested overloading the parameter structures
- Can we abuse the parameter field?
- No way to do this consistently across sessions, many TLS implementations do this in an unexpected manner.
- No connection between sets of C_Encrypts that are really for the same connection
- No way to do this consistently across sessions, many TLS implementations do this in an unexpected manner.
- Can we abuse the parameter field?
- Christian introduced requirement - no proposal provided yet
- Christian to bring forward a proposal
- Original questions posed is about differentiating two identical keys
- Discussed a mandatory UUID for each key instance as per KMIP would be a better way to solve this.
- proposal will be dropped in favor of CKA_UUID, unless we are unable to address CKA_UUID in a timely manner
- Request to add these new operations which stops operation and cleans context. Now we have to simulate it with some kind of failure.
- Tim asked why not use CancelFunction?
- That old function did not quite meet the need. Proposal should be brought forward for cancel functions for most things that have an Init* variation (like C_FindObject). ORacle will bring this forward.
- Need to extend beyond simply "quality" - FIPS? Hardware? etc?
- Suggestion the V3.0 should include one or more new mechanism parameter(s)
- Push to new v3.0 and bring forward at that time
- Discussion about representing more of the full lifecycle support for tokens
- Needs further investigation to look at the implications of changing token and slot info
- Oracle to work on a proposal
- General consensus that CKA-UUID is required
- This will help with interoperability with KMIP
- Oracle to bring forward a proposal
- Bob drafted a letter to CMVP NIST expressing concern about providing specific requirements regarding IV generation & requesting assistance to define a way of working with the existing standards body (like OASIS) to ensure undesirable outcomes are avoided.
- Oracle (Valerie) to review/proof read the document
- Graham walked through the presentation on Associating Attributes to Wrapped Key as a summary of the document uploaded to Kavi on 6th Jan 2016
- Agreed that perhaps the TC should just take a first step to cover ~80% of Graham's issue by defining a location that the token vendor can use for their own relevant vendor attributes.
- Bob uploaded 3 documents
- Discussion was that we should be using specific CKK types for each algorithm rather than CKK_GENERIC_SECRET and that parts of the specification still have the older approach which BobR is looking into.
- BobR - Add missing 0 to second row in Table 8 update
- BobR - Expand to include the description of why there is only one flag for MULTI_MESSAGE rather than one for each.
- BobR - Copied existing AES GCM mechanism and updated to match the Message Based Encryption Functions
- CK_GCM_PARAMS changes the pAAD - so GCM_AEAD_PARAMS just has that adjustment
- BobR - note CK_GCM_PARAMS -> CK_GKM_AEAD_PARAMS and on the CCM_PARAMS structure label and typedef as well
- Those minor changes were all that was required in order to make this work.
- BobR walked through the proposal for extending the function table
- Discussed making this a 3.0 item, but that now that we have a "forcing function" we need to consider this sooner than later.
- possibly change name to C_GetFunctionLists (the S on the end being important)
- Add something like a colon between vendor information for vendor defined mechs.
- Many of today's proposals for 2.41 include adding new functions. We have not added a single new function since PKCS#11 1.x to 2.01 transition.
- Historically, we've always said if we needed new functions we should rev the major version number.
- Even though Bob's function table allows for an application to use the old API completely, so it will remain backwards compatibility, the change is significant enough we really should not call it 2.41.
- Historically, we've always said if we needed new functions we should rev the major version number.
- Originally, we went with 2.41 to only introduce a few new mechanisms. Seems like we need bigger changes
- Should go ahead quickly, still, with new mechanisms as committee notes
- Need 3 vendors to commit to making a SoU to go to v3.0
- 3 vendors located - Cryptsoft, P6R & RedHat
- Current major v3.0 items will mostly move to v4.0
- that is, the major overhaul we've been thinking of as 3.0 will bump. the smaller things that required new functions could still be considered for the new 3.0
- Valerie will send a note to the reflector, and we will make a decision in our next meeting, if possible. (or possibly issue a ballot)
- Interop is ongoing due to difficulties with getting common platforms etc. The participants made a motion to recommend that sufficient interoperability has been demonstrated that the TC should permit the demonstration to go ahead at the RSA 2016 Conference.
- Tony C makes a motion for the TC to continue with the the PKCS11 Interop demonstration at the RSA 2016 Conference. Mark J Seconds, No objections, abstentions or comments.
- Tim H makes a motion for the TC to participate in the OASIS Interop PKCS11 Interop demonstration at the RSA 2017 Conference. Mark J Seconds, No objections, abstentions or comments.
- C_Inititlize returns context and C_Finalize cleans only the sessions, objects and other related to the context or all library if context is not passed. Now we cannot calls C_Finalize in shared libraries (may just be an OS issue).
- Oracle to come back to say why ref count is not sufficient (Valerie and Hai-may could not remember the background off the top of their heads)
- Remove fork behaviour from standard, perfectly acceptable to work in the child.
- General agreement to use a "fork_safe" flag
- will need someone to bring forward a proposal.
- to also take a user name and call back mechanism
- There are many issues with C_login - we need someone to own this and look at all the uses of login so it can be handled
- Need also to look at what can be done without logging in vs what can - handled by a flag currently but perhaps an warning flag is warranted for when a token is asked to perform a function and a user is not logged in. Maybe a useful point for a callback
- PKCS11 device vendors should be polled or asked to submit to the TC the requirements they have had where PKCS11 did not meet the needs and were an alternate solution has had to be used to extend pkcs11.
- Hai-May will bring forward the more simple proposal for a new C_LoginUser function.
- Still need owner to look into all user issues. Christian will talk to Dieter at Utimaco.
- Committee belief is it will be best to hear from vendors who have had to hack around the missing functionality.
- Map KMIP attributes to PKCS#11 object lifecycle attributes and enforcement. This includes new (different) error codes for attempts to use objects before/after it's valid to use them for the desired purpose. (example: should C_Encrypt() fail if the key passed is beyond its Protect Stop Date?)
- Consider representing key state a new via cka_state
- maybe new functions, or possibly leverage C_SetAttribute?
- Who can change? and also CKA_DESTROYABLE needs more clarification in current spec.
- Perhaps a face to face meeting in conjunction with the ICMC (18-20 May 2016) would be a good idea.
- Valerie to set a straw poll
- 16th March 2016
- Nothing
- Open action item. Tony to file to Jira.
- See Jira - https://issues.oasis-open.org/browse/PKCS/?selectedTab=com.atlassian.jira.jira-projects-plugin:issues-panel
- We will review action items in the face to face meeting. A lot of those are older items for the co-chairs
- Bob R needs to add the CKD values to go into the header file, and generate key mechanisms (25-Feb-2016)
- Dina to make a proposal containing the diffs of the things that were left out of TLS 1.x in v2.40. (25-Feb-2016)
- Tim to share the approach taken to random quality & other fetures of random in the v3.0 timeframe (25-Feb-2016)
- Valerie to look into Adding C_RenameToken, etc to check the implications of changing token and slot info (25-Feb-2016)
- Oracle to bring forward a proposal on the addition of CKA-UUID (25-Feb-2016)
- Oracle (Valerie) to review/proof read letter to the NIST CMVP drafted by Bob regarding mandating changes inside the standardisation space. (25-Feb-2016)
- Graham S to refine proposal on vendor extension attributes. (25-Feb-2016)
- Valerie to poll the list for participation in v3.0 - we need 3 vendors wiling to make an SoU (25-Feb-2016)
- Oracle (Hai-May) to look at login user and bring forward a proposal (25-Feb-2016)
- Utimaco (Dieter) to look into authentication and bring forward a proposal (25-Feb-2016)
- Valerie to raise a straw poll on attendance at the ICMC in May
- Late arrivals - None
- Tim moves. Hai-May seconds. No objections. No abstentions. Meeting adjourned.