MeetingMinutes Minutes04062014

June 04, 2014 Meeting Minutes

Role Call

• Bob G. did roll call, we have quorum. This will be an official meeting.

Proposed Agenda

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
           • • Public Review AES-XTS comments.
             • Statements of Use
         • v3.0 topics
           • • Comments on Wan-Teh's proposal
         • Topics for next call
6. New Business
7. Review Action Items
8. Adjourn

Opening Remarks

Agenda Additions

• none.

Motion to accept agenda

• Tim moves to accept the agenda, Bob R. seconds. No objections or abstentions or discussions. Approved.

Approve Previous Meeting Minutes

• Minutes up for approval: May 21, 2014
• Tim moves to accept the Minutes, Chris seconds. No objections or abstentions or discussions. Approved.

Status on 2.40 second review

• Review is closed. Received one set of comments before the close, one set afterwards.
• first set: Public Review AES-XTS comments.
  • There is a minor typo (reference to "no parameters taken", which is wrong and contradicted with correct information in the same section).
    • Valerie: wants to discuss the more substantive
    • Chris: did we hear from Chet?
    • Bob G: these other changes are substantive enough we'd need another public review.
    • Chris: I'm willing to make the changes, but it depends on the other's thoughts
    • Bob: Tim, any thoughts?
    • Tim: The comments that have been raised are fairly serious in terms of their nature and need to be looked at. I'm concerned we don't have anyone on the TC that has implemented or is planning on implementing this to process the reviews. This would be another public review. I'm loathe to reset this, as it would add another month to the process.
    • Val: wants feedback from Mark Powers
    • Mark: major mistake, this should be 16 bytes and not 8. This is my mistake. It's like a block number on a disk. The other is that we say key types should be 16,24,32 - but 64 is also allowed. COuldn't we simply say: "and 64"? Seems like a minor change. The other AES mechs, like CBC, they always have a disclaimer that says look at the CKM mech structure for the range of key sizes. [xxx] The other alternative to pass another parameter, seems clumsy to me.
    • Bob G: leave the mechanism name as it currently is, as opposed to changing it to XTS-AES
    • Mark: 2 things: we have our mechanism names that have the modes at the very end, I would not change that. If we want to have XTS-AES as a reference, that would be fine.
    • BOb: 4 things: 1) leave mech name the same, but have a reference. 2) clearly the typographical fix 3) Tim - would this count as a typographical error and not require a review?
    • Tim: I think we could agree that 8 to 16 was a typographical change.
    • Hal: ANy change, wording in TC process, any change that would require you to change the implementation is a material change.This seems serious enough we should do this correct.
    • Val: agree
    • TIm: the moment we make a change, we have to take in the entire comment. There is also the problem with parameters for encrypt and decrypt. We don't have a proposal in front of us. There seems to be 3 things keeping this from being usable.
    • Bob R: could we drop it and add it as an addendum?
    • Tim: that's a material change
    • Bob R: I have a problem with sending out something that's wrong, as there are people that take the spec for it's words.
    • Tim: or we can release erratta. We can stop and delay by another 2 months, or we can say we've left this too late and handle it with errata.
    • Bob R: how long would errata take?
    • Hal: probably longer, unless you already have an existing document. It seems if it's an extra month to get to CS, this is supposed to be the signal to implement for people not on the bleeding edge.
    • Bob G: not sure we could get through an OASIS standard review with a known error. If we're planning an errata, not sure that we could really do that. Put together a proposal to fix this as Mark described. We can decide if we want to include a reference to the NIST mechanism list. At the very least we need to add 64. Mark, is that appropriate?
    • Mark: I think that's the easiest way to do it. The only possible problem would be if someone had an existing implementation out there and the AES keys were somehow restricted to 32 and someone was upset about that.
    • Bob G: First thing tomorrow morning , I'll put together a write up on this and send around to folks, including Mark. This would require a voice vote in our next meeting. Hopefully by the time we have the STatements of Use we need, the standard will be ready. I regret that it means we need another public review.
    • Tim: we still have to work on the issue around needing 2 keys. It won't let you pass in 2 key handles, that's what I think Mark was referencing there. My concern, if we are going to address this issue, we need someone that can address it fully. Otherwise we will go from something that isn't quite there, to something that's still not quite there but closer.
      • Mark: has anyone else implemented this?
    • Tim: I have, but not in the pKCS11 context
    • Bob R: I'm worried if we're just extending the AES key. If it's really 2 keys, then it should be a different key type.
    • Tim: You can't refer to two AES keys and use them in XTS mode
    • Bob R: yeah, you can't do that.
    • Tim: or we can take it out and fix it later.
    • Bob R: I think that's what we want to do. I don't think there's a quick fix. There's already a potential disagreement on how to fix the brokenness of the fix.
    • Bob G: we could take a voice vote in this call to see if we should back it out and try again later. Is someone interested in making such a motion?
    • Bob R: Moves to remove 2.8.11 from the current mechanisms document
    • Hal: Seconds the motion.
    • Tim: no need to discuss at this point
    • Bob G: any concerns or issues? Does it make sense for me to contact Marko?
    • Tim: we've reached the viewpoint that you can't implement what's there. we are going to hold this up.
    • Val: this will be a problem for us.
    • Mark: we do have a usage for this.
    • Bob G: we do have a version already moving along, so I'm not sure that will take much longer than removing it.
    • Tim: I disagree, that fixing this will be the same speed as getting v3.0 out. I would support another document.
    • Bob R: This cannot wait for 3.0. Wan-Teh added mechs, did those get added to 2.40?
    • Tim: yes
    • Bob R: we should have a mechanism to get new mechs out
    • Bob G: that document doesn't exist, and not part of this vote
    • Bob R: that's important, though, we still have to figure that out.
    • Bog G: any objections?
    • Valerie: I object.
    • Bob G: any one else? Anyone want a full roll call? [silence] Motion passes with one objection.
  • Other comment for typo for section 2.12.13 and 2.15 (redundancy)
    • Chris: haven't had a chance to look
    • Bob G: have you had a chance to look at this at all?
    • Tim: just a quick glance.
    • Bob G: there may be another typo, but I'll be sure to send this comment around to the entire TC. Those were the only two comments we had, but we will have to do another public review. We will hopefully be ready with statements of use.
  • Statements of Use
    • Bob G: EMC and Redhat are working on Statements of use - shows the community that the standard is important enough to be taken seriously by others. We need to bring those forward to our committee after our next public review, probably in our meeting in July. we'll need them by the end of the month. Tim, any comments on them?
    • Tim: it's what's acceptable to the committee. I think we'll get the 3 w/out a problem. We are held up because we are not at committee specification level, which we need to have to reference in the statement of use.

