April 09, 2014 Meeting Minutes
- Bob Griffin performed roll call, we have quorum. This will be an official meeting.
1 Opening remarks (co-chairs)
2 Roll call
3 Review / approval of the agenda
4 Review of previous meeting minutes
5 Old Business
- Status of V2.40 second public review
- v3.0 topics
- Topics for next call
6 New Business
7 Review Action Items
- Bob: Just want to make sure we are ready to move forward. The ballot passed, but want to go over a couple of minor changes. Also go through Wan-Teh's proposal and Sven's document.
- Bob: Talk about secretary position.
Motion to accept agenda
- Tim moves to accept the agenda, Chris seconds. No objections or abstentions or discussions. Approved.
Approve Previous Meeting Minutes
Minutes up for approval: March 26, 2014
- Tim moved, Sue seconded. No objections or abstentions or discussions. Approved.
- Valerie gave summary of secretary of role: prompt minutes (do not need to be word for word, but capture the major points of discussion and decisions and participants), help keeping the wiki clean and up to date. YOu don't have to be a PKCS11 expert. this is a great role for someone learning about PKCS11. It is difficult to take notes and participate in the conversation.
- Bob: Secretary could also manage voting lists and create ballots, but Valerie and Bob are willing to continue doing those roles for now.
- Any volunteers? none. Please email Valerie and Bob if interested.
Status on 2.40 second review
- Sue found one error in the comment log related to the historical doc, which Bob will fix.
- Chris hasn't seen any issues with the comment log
- Bob: Patrick D. had some comments on normative documents and how they reference each other. Tim and Bob had put in a statement that no mechanism is specified for any of the base profiles. This is a reasonable approach: they should be visible, but we don't want to require these in the profiles document.
- Tim: Basically because we have the base profiles set to allow basic PKCS11 usage. You can use PKCS11 without any mechs. Also, you could be using entirely vendor specific mechs, and that shouldn't mean you are not compliant with PKCS11. Two approaches: thank Patrick and leave as is, or add a statement to explain this. Tim is inclined to leave it as is, unless we have any additional changes.
- Bob feels the same way. Any concerns? Silence.
- There's also the issue that Tim brought out with the wording changes required to move the documents forward. Bob will work on that with Chet. Hope to have this submitted before the end of the week. It will only be a 15 day public reviewer. Bob will send a note explicitly to the primary reviewers along with the comment list, so they know that we are taking this seriously.
- Bob: Reminder: we still need 3 statements of use, hopefully before we meet again in 2 weeks.
- Tim: The TC will also need to present profiles and vote on accepting the statement of use. Bob: did we do ballots? Tim: no.
Moving forward with v3.0
- Wan-Teh: Provided a slide deck going over the two approaches.This was in the email titled: Three documents for my PKCS #11 Messaged-Based Encryption proposal
- Bob: should we walk through these proposals? Sure
We can use existing function or new one (C_EncryptAssociationInit)
- First slide goes through this way. Doing this, it's possible to use existing mechanisms in a new way.
If both methods are through the old C_EncryptInit, you'd have to encode the behaviours in the mechanism and function parameters.
If you use the existing function, it has the advantage that it is very clear that there is only one encryption operation. (for things like GetOperationSTate and SetOperationState functions)
Mike: There is something you're not getting here. EncryptAssociation just associates objects for later use: the operation is not really in progress until you start encrypt message. I don't have a problem with it limiting to one operation per session, but don't get it confused with a crypto operation.
- Bob R: there is still crypto associated with that
- Mike: You really do not want to save and restore IV state, for example.
- Bob R: That's part of the parameters, but there's still the key state. There's the derive key
- Mike: wrt that, you're doing a reference between internal key material and external key material. As far as we're concerned, when you start the operation, you're using the same data , it's just been expanded
- Bob R: yes, but it costs to do the expansion. Because it's a recoverable, we want to have the right information. Your implementation may decide to save that key information as well
- Mike: Why does that matter for the API?
- Bob R: it matters, because when you do the restore, you know you'll be doing the encrypt with this specific mechanism.
- Mike: it's used for saving intrablock states - like hash states. Whatever's defined for the intramessage type of saving
- Bob R: that's not true. that's what those functions are for, I wrote the specs for those. I want to restore or close a session. you can clone without this, but it's more expensive. I need to be able to save and restore the state.
- Mike: This is designed for a tiny device that can only do one session?
- Bob R: yes
- Mike: Is it time to deprecate it?
- Bob R: possibly, but this is only one issue. We're basically arguing about spelling.
- Mike we could make this work with one operation - the call tells you which direction you're going in. What I looked at, is we're looking at a minimum of 12 new APIS. That might be okay, but be aware we're looking at an expansion function. If you want to save and restore a session, that adds to the complexity in an interesting manner.
- Bob R: I'd prefer to do that, or I'll have to have a big switch statement for things I can currently handle with save/resume state.
- Mike: But you'll already be modifying your code to work with a message based system
- Bob R: I could write new code that only works for the messaging system, or I can leverage existing code.
- Mike: You want an equiv of save and resume for sign and verify?
- Bob R: ... then it's already there
- Mike: instead of using an implicit association, it has to be one operation per session. If we do that and a new association is needed, ... then it is being managed for you.
- Bob R.: if that's true, then I wouldn't have to do that, that's true of current Encrypt
- Mike: do you want to save one session and resume to another
- Bob R: no, but that is permitted: that's how you copy.
- Mike: a new association would give you a new handle?
- BobR: no, if we want to do that, that's a completely separate conversation. If you want to change the semantics, then that's a different proposal
- Mike: a session isn't that: it's just key/mechanism state
- Bob R: it's key and crypto state. if you want to split those into something else, let's split them out as a separate proposal
- Mike: two things: one for encryption, one for signature. let's you do things like email processing. If neither sign nor encrypt are in progress, there is not state for the session.
- Bob R: that's true, it's not be used yet. the reason for existing is to hold encryption state
- Mike: it exists between function init and func finals, state is indeterminate. if you now put association in as a 3rd or 4th state vector. The key, the mech and the IV are now associated with the session.
- Bob R: they've always been associated with the session
- Mike: No they haven't
Bob R: yes, they do. EncryptInit: that's whe you pass the key in
- Mike: associated with the operation that is part of the session, but
- Bob R: if you want to split that for something else, that is a different proposal. current one saves it in the encryption state
- Mike: treat it as a wrap-around for the existing functionality. it's giving you a lifetime for the data. we are changing what the data means by adding the association into it. it was there for one message and it was gone. it did not persist message to message
- Bob R: that's not correct. the notion ofmessage doesn't exist in our current system. there's no breakdown between c-encrypt is beginning and final is the end. when I encrypt a chunck of data from SSL, I do a a bunch of encrypt/wait. in between that's stuff being sent off to the client. in the end, I say done. there are multiple messages, kept same IV and key state.
- Mike: which mechs?
- Bob R: CBC and the C mechanisms
- Mike: no , CBC uses a new IV for every message sent
- Bob: not in CBC, the IV is implicit based on previous, that's what's in the encryption state
- Mike: I understand that's what's in the ... the protocol allows you to use the last block of the previous message. that's how that version of TLS works
- Bob; it doesn't explicitly send a new CBC
- Mike: did you look at IPsec
- Bob G: tries to interrupt
- Mike: Yes, we're getting too far down, but if it's missing sign verify, depending too much on building a specific mech instead of being generic, questions on what it really is no body agrees on
- Bob R: I agree on it
- Mike: no crypto state except those pieces of static data. ... I'm using the underlying code to do something. I don't have any pending crypto state except this association stuff
- Bob R: you just invented new things that weren't part of the spec before. I'm fine with that, if you want to do that work, but that's not this proposal is about. this is to create enough stuff to handle the new RFC semantics
- Mike: for AEAD?
- Bob R: yes.
- Mike: How about generic message processing? how would you wrap it around the existing protocols? there's message processing,...
- Bob R: there's a bunch of stuff we dn't need to pass into the PKCS11 layer, AEAD does require us to handle the whole package that we couldn't do before. that's why we're here. if you want to talk about the other stuff, that's fine, but not in this proposal. I have no use for something that does packaging of S/MIME packages. it just needs whatever primitives it needs.
- Bob G: Breaking in here. it seems the question is whether or not to create a new function. Is that your sense as well? do you want to focus the proposal on that area and bring it forward for a vote?
- Wan-Teh: it's true, my preference is to add a new function. I think I'm using association in a different way than Mike originally proposed. Wan-teh will write his association definition down (AI) I want to perform common initialization.
- Mike: you have the key and mech, what other init do you need to do?
- Wan-Teh: it is possible (AES) to derive the key in a different way for decryption. that information is readily available, I just don't want the token to try to infer that from the mechanism.
- Bob G: are there any changes you'd need to make tp pkcs11messagebasedencryption? or is that ready to go
- Wan-Teh: I need to update so that I'm using the terminology correctly, I will try to avoide using association.
- Mike: trim out the options, as those still need to be discussed.
- Bob G: Wan-Teh, bring forward the document with your responses to mike to the next call so we can bring it to a vote.
- Wan-teh: I am taking next week off, so ...
- Bob G: We'll target the call after that (first wed in May) . Bob R or Stef: do you want to talk more about the forking thing?
- Stef: this is an area of complexity, I want to discuss with Bob R.
- Bob R.: this is mostly a documentation change, but will it cause problems for future implementations?
- Stef: I'd like to hear from the Oracle guys
- Bob G: could we bring this forward in 2 weeks?
- Stef/Bob R: sure
- * Stef
- wants to bring forward introspection of attributes
- Bob G; could you bring that forward in the next 2 weeks?
- Stef: I also have to complete the function table/stub layer. I will try to do both.
- Bob G: at least bring forward the introspection to start discussion.
- Stef: Okay.
- Bob G: If you have anything else for 3.0, bring them forward before our next meeting
- Bob will double check to make sure that if anyone should be a voting member is promoted before this ballot to promote the documents goes out. Valerie did this last week, so we should be pretty current. If there are any questions about your member status, please send a note to Bob and Valerie. Verified with Chet that we can take this as the motion to move the documents through. Bob hopes to get the request out before our next meeting. (complete)
- Tim noted that we won't have the right wording in the document at the vote time to say committee spec draft. Bob noted that last time when he changed the document, Chet made him back out the changes. Chet then later changed the wording. Tim is concerned these document may not be accepted without the adding the correct wording or to allow Chet to modify the the documents after a vote to move them forward. Tim wonders if we should change the wording of our motion. Bob thinks we're okay and will confirm with Chet. (AI for Bob to confirm with Chet)
- Valerie: create 3.0 suggestion document, move 2.40 suggestions over into new 3.0 suggestion document. (not started, yet)
- 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.
- Valerie (et al): add new suggestions to the 3.0 wiki, so we can track if they have owners and are moving forward.
Motion to Adjourn
- Tim moved, Bob R seconded. No objections or abstentions or discussions. Adjourned 1:57PM PT.