Draft of the HSS section for the upcoming PKCS 11 specification.

Update the AES_GCM and AES_CCM to account for a new IV generator needed for TLS 1.3. If this proposal is generally accepted, I'll allocate a new identifier for this generator.

This change addresses a 3.0 comment from Martin Thompson. It removes the TLS specific wording, which was wrong. That wording will now be in the policy file.

Here's the wording which implements the semantics we talked about. On further reflection we could solve the issue in another way: Note that even though the operation isn't closed, future calls to xxxxUpdate are undefined if the output buffer is specified. I believe the expected implementation of the semantic was: 1) if no buffer is specified, return CKR_BUFFER_TOO_SMALL and a length big enough to handle whatever data is left. 2) if a buffer is specified, do the final decrypt and now we know the length. if the length is too small, return the full length and cache the decrypted data. On the next call we return that decrypted data. In this mode, calling C_DecryptUpdate again, or using a different encrypted buffer in C_Decrypt would not work as expected. Anyway I think we should discuss this on our next call. bob

PKCS #11 Cryptographic Token Interface Base Specification V3.0, PKCS #11 Cryptographic Token Interface Current Mechanisms Specification V3.0, PKCS #11 Cryptographic Token Interface Historical Mechanisms Specification V3.0, and PKCS #11 Cryptographic Token Interface Profiles V3.0 [1] were approved as Committee Specifications on 19 December 2019. The TC has received 3 Statements of Use from Cryptsoft, Utimaco, and Information Security Corporation [2]. Do you now approve submitting these Committee Specifications to the OASIS membership for consideration as Candidate OASIS Standards? Approving this ballot will result in a 60-day public review after which, if no comments are received, the COSs will be submitted to a membership-wide call for consent. If comments are received, the TC will be asked to vote by Special Majority Ballot on whether to continue to the membership vote. This is explained in TC Process section 3.4.2, Public Review of a Candidate OASIS Standard [3]. This ballot requires a Special Majority Vote [3]. The TC roster currently lists 13 voting members. In order to pass, at least 9 members (2/3 x 13) have to vote Yes and no more than 3 members (1/4 x 13) may vote No. [1] URI for the specifications - PKCS #11 Cryptographic Token Interface Base Specification: http://docs.oasis-open.org/pkcs11/pkcs11-profiles/v3.0/cs01/pkcs11-profiles-v3.0-cs01.html - PKCS #11 Cryptographic Token Interface Current Mechanisms Specification: https://docs.oasis-open.org/pkcs11/pkcs11-curr/v3.0/pkcs11-curr-v3.0.html - PKCS #11 Cryptographic Token Interface Historical Mechanisms Specification: https://docs.oasis-open.org/pkcs11/pkcs11-hist/v3.0/pkcs11-hist-v3.0.html - PKCS #11 Cryptographic Token Interface Profiles: https://docs.oasis-open.org/pkcs11/pkcs11-profiles/v3.0/pkcs11-profiles-v3.0.html [2] Statements of use - Cryptsoft: https://www.oasis-open.org/committees/download.php/66459 - Utimaco https://www.oasis-open.org/committees/download.php/66584 - Information Security Corporation https://www.oasis-open.org/committees/download.php/66711 [3] http://www.oasis-open.org/policies-guidelines/tc-process#OASISstandard