Moving forward with v3.0

• Wan-Teh's proposal: 2 comments directed at the proposal. 1st comment: missing signature verification and generation functions. I will add those. 2nd comment is to look at the batched request feature in the KMIP protocol. I took a look and I believe that feature is not really appropriate for PKCS11. It's a client/server model, where there is known server or network delay. IN general PKCS11 assumes a token that is local to the computer or even a software implementation. I think adding a batch request feature doesn't seem to be in line with the current PKCS11 API. I will also send a written response to the TC on this.
• Bob G: any further comments or discussion? Mark I noticed that you had a comment as well about macros - was that something that needs to be implemented right now?
• Mark: don't recall that.
• Wan-Teh: that was a comment for Michael St John's proposal. So mark was asking if it would be appropriate to define the current ones as macros that would expand to this new model.
• Bob G: oh, so only relevant to MsJ's proposal. Any other comments or things to talk through?
• Wan-Teh: I'll try to have another proposal next week.
• Bob G: by next meeting, I want to go through the wiki and collect those topics, so we know what outstanding work we need to look at, including Sven's notes. Any other comments?
• Sven: As per Tim Cook's presentation on Monday, it will be a lot easier to use PKCS11 on iOS8. mobile is a very important place, it's very important that we should look at these operating systems.
• Bob G: did you send that around?
• Sven: not yet, will find the right part of the 2 hour call and send out.
• Bob G: hopefully we'll have some advice from Chris on how to expand

Topics for Next Call

• How do we now get out new mechanisms before 3.0?
• Bob G: Can you write up a proposal, Valerie?
• Val: No time, but clearly this is important with everyone on the call that we don't wait until v3.0 for new mechanisms.
• Bob G: how about I take time to write up a couple of paragraphs to take to the team by the next meeting? (AI)
• Val: Sounds good, thanks.

Action Items

• 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)
• 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)

Motion to Adjourn

• Tim moved, Bob R. seconded. No objections or abstentions or discussions. Adjourned 1:45PM US-PDT.