P11 Header file discussion summary

[Valerie Fenwick <valerie.fenwick@oracle.com>]

Hi folks-

Thank you so much to Chris Z, Tim H, Bob R, Dina K. for taking the time to 
discuss this, I really do appreciate the discussion. I apologize for the delay 
in getting these notes together

I'm using voice recognition software, so I blame any errors on that instead of
me ;-)

I would like to share these notes the entire TC, as it may help clear up other
folks misconceptions.  Note, no decisions were made. All of the below are
clarifications. Where there is need to update the standard for clarifications,
that will be discussed at a future meeting and handled with the ballot process,
as per our other changes to the standard itself.

Here are my major takeaways:

1) we need a github repo ASAP so folks can view the current version of the
header file, and provide comments directly via github. [Note: Bob and I are
still working with Chet on this].

2) there was some confusion around whether our minor versions of the standard
needed to maintain backwards compatibility. That has been cleared up with the
reference: Quoting from 2.40 Errata, section 3.1 "Minor revisions of the
Cryptoki standard are always upwardly compatible within the same major version
number."

2a) it was unclear why constant values needed to be consistent across versions.
That is captured above, in that an application written for version 2.20 should
be able to still run on top of version 2.40 library, for example (just accessing 
fewer features/mechanisms). As our standard does not use explicit string values 
(char *), and instead uses the hex values for everything, two computer programs 
talking to each other will rely on the hex values remaining consistent between 
minor revisions of the standard. Basically, interoperability.

3) some vendors had built logic into their code around certain types of
mechanisms being in certain parts of the mechanism range. That was never
guaranteed to work, unfortunately for those of you who made code decisions like
this. That worked for a while, but stopped working with version 2.40.

4) The TC made a decision in the February 2016 face-to-face meeting, as
documented in our minutes, that while the current wording in the standard does
allow us to break backwards compatibility with 3.0, the TC has chosen not to do
that.

We clearly cannot expect all of our users, developers, and vendors to read
all sets of our meeting minutes :-) Valerie will write up a proposed change for
the 3.0 documents that will specify that the TC has chosen to *NOT* break
backwards compatibility with 3.0, but that we will reserve the right to do so in
a future major revision. This should make it clear to all, and make it clear
that the TC has decided to do this.

5) There are concerns that if the author of their proposal sets the constant
values in their proposal, but the ballot is not successful, we will waste unused 
mechanism IDs, for example.  We do already have gaps in the ranges, so while not 
 very nice, it would not break backwards compatibility to have gaps. But, 
perhaps we should not set ourselves up to have gaps.

6) Another concern is that multiple proposals will come forward at the same
time, using the same hex values.

7) Many vendors will implement a standard before is an OASIS final standard, so
waiting until the very end of the process to set the IDs is too late.

8) We have been talking about leveraging our committee notes, to get mechanisms
out faster, perhaps as an addendum to the 2.40 Errata. We should discuss this
further with the TC, but this may be a way of solving the problem.

9) There is confusion about the we are starting with version 2.40 of the
standard for our 3.0 work product, with a 2.40 errata document. We should make
it clear with the TC motion to our intent is. Both cochairs believed we will
start with the 2.40 errata document.


With that, at least I feel like I have a better understanding of the overall
concerns. At this point to decide specifically when the mechanism IDs should be
set, I do believe we should take this back to the TC. I'm happy to put this on
the agenda for next time. I have a couple of suggestions, specifically where
we have a timeline for when they are set, between ballot approval and when
the final specification is done

sound good?

Valerie


--
Note: I am using voice recognition software. Forgive any strange words.
Valerie Fenwick, http://bubbva.blogspot.com/ @bubbva
Solaris Cryptographic & Key Management Technologies, Manager
Oracle Corporation: 4180 Network Circle, Santa Clara, CA, 95054.