-
Notifications
You must be signed in to change notification settings - Fork 14
MeetingMinutes Minutes08102014
Robert Relyea edited this page Mar 5, 2025
·
2 revisions
- Bob performed roll call, we have quorum. This will be an official meeting.
- Opening remarks (co-chairs)
- Roll call
- Review / approval of the agenda
- Review of previous meeting minutes
- Old Business
- Status of V2.40
- Statements of Use
- Review materials for submission with request for ballot on OASIS candidate standards
- Voice vote to request ballot on OASIS candidate standards
- Header files
- Request for implementation info
- V2.x topics
- Corrections to constants etc
- Additional profiles (Sven)
- v3.0 topics
- Wan-Teh / Bob R
- Sven
- Status of V2.40
- New Business
- Review Action Items
- Adjourn
- Tim moved, Sven seconded. No objections or abstentions or discussions.
- September 24, 2014
- Tim moved, Chris seconded. No objections or abstentions or discussions.
- Bob G: Documents sent for approval - note from Chet that given the errors, we need to amend and resubmit the committee spec.
- Bob G: Chet indicated that another public review would not be required, we do however need to resubmit the committee spec v2.0 with amended statements of use to match. We do need a full majority vote to commence that process.
- Bob G: Resolution to just amend documents to meet editorial issues raised by OASIS and get out for review ASAP.
- Bob G: Working with Chet to determine whether the header files are normative or illustrative. My opinion is that the normative reference remains in the spec and the header files are illustrative only
- Stef: Asked how tightly bound the "illustrative" header files are bound to the specification as it seems kind of risky
- Bob G: We need to focus on any differences in the definitions - we could look at removing them completely or publish the definitions and include a caveat that there is a difference but I'm still waiting for Chet
- Tim: On the last meeting, we decided that the header files should reflect the spec and they cannot be OASIS documents (illustrative or otherwise), therefore the spec needs to be clear match what's in the spec.
- Tim: The pages are up, folks should update as they see fit.
- Tony: link to PKCS11 known implementations is: https://wiki.oasis-open.org/pkcs11/KnownPKCS11Implementations
- Tony: link to KMIP known implementations is: https://wiki.oasis-open.org/kmip/KnownKMIPImplementations
- Tim: background and status on the interop for RSA Conference 2015
- BobG: requested nomination, MarkJ: Nominated Tony C, JimS: Seconded. No objections.
- Bob G: Regarding a near term release that would include the updated constants etc, Sven?
- Sven: Similar to what I have uploaded before but I would like to address the features I've outlined before.
- Multiple PINs - need additional PINs as a request from the market to enable levels of access for different elements of the card.
- PIN Policy: an example is PIN length - need to define a min & Max length of PIN
- Post issuance PIN changes - need to look at an option for post issuance modification of PIN values and length.
- Additional Certificate features: Need additional certificate features to further enable post-issuance use and modification.
- Error handling - a finer grained set of error codes
- Card activities - look at standardizing the various actions involved in smartcard production, issuance and use.
- Profile - UEFI profile is required. Tim asked if we should document a subset of PKCS11 in a UEFI specific profile? Sven: Yes.
- Cross platform information: Provide a method to know which functions would work on which platform.
- Sven: OASIS PKCS11 committee could also look at joining the UEFI committee
- BobG: Asked about how this would be done
- Sven: There is Membership - we would work them to offer a library to use and it looks like a profile would work
- Sven: The suggestion is to provide a wrapper for the card edge interface such that more applications to directly interact at the card edge.
- BobG: It sounds like we can get a profile done fairly quickly if we can reduce the scope to perhaps the last four items as the first three items, appear larger tasks. Svwn, are you able to prioritize the items for a 2.41 release?
- Sven: The PINs are integral to the other features - This doesn't need to be done quickly for 2.41 - it would be better to take longer and roll all the functionality up into one profile.
- BobG: OK, I think we do need to work on the error messages and if there is a great deal of value in the UEFI profile then perhaps you and Tim should work on that. My comment would be to work on that and bring forward the minimum set of features.
- Sven: if we want it for 2.41 then we can do that but the other items are more important and I'd rather take the time to work on those
- Bob G: We also need to consider what value these items have for others in the group. So we do need to gather support in the committee to drive these forward.
- Tim: I'm happy to work with Sven on the profile but I do believe that there is a set for 2.41 and one for post v2.41
- Bob G: Thanks for bringing this forward
- Sven: Just a note that I've already shortened the list from what I had before and if we take too much off - we'll end up with a much longer list of items to deal with for post 2.41
- Bob R: I've spoken to Wan-Teh and there is still some work to be done on the spec. The immediate task is to add the mechanisms for GSM. The proposal he has up is complete for the messaging API only so we can move that to ballot knowing that we still have to adfd the machanisms for GSM to actually use it.
- Bob R: The other thing he said was we need to decide on the semantics for get operation state but those semantics are independent of the API so I think we can move forward on the API as documented or we can wait two weeks to take it forward with the GSM mechanisms.
- Bob G: I'd propose we wait for the GSM mechanisms and take it forward from there. I look forward to balloting that on the next call.
- Bob G: On the call two weeks ago we had possible dates in November and also at RSA, there is also a date in February.
- Valerie: I believe Sven indicated the February event
- Sven: GSMA Barcelona in February 2015
- BobG: Asked for any suggestions for a face to face date & location to put into a straw poll to me by the end of the week for inclusion. I'll also include the Crypto workshop at NIST at the beginning of April.
- Bob G: Looking at errata, implementation page, Sven's list, and discussion about face-to-face and Graham's proposal about secure key import in our next meeting.
- Any additional topics? hearing none.
- Valerie: create 3.0 suggestion document, move 2.40 suggestions over into new 3.0 suggestion document. (not started, yet) (09042014.01)
- Bob: will make a first pass by going through meeting minutes. I will send to Valerie, who can clean it up and post to the wiki.(09042014.02) (Complete Aug 3, 2014)
- Valerie (et al): add new suggestions to the 3.0 wiki, so we can track if they have owners and are moving forward. (09042014.03)
- Bob G: how about I take time to write up a couple of paragraphs on how to get out a new mechanism to take to the team by the next meeting? (04062014.01)
- Tim H: send suggestions on how to handle minor updates prior to v3.0 to the list (16072014.01)
- Valerie: Check with her team to see if anyone will be picking up Darren's proposal from a few weeks back (10092014.01)
- Bob G: Check with Chet to see if we have to do anything special for the header files (10092014.02)
- Valerie: Follow up on timeline for new AES-XTS proposal (10092014.03)
- Bob G: Start with Stef's document and make an amendment doc. Stef's broken definitions write-up (24092014.01)
- Bob G: I believe we can do errata's against committee spec, so we won't have to wait 90 days, but I will check with Chet (24092014.02)
- Tim moved, Bob L seconded. No objections or abstentions or discussions. Adjourned 1:53PM US-PDT.