Minutes for PKCS 11 TC weekly concall 22-January-2014 - Approved 28 February 2014
1 Opening remarks (co-chairs)
2 Roll call (Bob)
- We have quorum
3 Review / approval of the agenda
1 Opening remarks (co-chairs) 2 Roll call (secretary) 3 Review / approval of the agenda 3 Review of previous meeting minutes (8-Jan-2014) 4 Old Business - Plans for F2F - AEAD discussion - V2.40 comments - Topics for next call
5 New Business 6 Review Action Items 7 Adjourn
- Tim H. moves to accept the agenda, Chris Z seconds. Hearing no objections or abstentions, motion passes and agenda is approved.
3 Review of previous meeting minutes (8-Jan-2014)
- David has posted the minutes from October, but Bob has not had a chance to review so will defer their approval. Tim moves to accept minutes from 8-Jan-2014, Chris Z seconds.
- Hearing no objections or abstentions, minutes for 8-Jan-2014 are approved.
4 Old Business
- Plans for F2F
- Food will be catered. Chris will do a poll just to see if there are any dietary restrictions. Bob included 4 topics on the agenda: 1) look at anything outstanding in the 2.4 documents. 2) talk about for 3.0, like function tables, WAEP, forking. let's get an idea of which ones we'll talk about at the Face-to-face at our next meeting. Hopefully we can have some fleshed out proposals. 3) see how things went at the demo/interop. anything else we want to change? 4) significant changes to or alternatives to the current PK11 interface. Hope we'll be finished by 5 pm at the latest so people can catch flights. Comments or suggestions on the agenda? none voiced. Bob asked Valerie for feedback, she said all items she wants to discuss should fit in those buckets.
- Going to be sharing the booth with 5 PKCS11 vendors and 8 vendors doing KMIP. Probably largest OASIS demo at RSA ever. Working through the logistics. We should be able to have a presentation at the F2F. others not participating can register in the next couple of weeks with the OASIS RSA code. Valerie: how do people participating get registered? Tim: Jane will register you and your nominated participants to special access passes for the expo.
- See the slides Wan-Teh send to the reflector. Worked on the slides with Bob R. from Red Hat. Both using NSS. Main use case is the encryption of TLS records. This will apply to several other network protocols. TLS records need to be encrypted.
Slide 5) now you can see we are calling C_EncryptInit more than we did in the old days. It is useful to find a way to minimize these calls. slide 6) the IV or nonce must not be repeated. In current API, the IV is provided by the caller. it is important to verify that they are really distinct. Could we have the crypto module generate the IV? then we could verify the module to make sure it's generation of IV is good.
Internet draft from David McGrew also discusses this issue. Slide 7) Encryption part is more complicated, because IV generation must be considered. Wan-Teh would like to propose some AEAD specific functions as outlined on slide 7 Slide 8) new mechanism defined, not discussed in detail Slide 9) GCM and CTR are the target algorithms - others that we're missing? Other use cases? Does this problem really need to be solved? how expensive are C_ENcryptInit Feedback from Bob G: this is the first request we've ever had for a modification on C_EncryptInit/C_Encrypt. Can't we just modify the parameters?
Wan-Teh: Michael StJohn's brought this up, too. for counter mode Bob R: this is essentially just adding a parameter , but without breaking old functions. Bob G: Why don't we do this when we split the API for new function table? Bob R: We'll still need to leave old C_Encrypt alone. Valerie: Why not do this in a more general purpose way with the new
equivalent of C_EnryptInit? This seems too specific. Being specific could help with error messages, etc, but not very flexible.
Bob R: This is more like C_EncryptUpdate. This will create different output based on what is input. AEAD is the first time this was required. Sven: This seems very specific to solving a Google problem. It would be better to look at how do we generally encrypt data? Bob R: we already have something for this, that works for everything but AEAD. AEAD is a new way of doing crypto and this is actually generic, not specifically just for GCM. This is a new way of doing crypto and needs a new function. Wan-Teh: I'm not solving a problem for GOogle, but solving a problem for all permutations of TLS for all implementations based on pkcs11 Michael StJ: Thought we talked about this before. We use GCM, we don't use CCM because it's patented and the license is too expensive. I don't
think this is a bad approach. For us, calling C_EncryptInit over and over again is not a good approach - breaks the pipeline. Bob G.: Let's leave this up for 2 weeks and see if anymore thoughts come in. If not, Wan-Teh can work on a proposal that we can vote on at F2F. Wan-Teh: Michael St. Johns already sent a lot of feedback, most of which will get integrated.
- There are a few that are more substantive comments. Bob would like to suggest we include header files (non-normative, derivataions) with next review. This would be something that would be a deliverable from the committee, instead of each individual generating this themselves. Wan-Teh: I need the header files for other work I was doing. TIm: Chris, did you have some draft header files? Chris: yes, I will dig them out and send them out. AI Chris: send out header files to reflector. Thought on addressing comments: take a cut at the documents for the editorial comments. Bob thinks it will be easier if we have a consistent approach to how we incorporate the fixes. Any editors have any concerns with this approach? Tim: I'm happy for you to do this. Chris: looking at the comments, they seem mostly editorial. Anybody see anything beyond editorial that would require a new proposal or API changes that we need to address in this version? No comments. Any issues or concerns with the comments coming in? Bob G. sent them to everyone, so you should've seen them. All editors: take a look at the comments related to your documents. AI Bob G: get a version of the document to the editors by Thursday or Friday at the latest. Hopefully by the next meeting, we can rewview the outcome of our reviews of these documents.
- AEAD, 2.40 feedback, and forking. Do we need to do a formal proposal to fork? probably. anything else? nothing mentioned.
5 New Business
- none brought up.
6 Review Action Items
- None to review, minutes not all collected.
- Anything else? silence Tim moves to adjourn, Chris Z seconds. Hearing no objections or abstentions, meeting adjourned 1:54PM PT.