22012014Minutes

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.

    Interop/Demo - Tim
	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. 

    AEAD discussion - Wan-Teh Chang
	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.

	Found a trick to only use C_EncryptUpdate to get the new IV. Before AES
	GCM, NSS could use one C_EncryptInit.

	SLide 4) Now that we have AES-GCM, each record needs a new IV and AAD,
	so now we have to call C_EncryptInit. SO even though they are all
	encrypted with the same key, we have to pass this same key to each
	C_EncryptInit.

	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.


    V2.40 comments - Bob G.

    	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.

    Topics for next call

	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.

7 Adjourn
	Anything else? silence

	Tim moves to adjourn, Chris Z seconds. Hearing no objections or abstentions, meeting adjourned 1:54PM PT.