OASIS PKCS 11 TC Public Documents

Number of Documents Show last documents per workgroup
Document Descriptions
OASIS PKCS 11 TC   (Showing 10 of 764)
Document Name # Size State Submitter Date Action
6
44K
Draft
Michelle Brochmann
2020-06-16
Draft of the HSS section for the upcoming PKCS 11 specification.
5
45K
Draft
Michelle Brochmann
2020-06-10
Draft of the HSS section for the upcoming PKCS 11 specification.
4
43K
Draft
Michelle Brochmann
2020-05-12
Draft of the HSS section for the upcoming PKCS 11 specification.
0
9K
Draft
Robert Relyea
2020-04-30
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.
0
8K
Draft
Robert Relyea
2020-04-30
This is the second part of the TLS/HKDF changes. If the policy name is generally acceptable I'll allocate a new policy identifier for it.
0
5K
Draft
Robert Relyea
2020-04-30
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.
0
7K
Draft
Robert Relyea
2020-04-30
This adds a note as to why the change and a warning as to what may break if depending on the old behavior as requested by the TC.
0
7K
Draft
Robert Relyea
2020-04-27
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
0
48K
Draft
Robert Relyea
2020-04-27
Address Daniel's comments: - I kept the bools indicating the presence of optional key handles for 2 reasons: 1) it was consistent with HKDF usage, and 2) in at least one case it affected the actual protocol of the hash. (Rekey rather than non-rekey). - added more specificity about the expected error codes in forbidden conditions. - added more specificity around key types accepted or returned. In addition, the IKE people noted a missing functionality: The derive mechanism needed to make QUICK mode work doesn't exist. I've extended derive APP_B to handle QUICK mode and changed the mechanism name. I've also allocated the mechanism numbers and added them to the spec. bob
0
27K
Draft
Chet Ensign
2020-03-27
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