PKCS #11 Cryptographic Token Interface Historical Mechanisms Specification Version 3.0 OASIS Standard 15 June 2020

This stage: https://docs.oasis-open.org/pkcs11/pkcs11-hist/v3.0/os/pkcs11-hist-v3.0-os.docx (Authoritative) https://docs.oasis-open.org/pkcs11/pkcs11-hist/v3.0/os/pkcs11-hist-v3.0-os.html https://docs.oasis-open.org/pkcs11/pkcs11-hist/v3.0/os/pkcs11-hist-v3.0-os.pdf Previous stage: N/A Latest stage: https://docs.oasis-open.org/pkcs11/pkcs11-hist/v3.0/pkcs11-hist-v3.0.docx (Authoritative) https://docs.oasis-open.org/pkcs11/pkcs11-hist/v3.0/pkcs11-hist-v3.0.html https://docs.oasis-open.org/pkcs11/pkcs11-hist/v3.0/pkcs11-hist-v3.0.pdf Technical Committee: OASIS PKCS 11 TC Chairs: Tony Cox ([email protected]), Cryptsoft Pty Ltd Robert Relyea ([email protected]), Red Hat Editors: Chris Zimman ([email protected]), Individual Dieter Bong ([email protected]), Utimaco IS GmbH Additional artifacts: This prose specification is one component of a Work Product that also includes: • PKCS #11 header files: https://docs.oasis-open.org/pkcs11/pkcs11-hist/v3.0/os/include/pkcs11-v3.0/ • ALERT: Due to a clerical error when publishing the Committee Specification, the header files listed above are outdated and may contain serious flaws. The TC is addressing this in the next round of edits. Meanwhile, users of the standard can find the correct header files at https://github.com/oasis- tcs/pkcs11/tree/master/working/3-00-current. Related work: This specification replaces or supersedes: • PKCS #11 Cryptographic Token Interface Historical Mechanisms Specification Version 2.40. Edited by Susan Gleeson, Chris Zimman, Robert Griffin, and Tim Hudson. Latest stage. http://docs.oasis- open.org/pkcs11/pkcs11-hist/v2.40/pkcs11-hist-v2.40.html. This specification is related to: • PKCS #11 Cryptographic Token Interface Profiles Version 3.0. Edited by Tim Hudson. Latest stage. https://docs.oasis-open.org/pkcs11/pkcs11-profiles/v3.0/pkcs11-profiles-v3.0.html.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 1 of 64 • PKCS #11 Cryptographic Token Interface Base Specification Version 3.0. Edited by Chris Zimman and Dieter Bong. Latest stage. https://docs.oasis-open.org/pkcs11/pkcs11-base/v3.0/pkcs11-base- v3.0.html. • PKCS #11 Cryptographic Token Interface Current Mechanisms Specification Version 3.0. Edited by Chris Zimman and Dieter Bong. Latest stage. https://docs.oasis-open.org/pkcs11/pkcs11- curr/v3.0/pkcs11-curr-v3.0.html. Abstract: This document defines mechanisms for PKCS #11 that are no longer in general use. Status: This document was last revised or approved by the membership of OASIS on the above date. The level of approval is also listed above. Check the "Latest stage" location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at https://www.oasis- open.org/committees/tc_home.php?wg_abbrev=pkcs11#technical. TC members should send comments on this document to the TC's email list. Others should send comments to the TC's public comment list, after subscribing to it by following the instructions at the "Send A Comment" button on the TC's web page at https://www.oasis-open.org/committees/pkcs11/. This specification is provided under the RF on RAND Terms Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC's web page (https://www.oasis- open.org/committees/pkcs11/ipr.php). Note that any machine-readable content (Computer Language Definitions) declared Normative for this Work Product is provided in separate plain text files. In the event of a discrepancy between any such plain text file and display content in the Work Product's prose narrative document(s), the content in the separate plain text file prevails. Citation format: When referencing this specification, the following citation format should be used: [PKCS11-Historical-v3.0] PKCS #11 Cryptographic Token Interface Historical Mechanisms Specification Version 3.0. Edited by Chris Zimman and Dieter Bong. 15 June 2020. OASIS Standard. https://docs.oasis- open.org/pkcs11/pkcs11-hist/v3.0/os/pkcs11-hist-v3.0-os.html. Latest stage: https://docs.oasis- open.org/pkcs11/pkcs11-hist/v3.0/pkcs11-hist-v3.0.html.

Copyright © OASIS Open 2020. All Rights Reserved. All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so. OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims. The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark for above guidance.

1 Introduction ...... 8 1.1 IPR Policy ...... 8 1.2 Description of this Document ...... 8 1.3 Terminology ...... 8 1.4 Definitions ...... 8 1.5 Normative References ...... 9 1.6 Non-Normative References ...... 9 2 Mechanisms ...... 12 2.1 PKCS #11 Mechanisms ...... 12 2.2 FORTEZZA timestamp ...... 14 2.3 KEA ...... 15 2.3.1 Definitions ...... 15 2.3.2 KEA mechanism parameters ...... 15 2.3.2.1 CK_KEA_DERIVE_PARAMS; CK_KEA_DERIVE_PARAMS_PTR ...... 15 2.3.3 KEA public key objects ...... 16 2.3.4 KEA private key objects ...... 16 2.3.5 KEA key pair generation ...... 17 2.3.6 KEA key derivation ...... 18 2.4 RC2 ...... 19 2.4.1 Definitions ...... 19 2.4.2 RC2 secret key objects ...... 19 2.4.3 RC2 mechanism parameters ...... 20 2.4.3.1 CK_RC2_PARAMS; CK_RC2_PARAMS_PTR ...... 20 2.4.3.2 CK_RC2_CBC_PARAMS; CK_RC2_CBC_PARAMS_PTR ...... 20 2.4.3.3 CK_RC2_MAC_GENERAL_PARAMS; CK_RC2_MAC_GENERAL_PARAMS_PTR ...... 20 2.4.4 RC2 key generation ...... 21 2.4.5 RC2-ECB ...... 21 2.4.6 RC2-CBC ...... 22 2.4.7 RC2-CBC with PKCS padding ...... 22 2.4.8 General-length RC2-MAC ...... 23 2.4.9 RC2-MAC ...... 23 2.5 RC4 ...... 24 2.5.1 Definitions ...... 24 2.5.2 RC4 secret key objects ...... 24 2.5.3 RC4 key generation ...... 24 2.5.4 RC4 mechanism ...... 25 2.6 RC5 ...... 25 2.6.1 Definitions ...... 25 2.6.2 RC5 secret key objects ...... 25 2.6.3 RC5 mechanism parameters ...... 26 2.6.3.1 CK_RC5_PARAMS; CK_RC5_PARAMS_PTR ...... 26 2.6.3.2 CK_RC5_CBC_PARAMS; CK_RC5_CBC_PARAMS_PTR ...... 26 2.6.3.3 CK_RC5_MAC_GENERAL_PARAMS; CK_RC5_MAC_GENERAL_PARAMS_PTR ...... 26 2.6.4 RC5 key generation ...... 27 pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 4 of 64 2.6.5 RC5-ECB ...... 27 2.6.6 RC5-CBC ...... 28 2.6.7 RC5-CBC with PKCS padding ...... 28 2.6.8 General-length RC5-MAC ...... 29 2.6.9 RC5-MAC ...... 29 2.7 General block cipher ...... 30 2.7.1 Definitions ...... 30 2.7.2 DES secret key objects ...... 31 2.7.3 CAST secret key objects ...... 31 2.7.4 CAST3 secret key objects ...... 32 2.7.5 CAST128 secret key objects ...... 32 2.7.6 IDEA secret key objects ...... 33 2.7.7 CDMF secret key objects ...... 33 2.7.8 General block cipher mechanism parameters ...... 34 2.7.8.1 CK_MAC_GENERAL_PARAMS; CK_MAC_GENERAL_PARAMS_PTR ...... 34 2.7.9 General block cipher key generation ...... 34 2.7.10 General block cipher ECB ...... 35 2.7.11 General block cipher CBC ...... 35 2.7.12 General block cipher CBC with PCKS padding ...... 36 2.7.13 General-length general block cipher MAC ...... 36 2.7.14 General block cipher MAC ...... 37 2.8 SKIPJACK...... 37 2.8.1 Definitions ...... 37 2.8.2 SKIPJACK secret key objects ...... 38 2.8.3 SKIPJACK Mechanism parameters ...... 39 2.8.3.1 CK_SKIPJACK_PRIVATE_WRAP_PARAMS; CK_SKIPJACK_PRIVATE_WRAP_PARAMS_PTR . 39 2.8.3.2 CK_SKIPJACK_RELAYX_PARAMS; CK_SKIPJACK_RELAYX_PARAMS_PTR ...... 39 2.8.4 SKIPJACK key generation ...... 40 2.8.5 SKIPJACK-ECB64 ...... 41 2.8.6 SKIPJACK-CBC64 ...... 41 2.8.7 SKIPJACK-OFB64 ...... 41 2.8.8 SKIPJACK-CFB64 ...... 41 2.8.9 SKIPJACK-CFB32 ...... 42 2.8.10 SKIPJACK-CFB16 ...... 42 2.8.11 SKIPJACK-CFB8 ...... 42 2.8.12 SKIPJACK-WRAP ...... 43 2.8.13 SKIPJACK-PRIVATE-WRAP ...... 43 2.8.14 SKIPJACK-RELAYX ...... 43 2.9 BATON ...... 43 2.9.1 Definitions ...... 43 2.9.2 BATON secret key objects ...... 43 2.9.3 BATON key generation ...... 44 2.9.4 BATON-ECB128 ...... 44 2.9.5 BATON-ECB96...... 45 2.9.6 BATON-CBC128 ...... 45 2.9.7 BATON-COUNTER ...... 45 pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 5 of 64 2.9.8 BATON-SHUFFLE ...... 46 2.9.9 BATON WRAP ...... 46 2.10 JUNIPER...... 46 2.10.1 Definitions ...... 46 2.10.2 JUNIPER secret key objects ...... 46 2.10.3 JUNIPER key generation ...... 47 2.10.4 JUNIPER-ECB128 ...... 47 2.10.5 JUNIPER-CBC128 ...... 48 2.10.6 JUNIPER-COUNTER ...... 48 2.10.7 JUNIPER-SHUFFLE ...... 48 2.10.8 JUNIPER WRAP ...... 49 2.11 MD2 ...... 49 2.11.1 Definitions ...... 49 2.11.2 MD2 digest ...... 49 2.11.3 General-length MD2-HMAC ...... 49 2.11.4 MD2-HMAC ...... 50 2.11.5 MD2 key derivation ...... 50 2.12 MD5 ...... 50 2.12.1 Definitions ...... 50 2.12.2 MD5 Digest ...... 51 2.12.3 General-length MD5-HMAC ...... 51 2.12.4 MD5-HMAC ...... 51 2.12.5 MD5 key derivation ...... 51 2.13 FASTHASH ...... 52 2.13.1 Definitions ...... 52 2.13.2 FASTHASH digest ...... 52 2.14 PKCS #5 and PKCS #5-style password-based encryption (PBD) ...... 52 2.14.1 Definitions ...... 52 2.14.2 Password-based encryption/authentication mechanism parameters...... 53 2.14.2.1 CK_PBE_PARAMS; CK_PBE_PARAMS_PTR ...... 53 2.14.3 MD2-PBE for DES-CBC ...... 53 2.14.4 MD5-PBE for DES-CBC ...... 53 2.14.5 MD5-PBE for CAST-CBC ...... 54 2.14.6 MD5-PBE for CAST3-CBC ...... 54 2.14.7 MD5-PBE for CAST128-CBC ...... 54 2.14.8 SHA-1-PBE for CAST128-CBC ...... 54 2.15 PKCS #12 password-based encryption/authentication mechanisms ...... 54 2.15.1 Definitions ...... 54 2.15.2 SHA-1-PBE for 128-bit RC4 ...... 55 2.15.3 SHA-1_PBE for 40-bit RC4 ...... 56 2.15.4 SHA-1_PBE for 128-bit RC2-CBC ...... 56 2.15.5 SHA-1_PBE for 40-bit RC2-CBC ...... 56 2.16 RIPE-MD ...... 56 2.16.1 Definitions ...... 56 2.16.2 RIPE-MD 128 Digest ...... 57 2.16.3 General-length RIPE-MD 128-HMAC ...... 57 pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 6 of 64 2.16.4 RIPE-MD 128-HMAC ...... 57 2.16.5 RIPE-MD 160 ...... 57 2.16.6 General-length RIPE-MD 160-HMAC ...... 57 2.16.7 RIPE-MD 160-HMAC ...... 58 2.17 SET ...... 58 2.17.1 Definitions ...... 58 2.17.2 SET mechanism parameters ...... 58 2.17.2.1 CK_KEY_WRAP_SET_OAEP_PARAMS; CK_KEY_WRAP_SET_OAEP_PARAMS_PTR ...... 58 2.17.3 OAEP key wrapping for SET ...... 58 2.18 LYNKS ...... 59 2.18.1 Definitions ...... 59 2.18.2 LYNKS key wrapping ...... 59 3 PKCS #11 Implementation Conformance ...... 60 Appendix A. Acknowledgments ...... 61 Appendix B. Manifest constants ...... 63 Appendix C. Revision History ...... 64

2 1.1 IPR Policy 3 This specification is provided under the RF on RAND Terms Mode of the OASIS IPR Policy, the mode 4 chosen when the Technical Committee was established. For information on whether any patents have 5 been disclosed that may be essential to implementing this specification, and any offers of patent licensing 6 terms, please refer to the Intellectual Property Rights section of the TC's web page (https://www.oasis- 7 open.org/committees/pkcs11/ipr.php).

8 1.2 Description of this Document 9 This document defines historical PKCS#11 mechanisms, that is, mechanisms that were defined for earlier 10 versions of PKCS #11 but are no longer in general use 11 All text is normative unless otherwise labeled.

12 1.3 Terminology 13 The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD 14 NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described 15 in [RFC2119].

16 1.4 Definitions 17 For the purposes of this standard, the following definitions apply. Please refer to [PKCS#11-Base] for 18 further definitions 19 BATON MISSI’s BATON block cipher. 20 CAST Entrust Technologies’ proprietary symmetric block cipher 21 CAST3 Entrust Technologies’ proprietary symmetric block cipher 22 CAST128 Entrust Technologies’ symmetric block cipher. 23 CDMF Commercial Data Masking Facility, a block encipherment method 24 specified by International Business Machines Corporation and 25 based on DES. 26 CMS Cryptographic Message Syntax (see RFC 3369) 27 DES Data Encryption Standard, as defined in FIPS PUB 46-3 28 ECB Electronic Codebook mode, as defined in FIPS PUB 81. 29 FASTHASH MISSI’s FASTHASH message-digesting algorithm. 30 IDEA Ascom Systec’s symmetric block cipher. 31 IV Initialization Vector. 32 JUNIPER MISSI’s JUNIPER block cipher. 33 KEA MISSI’s Key Exchange Algorithm. 34 LYNKS A smart card manufactured by SPYRUS. 35 MAC Message Authentication Code 36 MD2 RSA Security’s MD2 message-digest algorithm, as defined in RFC 37 6149.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 8 of 64 38 MD5 RSA Security’s MD5 message-digest algorithm, as defined in RFC 39 1321. 40 PRF Pseudo random function. 41 RSA The RSA public-key cryptosystem. 42 RC2 RSA Security’s RC2 symmetric block cipher. 43 RC4 RSA Security’s proprietary RC4 symmetric stream cipher. 44 RC5 RSA Security’s RC5 symmetric block cipher. 45 SET The Secure Electronic Transaction protocol. 46 SHA-1 The (revised) Secure Hash Algorithm with a 160-bit message digest, 47 as defined in FIPS PUB 180-2. 48 SKIPJACK MISSI’s SKIPJACK block cipher. 49

50 1.5 Normative References 51 [PKCS #11-Base] PKCS #11 Cryptographic Token Interface Base Specification Version 2.40. 52 Edited by Susan Gleeson and Chris Zimman. Latest version. http://docs.oasis- 53 open.org/pkcs11/pkcs11-base/v2.40/pkcs11-base-v2.40.html. 54 55 [PKCS #11-Curr] PKCS #11 Cryptographic Token Interface Current Mechanisms Specification 56 Version 2.40. Edited by Susan Gleeson and Chris Zimman. Latest version. 57 http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.html. 58 59 [PKCS #11-Prof] PKCS #11 Cryptographic Token Interface Profiles Version 2.40. Edited by Tim 60 Hudson. Latest version. http://docs.oasis-open.org/pkcs11/pkcs11- 61 profiles/v2.40/pkcs11-profiles-v2.40.html. 62 63 [RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 64 14, RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt. 65

66 1.6 Non-Normative References 67 [ANSI C] ANSI/ISO. American National Standard for Programming Languages – C. 1990 68 [ANSI X9.31] Accredited Standards Committee X9. Digital Signatures Using Reversible Public 69 Key Cryptography for the Financial Services Industry (rDSA). 1998. 70 [ANSI X9.42] Accredited Standards Committee X9. Public Key Cryptography for the Financial 71 Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm 72 Cryptography. 2003 73 [ANSI X9.62] Accredited Standards Committee X9. Public Key Cryptography for the Financial 74 Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA). 1998 75 [CC/PP] G. Klyne, F. Reynolds, C. , H. Ohto, J. Hjelm, M. H. Butler, L. Tran, Editors, 76 W3C. Composite Capability/Preference Profiles (CC/PP): Structure and 77 Vocabularies. 2004, URL: http://www.w3.org/TR/2004/REC-CCPP-struct- 78 vocab-20040115/ 79 [CDPD] Ameritech Mobile Communications et al. Cellular Digital Packet Data System 80 Specifications: Part 406: Airlink Security. 1993 81 [FIPS PUB 46-3] NIST. FIPS 46-3: Data Encryption Standard (DES). October 26, 2999. URL: 82 http://csrc.nist.gov/publications/fips/index.html

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 9 of 64 83 [FIPS PUB 81] NIST. FIPS 81: DES Modes of Operation. December 1980. URL: 84 http://csrc.nist.gov/publications/fips/index.html 85 [FIPS PUB 113] NIST. FIPS 113: Computer Data Authentication. May 30, 1985. URL: 86 http://csrc.nist.gov/publications/fips/index.html 87 [FIPS PUB 180-2] NIST. FIPS 180-2: Secure Hash Standard. August 1, 2002. URL: 88 http://csrc.nist.gov/publications/fips/index.html 89 [FORTEZZA CIPG] NSA, Workstation Security Products. FORTEZZA Cryptologic Interface 90 Programmers Guide, Revision 1.52. November 1985 91 [GCS-API] X/Open Company Ltd. Generic Cryptographic Service API (GCS-API), Base – 92 Draft 2. February 14, 1995. 93 [ISO/IEC 7816-1] ISO/IEC 7816-1:2011. Identification Cards – Integrated circuit cards -- Part 1: 94 Cards with contacts -- Physical Characteristics. 2011 URL: 95 http://www.iso.org/iso/catalogue_detail.htm?csnumber=54089. 96 [ISO/IEC 7816-4] ISO/IEC 7618-4:2013. Identification Cards – Integrated circuit cards – Part 4: 97 Organization, security and commands for interchange. 2013. URL: 98 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumb 99 er=54550. 100 [ISO/IEC 8824-1] ISO/IEC 8824-1:2008. Abstract Syntax Notation One (ASN.1): Specification of 101 Base Notation. 2002. URL: 102 http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber= 103 54012 104 [ISO/IEC 8825-1] ISO/IEC 8825-1:2008. Information Technology – ASN.1 Encoding Rules: 105 Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), 106 and Distinguished Encoding Rules (DER). 2008. URL: 107 http://www.iso.org/iso/home/store/catalogue_ics/catalogue_detail_ics.htm?csnum 108 ber=54011&ics1=35&ics2=100&ics3=60 109 [ISO/IEC 9594-1] ISO/IEC 9594-1:2008. Information Technology – Open System Interconnection – 110 The Directory: Overview of Concepts, Models and Services. 2008. URL: 111 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumb 112 er=53364 113 [ISO/IEC 9594-8] ISO/IEC 9594-8:2008. Information Technology – Open Systems Interconnection 114 – The Directory: Public-key and Attribute Certificate Frameworks. 2008 URL: 115 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumb 116 er=53372 117 [ISO/IEC 9796-2] ISO/IEC 9796-2:2010. Information Technology – Security Techniques – Digital 118 Signature Scheme Giving Message Recovery – Part 2: Integer factorization 119 based mechanisms. 2010. URL: 120 http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumb 121 er=54788 122 [Java MIDP] Java Community Process. Mobile Information Device Profile for Java 2 Micro 123 Edition. November 2002. URL: http://jcp.org/jsr/detail/118.jsp 124 [MeT-PTD] MeT. MeT PTD Definition – Personal Trusted Device Definition, Version 1.0. 125 February 2003. URL: http://www.mobiletransaction.org 126 [PCMCIA] Personal Computer Memory Card International Association. PC Card Standard, 127 Release 2.1. July 1993. 128 [PKCS #1] RSA Laboratories. RSA Cryptography Standard, v2.1. June 14, 2002 URL: 129 ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf 130 [PKCS #3] RSA Laboratories. Diffie-Hellman Key-Agreement Standard, v1.4. November 131 1993. 132 [PKCS #5] RSA Laboratories. Password-Based Encryption Standard, v2.0. March 26, 133 1999. URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs-5v2-0a1.pdf 134 [PKCS #7] RSA Laboratories. Cryptographic Message Syntax Standard, v1.6. November 135 1997 URL : ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-7/pkcs-7v16.pdf

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 10 of 64 136 [PKCS #8] RSA Laboratories. Private-Key Information Syntax Standard, v1.2. November 137 1993. URL : ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-8/pkcs-8v1_2.asn 138 [PKCS #11-UG] PKCS #11 Cryptographic Token Interface Usage Guide Version 2.40. Edited by 139 John Leiseboer and Robert Griffin. Latest version. http://docs.oasis- 140 open.org/pkcs11/pkcs11-ug/v2.40/pkcs11-ug-v2.40.html. 141 [PKCS #12] RSA Laboratories. Personal Information Exchange Syntax Standard, v1.0. 142 June 1999. URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf 143 [RFC 1321] R. Rivest. RFC 1321: The MD5 Message-Digest Algorithm. MIT Laboratory for 144 Computer Science and RSA Data Security, Inc., April 1992. URL: 145 http://www.rfc-editor.org/rfc/rfc1321.txt 146 [RFC 3369] R. Houseley. RFC 3369: Cryptographic Message Syntax (CMS). August 2002. 147 URL: http://www.rfc-editor.org/rfc/rfc3369.txt 148 [RFC 6149] S. Turner and L. Chen. RFC 6149: MD2 to Historic Status. March, 2011. URL: 149 http://www.rfc-editor.org/rfc/rfc6149.txt 150 [SEC-1] Standards for Efficient Cryptography Group (SECG). Standards for Efficient 151 Cryptography (SEC) 1: Elliptic Curve Cryptography. Version 1.0, September 20, 152 2000. 153 [SEC-2] Standards for Efficient cryptography Group (SECG). Standards for Efficient 154 Cryptography (SEC) 2: Recommended Elliptic Curve Domain Parameters. 155 Version 1.0, September 20, 2000. 156 [TLS] IETF. RFC 2246: The TLS Protocol Version 1.0. January 1999. URL: 157 http://ieft.org/rfc/rfc2256.txt 158 [WIM] WAP. Wireless Identity Module. – WAP-260-WIP-20010712.a. July 2001. URL: 159 http://technical.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?Doc 160 Name=/wap/wap-260-wim-20010712-a.pdf 161 [WPKI] WAP. Wireless Application Protocol: Public Key Infrastructure Definition. – WAP- 162 217-WPKI-20010424-a. April 2001. URL: 163 http://technical.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?Doc 164 Name=/wap/wap-217-wpki-20010424-a.pdf 165 [WTLS] WAP. Wireless Transport Layer Security Version – WAP-261-WTLS-20010406- 166 a. April 2001. URL: 167 http://technical.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?Doc 168 Name=/wap/wap-261-wtls-20010406-a.pdf 169 [X.500] ITU-T. Information Technology – Open Systems Interconnection –The Directory: 170 Overview of Concepts, Models and Services. February 2001. (Identical to 171 ISO/IEC 9594-1) 172 [X.509] ITU-T. Information Technology – Open Systems Interconnection – The 173 Directory: Public-key and Attribute Certificate Frameworks. March 2000. 174 (Identical to ISO/IEC 9594-8) 175 [X.680] ITU-T. Information Technology – Abstract Syntax Notation One (ASN.1): 176 Specification of Basic Notation. July 2002. (Identical to ISO/IEC 8824-1) 177 [X.690] ITU-T. Information Technology – ASN.1 Encoding Rules: Specification of Basic 178 Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished 179 Encoding Rules (DER). July 2002. (Identical to ISO/IEC 8825-1) 180

182 2.1 PKCS #11 Mechanisms 183 A mechanism specifies precisely how a certain cryptographic process is to be performed. PKCS #11 184 implementations MAY use one or more mechanisms defined in this document. 185 186 The following table shows which Cryptoki mechanisms are supported by different cryptographic 187 operations. For any particular token, of course, a particular operation MAY support only a subset of the 188 mechanisms listed. There is also no guarantee that a token which supports one mechanism for some 189 operation supports any other mechanism for any other operation (or even supports that same mechanism 190 for any other operation). For example, even if a token is able to create RSA digital signatures with the 191 CKM_RSA_PKCS mechanism, it may or may not be the case that the same token MAY also perform 192 RSA encryption with CKM_RSA_PKCS. 193 Table 1, Mechanisms vs. Functions

Functions Encrypt Sign SR Wrap Gen. Mechanism & & & Digest & Derive Key/ Decrypt Verify VR1 Unwrap Key Pair

CKM_FORTEZZA_TIMESTAMP X2 CKM_KEA_KEY_PAIR_GEN X CKM_KEA_KEY_DERIVE X CKM_RC2_KEY_GEN X CKM_RC2_ECB X X CKM_RC2_CBC X X CKM_RC2_CBC_PAD X X CKM_RC2_MAC_GENERAL X CKM_RC2_MAC X CKM_RC4_KEY_GEN X CKM_RC4 X CKM_RC5_KEY_GEN X CKM_RC5_ECB X X CKM_RC5_CBC X X CKM_RC5_CBC_PAD X X CKM_RC5_MAC_GENERAL X CKM_RC5_MAC X CKM_DES_KEY_GEN X CKM_DES_ECB X X CKM_DES_CBC X X CKM_DES_CBC_PAD X X CKM_DES_MAC_GENERAL X CKM_DES_MAC X CKM_CAST_KEY_GEN X CKM_CAST_ECB X X CKM_CAST_CBC X X CKM_CAST_CBC_PAD X X CKM_CAST_MAC_GENERAL X CKM_CAST_MAC X

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 12 of 64 Functions Encrypt Sign SR Wrap Gen. Mechanism & & & Digest & Derive Key/ Decrypt Verify VR1 Unwrap Key Pair

CKM_CAST3_KEY_GEN X CKM_CAST3_ECB X X CKM_CAST3_CBC X X CKM_CAST3_CBC_PAD X X CKM_CAST3_MAC_GENERAL X CKM_CAST3_MAC X CKM_CAST128_KEY_GEN X CKM_CAST128_ECB X X CKM_CAST128_CBC X X CKM_CAST128_CBC_PAD X X CKM_CAST128_MAC_GENERAL X CKM_CAST128_MAC X CKM_IDEA_KEY_GEN X CKM_IDEA_ECB X X CKM_IDEA_CBC X X CKM_IDEA_CBC_PAD X X CKM_IDEA_MAC_GENERAL X CKM_IDEA_MAC X CKM_CDMF_KEY_GEN X CKM_CDMF_ECB X X CKM_CDMF_CBC X X CKM_CDMF_CBC_PAD X X CKM_CDMF_MAC_GENERAL X CKM_CDMF_MAC X CKM_SKIPJACK_KEY_GEN X CKM_SKIPJACK_ECB64 X CKM_SKIPJACK_CBC64 X CKM_SKIPJACK_OFB64 X CKM_SKIPJACK_CFB64 X CKM_SKIPJACK_CFB32 X CKM_SKIPJACK_CFB16 X CKM_SKIPJACK_CFB8 X CKM_SKIPJACK_WRAP X CKM_SKIPJACK_PRIVATE_WRAP X CKM_SKIPJACK_RELAYX X3 CKM_BATON_KEY_GEN X CKM_BATON_ECB128 X CKM_BATON_ECB96 X CKM_BATON_CBC128 X CKM_BATON_COUNTER X CKM_BATON_SHUFFLE X CKM_BATON_WRAP X CKM_JUNIPER_KEY_GEN X CKM_JUNIPER_ECB128 X CKM_JUNIPER_CBC128 X pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 13 of 64 Functions Encrypt Sign SR Wrap Gen. Mechanism & & & Digest & Derive Key/ Decrypt Verify VR1 Unwrap Key Pair

CKM_JUNIPER_COUNTER X CKM_JUNIPER_SHUFFLE X CKM_JUNIPER_WRAP X CKM_MD2 X CKM_MD2_HMAC_GENERAL X CKM_MD2_HMAC X CKM_MD2_KEY_DERIVATION X CKM_MD5 X CKM_MD5_HMAC_GENERAL X CKM_MD5_HMAC X CKM_MD5_KEY_DERIVATION X CKM_RIPEMD128 X CKM_RIPEMD128_HMAC_GENERAL X CKM_RIPEMD128_HMAC X CKM_RIPEMD160 X CKM_RIPEMD160_HMAC_GENERAL X CKM_RIPEMD160_HMAC X CKM_FASTHASH X CKM_PBE_MD2_DES_CBC X CKM_PBE_MD5_DES_CBC X CKM_PBE_MD5_CAST_CBC X CKM_PBE_MD5_CAST3_CBC X CKM_PBE_MD5_CAST128_CBC X CKM_PBE_SHA1_CAST128_CBC X CKM_PBE_SHA1_RC4_128 X CKM_PBE_SHA1_RC4_40 X CKM_PBE_SHA1_RC2_128_CBC X CKM_PBE_SHA1_RC2_40_CBC X CKM_PBA_SHA1_WITH_SHA1_HMAC X CKM_KEY_WRAP_SET_OAEP X CKM_KEY_WRAP_LYNKS X 194 1 SR = SignRecover, VR = VerifyRecover. 195 2 Single-part operations only. 196 3 Mechanism MUST only be used for wrapping, not unwrapping. 197 The remainder of this section presents in detail the mechanisms supported by Cryptoki and the 198 parameters which are supplied to them. 199 In general, if a mechanism makes no mention of the ulMinKeyLen and ulMaxKeyLen fields of the 200 CK_MECHANISM_INFO structure, then those fields have no meaning for that particular mechanism.

201 2.2 FORTEZZA timestamp 202 The FORTEZZA timestamp mechanism, denoted CKM_FORTEZZA_TIMESTAMP, is a mechanism for 203 single-part signatures and verification. The signatures it produces and verifies are DSA digital signatures 204 over the provided hash value and the current time.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 14 of 64 205 It has no parameters. 206 Constraints on key types and the length of data are summarized in the following table. The input and 207 output data MAY begin at the same location in memory. 208 Table 2, FORTEZZA Timestamp: Key and Data Length

Function Key type Input Length Output Length

C_Sign1 DSA private key 20 40

C_Verify1 DSA public key 20,402 N/A 209 1 Single-part operations only 210 2 Data length, signature length 211 For this mechanism, the ulMinKeySIze and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 212 specify the supported range of DSA prime sizes, in bits.

213 2.3 KEA

214 2.3.1 Definitions 215 This section defines the key type “CKK_KEA” for type CK_KEY_TYPE as used in the CKA_KEY_TYPE 216 attribute of key objects. 217 Mechanisms: 218 CKM_KEA_KEY_PAIR_GEN 219 CKM_KEA_KEY_DERIVE

220 2.3.2 KEA mechanism parameters

221 2.3.2.1 CK_KEA_DERIVE_PARAMS; CK_KEA_DERIVE_PARAMS_PTR 222 CK_KEA_DERIVE_PARAMS is a structure that provides the parameters to the CKM_KEA_DERIVE 223 mechanism. It is defined as follows: 224 typedef struct CK_KEA_DERIVE_PARAMS { 225 CK_BBOOL isSender; 226 CK_ULONG ulRandomLen; 227 CK_BYTE_PTR pRandomA; 228 CK_BYTE_PTR pRandomB; 229 CK_ULONG ulPublicDataLen; 230 CK_BYTE_PTR pPublicData; 231 } CK_KEA_DERIVE_PARAMS; 232 233 The fields of the structure have the following meanings: 234 isSender Option for generating the key (called a TEK). The value 235 is CK_TRUE if the sender (originator) generates the 236 TEK, CK_FALSE if the recipient is regenerating the TEK

237 ulRandomLen the size of random Ra and Rb in bytes

238 pRandomA pointer to Ra data

239 pRandomB pointer to Rb data

240 ulPublicDataLen other party’s KEA public key size

242 CK_KEA_DERIVE_PARAMS_PTR is a pointer to a CK_KEA_DERIVE_PARAMS.

243 2.3.3 KEA public key objects 244 KEA public key objects (object class CKO_PUBLIC_KEY, key type CKK_KEA) hold KEA public keys. 245 The following table defines the KEA public key object attributes, in addition to the common attributes 246 defined for this object class: 247 Table 3, KEA Public Key Object Attributes

Attribute Data type Meaning

CKA_PRIME1,3 Big integer Prime p (512 to 1024 bits, in steps of 64 bits)

CKA_SUBPRIME1,3 Big integer Subprime q (160 bits)

CKA_BASE1,3 Big integer Base g (512 to 1024 bits, in steps of 64 bits)

CKA_VALUE1,4 Big integer Public value y

248 - Refer to [PKCS #11-Base] table 11 for footnotes 249 The CKA_PRIME, CKA_SUBPRIME and CKA_BASE attribute values are collectively the “KEA domain 250 parameters”. 251 The following is a sample template for creating a KEA public key object: 252 CK_OBJECT_CLASS class = CKO_PUBLIC_KEY; 253 CK_KEY_TYPE keyType = CKK_KEA; 254 CK_UTF8CHAR label[] = “A KEA public key object”; 255 CK_BYTE prime[] = {…}; 256 CK_BYTE subprime[] = {…}; 257 CK_BYTE base[] = {…}; 258 CK_BYTE value[] = {…}; 259 CK_ATTRIBUTE template[] = { 260 {CKA_CLASS, &class, sizeof(class)}, 261 {CKA_KEY_TYPE, &keyType, sizeof(keyType)}, 262 {CKA_TOKEN, &true, sizeof(true)}, 263 {CKA_LABEL, label, sizeof(label)-1}, 264 {CKA_PRIME, prime, sizeof(prime)}, 265 {CKA_SUBPRIME, subprime, sizeof(subprime)}, 266 {CKA_BASE, base, sizeof(base)}, 267 {CKA_VALUE, value, sizeof(value)} 268 }; 269

270 2.3.4 KEA private key objects 271 KEA private key objects (object class CKO_PRIVATE_KEY, key type CKK_KEA) hold KEA private keys. 272 The following table defines the KEA private key object attributes, in addition to the common attributes 273 defined for this object class: 274 Table 4, KEA Private Key Object Attributes

Attribute Data type Meaning CKA_PRIME1,4,6 Big integer Prime p (512 to 1024 bits, in steps of 64 bits)

CKA_SUBPRIME1,4,6 Big integer Subprime q (160 bits)

CKA_BASE1,4,6 Big integer Base g (512 to 1024 bits, in steps of 64 bits)

275 Refer to [PKCS #11-Base] table 11 for footnotes 276 277 The CKA_PRIME, CKA_SUBPRIME and CKA_BASE attribute values are collectively the “KEA domain 278 parameters”. 279 Note that when generating a KEA private key, the KEA parameters are not specified in the key’s 280 template. This is because KEA private keys are only generated as part of a KEA key pair, and the KEA 281 parameters for the pair are specified in the template for the KEA public key. 282 The following is a sample template for creating a KEA private key object: 283 CK_OBJECT_CLASS class = CKO_PRIVATE_KEY; 284 CK_KEY_TYPE keyType = CKK_KEA; 285 CK_UTF8CHAR label[] = “A KEA private key object”; 286 CK_BYTE subject[] = {…}; 287 CK_BYTE id[] = {123}; 288 CK_BYTE prime[] = {…}; 289 CK_BYTE subprime[] = {…}; 290 CK_BYTE base[] = {…}; 291 CK_BYTE value[] = {…]; 292 CK_BBOOL true = CK_TRUE; 293 CK_ATTRIBUTE template[] = { 294 {CKA_CLASS, &class, sizeof(class)}, 295 {CKA_KEY_TYPE, &keyType, sizeof(keyType)},Algorithm, as defined by NISTS 296 {CKA_TOKEN, &true, sizeof(true)}, 297 {CKA_LABEL, label, sizeof(label) -1}, 298 {CKA_SUBJECT, subject, sizeof(subject)}, 299 {CKA_ID, id, sizeof(id)}, 300 {CKA_SENSITIVE, &true, sizeof(true)}, 301 {CKA_DERIVE, &true, sizeof(true)}, 302 {CKA_PRIME, prime, sizeof(prime)}, 303 {CKA_SUBPRIME, subprime, sizeof(subprime)}, 304 {CKA_BASE, base, sizeof(base)], 305 {CKA_VALUE, value, sizeof(value)} 306 };

307 2.3.5 KEA key pair generation 308 The KEA key pair generation mechanism, denoted CKM_KEA_KEY_PAIR_GEN, generates key pairs for 309 the Key Exchange Algorithm, as defined by NIST’s “SKIPJACK and KEA Algorithm Specification Version 310 2.0”, 29 May 1998. 311 It does not have a parameter. 312 The mechanism generates KEA public/private key pairs with a particular prime, subprime and base, as 313 specified in the CKA_PRIME, CKA_SUBPRIME, and CKA_BASE attributes of the template for the public 314 key. Note that this version of Cryptoki does not include a mechanism for generating these KEA domain 315 parameters. 316 The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE and CKA_VALUE attributes to the new 317 public key and the CKA_CLASS, CKA_KEY_TYPE, CKA_PRIME, CKA_SUBPRIME, CKA_BASE, and 318 CKA_VALUE attributes to the new private key. Other attributes supported by the KEA public and private 319 key types (specifically, the flags indicating which functions the keys support) MAY also be specified in the 320 templates for the keys, or else are assigned default initial values. 321 For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 322 specify the supported range of KEA prime sizes, in bits.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 17 of 64 323 2.3.6 KEA key derivation 324 The KEA key derivation mechanism, denoted CKM_KEA_DERIVE, is a mechanism for key derivation 325 based on KEA, the Key Exchange Algorithm, as defined by NIST’s “SKIPJACK and KEA Algorithm 326 Specification Version 2.0”, 29 May 1998. 327 It has a parameter, a CK_KEA_DERIVE_PARAMS structure. 328 This mechanism derives a secret value, and truncates the result according to the CKA_KEY_TYPE 329 attribute of the template and, if it has one and the key type supports it, the CKA_VALUE_LEN attribute of 330 the template. (The truncation removes bytes from the leading end of the secret value.) The mechanism 331 contributes the result as the CKA_VALUE attribute of the new key; other attributes required by the key 332 type must be specified in the template. 333 As defined in the Specification, KEA MAY be used in two different operational modes: full mode and e- 334 mail mode. Full mode is a two-phase key derivation sequence that requires real-time parameter 335 exchange between two parties. E-mail mode is a one-phase key derivation sequence that does not 336 require real-time parameter exchange. By convention, e-mail mode is designated by use of a fixed value 337 of one (1) for the KEA parameter Rb (pRandomB). 338 The operation of this mechanism depends on two of the values in the supplied 339 CK_KEA_DERIVE_PARAMS structure, as detailed in the table below. Note that in all cases, the data 340 buffers pointed to by the parameter structure fields pRandomA and pRandomB must be allocated by the 341 caller prior to invoking C_DeriveKey. Also, the values pointed to by pRandomA and pRandomB are 342 represented as Cryptoki “Big integer” data (i.e., a sequence of bytes, most significant byte first). 343 Table 5, KEA Parameter Values and Operations

Value of Value of big Token Action boolean integer (after checking parameter and template values) isSender pRandomB

CK_TRUE Compute KEA Ra value, store it in pRandomA, return CKR_OK. 0 No derived key object is created.

CK_TRUE 1 Compute KEA Ra value, store it in pRandomA, derive key value using e-mail mode, create key object, return CKR_OK.

CK_TRUE >1 Compute KEA Ra value, store it in pRandomA, derive key value using full mode, create key object, return CKR_OK

CK_FALSE 0 Compute KEA Rb value, store it in pRandomB, return CKR_OK. No derived key object is created.

CK_FALSE 1 Derive key value using e-mail mode, create key object, return CKR_OK. CK_FALSE >1 Derive key value using full mode, create key object, return CKR_OK.

344 Note that the parameter value pRandomB == 0 is a flag that the KEA mechanism is being invoked to 345 compute the party’s public random value (Ra or Rb, for sender or recipient, respectively), not to derive a 346 key. In these cases, any object template supplied as the C_DeriveKey pTemplate argument should be 347 ignored. 348 This mechanism has the following rules about key sensitivity and extractability*:

* Note that the rules regarding the CKA_SENSITIVE, CKA_EXTRACTABLE, CKA_ALWAYS_SENSITIVE, and CKA_NEVER_EXTRACTABLE attributes have changed in version pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 18 of 64 349 • The CKA_SENSITIVE and CKA_EXTRACTABLE attributes in the template for the new key MAY 350 both be specified to be either CK_TRUE or CK_FALSE. If omitted, these attributes each take on 351 some default value. 352 • If the base key has its CKA_ALWAYS_SENSITIVE attribute set to CK_FALSE, then the derived 353 key MUST as well. If the base key has its CKA_ALWAYS_SENSITIVE attribute set to 354 CK_TRUE, then the derived has its CKA_ALWAYS_SENSITIVE attribute set to the same value 355 as its CKA_SENSITIVE attribute. 356 • Similarly, if the base key has its CKA_NEVER_EXTRACTABLE attribute set to CK_FALSE, then 357 the derived key MUST, too. If the base key has its CKA_NEVER_EXTRACTABLE attribute set 358 to CK_TRUE, then the derived key has its CKA_NEVER_EXTRACTABLE attribute set to the 359 opposite value from its CKA_EXTRACTABLE attribute. 360 For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 361 specify the supported range of KEA prime sizes, in bits.

362 2.4 RC2

363 2.4.1 Definitions 364 RC2 is a block cipher which is trademarked by RSA Security. It has a variable keysizse and an additional 365 parameter, the “effective number of bits in the RC2 search space”, which MAY take on values in the 366 range 1-1024, inclusive. The effective number of bits in the RC2 search space is sometimes specified by 367 an RC2 “version number”; this “version number” is not the same thing as the “effective number of bits”, 368 however. There is a canonical way to convert from one to the other. 369 This section defines the key type “CKK_RC2” for type CK_KEY_TYPE as used in the CKA_KEY_TYPE 370 attribute of key objects. 371 Mechanisms: 372 CKM_RC2_KEY_GEN 373 CKM_RC2_ECB 374 CKM_RC2_CBC 375 CKM_RC2_MAC 376 CKM_RC2_MAC_GENERAL 377 CKM_RC2_CBC_PAD

378 2.4.2 RC2 secret key objects 379 RC2 secret key objects (object class CKO_SECRET_KEY, key type CKK_RC2) hold RC2 keys. The 380 following table defines the RC2 secret key object attributes, in addition to the common attributes defined 381 for this object class: 382 Table 6, RC2 Secret Key Object Attributes

Attribute Data type Meaning

CKA_VALUE1,4,6,7 Byte array Key value (1 to 128 bytes) CKA_VALUE_LEN2,3 CK_ULONG Length in bytes of key value

383 Refer to [PKCS #11-Base] table 11 for footnotes

2.11 to match the policy used by other key derivation mechanisms such as CKM_SSL3_MASTER_KEY_DERIVE.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 19 of 64 384 The following is a sample template for creating an RC2 secret key object: 385 CK_OBJECT_CLASS class = CKO_SECRET_KEY; 386 CK_KEY_TYPE keyType = CKK_RC2; 387 CK_UTF8CHAR label[] = “An RC2 secret key object”; 388 CK_BYTE value[] = {…}; 389 CK_BBOOL true = CK_TRUE; 390 CK_ATTRIBUTE template[] = { 391 {CKA_CLASS, &class, sizeof(class)}, 392 {CKA_KEY_TYPE, &keyType, sizeof(keyType)}, 393 {CKA_TOKEN, &true, sizeof(true)}, 394 {CKA_LABEL, label, sizeof(label)-1}, 395 {CKA_ENCRYPT, &true, sizeof(true)}, 396 {CKA_VALUE, value, sizeof(value)} 397 };

398 2.4.3 RC2 mechanism parameters

399 2.4.3.1 CK_RC2_PARAMS; CK_RC2_PARAMS_PTR 400 CK_RC2_PARAMS provides the parameters to the CKM_RC2_ECB and CMK_RC2_MAC mechanisms. 401 It holds the effective number of bits in the RC2 search space. It is defined as follows: 402 typedef CK_ULONG CK_RC2_PARAMS; 403 CK_RC2_PARAMS_PTR is a pointer to a CK_RC2_PARAMS.

404 2.4.3.2 CK_RC2_CBC_PARAMS; CK_RC2_CBC_PARAMS_PTR 405 CK_RC2_CBC_PARAMS is a structure that provides the parameters to the CKM_RC2_CBC and 406 CKM_RC2_CBC_PAD mechanisms. It is defined as follows: 407 typedef struct CK_RC2_CBC_PARAMS { 408 CK_ULONG ulEffectiveBits; 409 CK_BYTE iv[8]; 410 } CK_RC2_CBC_PARAMS; 411 The fields of the structure have the following meanings: 412 ulEffectiveBits the effective number of bits in the RC2 search space

413 iv the initialization vector (IV) for cipher block chaining 414 mode

415 CK_RC2_CBC_PARAMS_PTR is a pointer to a CK_RC2_CBC_PARAMS.

416 2.4.3.3 CK_RC2_MAC_GENERAL_PARAMS; 417 CK_RC2_MAC_GENERAL_PARAMS_PTR 418 CK_RC2_MAC_GENERAL_PARAMS is a structure that provides the parameters to the 419 CKM_RC2_MAC_GENERAL mechanism. It is defined as follows: 420 typedef struct CK_RC2_MAC_GENERAL_PARAMS { 421 CK_ULONG ulEffectiveBits; 422 CK_ULONG ulMacLength; 423 } CK_RC2_MAC_GENERAL_PARAMS; 424 The fields of the structure have the following meanings: 425 ulEffectiveBits the effective number of bits in the RC2 search space

426 ulMacLength length of the MAC produced, in bytes

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 20 of 64 427 CK_RC2_MAC_GENERAL_PARAMS_PTR is a pointer to a CK_RC2_MAC_GENERAL_PARAMS.

428 2.4.4 RC2 key generation 429 The RC2 key generation mechanism, denoted CKM_RC2_KEY_GEN, is a key generation mechanism for 430 RSA Security’s block cipher RC2. 431 It does not have a parameter. 432 The mechanism generates RC2 keys with a particular length in bytes, as specified in the 433 CKA_VALUE_LEN attribute of the template for the key. 434 The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new 435 key. Other attributes supported by the RC2 key type (specifically, the flags indicating which functions the 436 key supports) MAY be specified in the template for the key, or else are assigned default initial values. 437 For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 438 specify the supported range of RC2 key sizes, in bits.

439 2.4.5 RC2-ECB 440 RC2-ECB, denoted CKM_RC2_ECB, is a mechanism for single- and multiple-part encryption and 441 decryption; key wrapping; and key unwrapping, based on RSA Security’s block cipher RC2 and electronic 442 codebook mode as defined in FIPS PUB 81. 443 It has a parameter, a CK_RC2_PARAMS, which indicates the effective number of bits in the RC2 search 444 space. 445 This mechanism MAY wrap and unwrap any secret key. Of course, a particular token MAY not be able to 446 wrap/unwrap every secret key that it supports. For wrapping, the mechanism encrypts the value of the 447 CKA_VALUE attribute of the key that is wrapped, padded on the trailing end with up to seven null bytes 448 so that the resulting length is a multiple of eight. The output data is the same length as the padded input 449 data. It does not wrap the key type, key length, or any other information about the key; the application 450 must convey these separately. 451 For unwrapping, the mechanism decrypts the wrapped key, and truncates the result according to the 452 CKA_KEY_TYPE attribute of the template and, if it has one, and the key type supports it, the 453 CKA_VALUE_LEN attribute of the template. The mechanism contributes the result as the CKA_VALUE 454 attribute of the new key; other attributes required by the key type must be specified in the template. 455 Constraints on key types and the length of data are summarized in the following table: 456 Table 7 RC2-ECB: Key and Data Length

Function Key Input Output length Comments type length C_Encrypt RC2 Multiple of Same as input length No final 8 part C_Decrypt RC2 Multiple of Same as input length No final 8 part

C_WrapKey RC2 Any Input length rounded up to multiple of 8

C_UnwrapKey RC2 Multiple of Determined by type of key being unwrapped or 8 CKA_VALUE_LEN 457 For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 458 specify the supported range of RC2 effective number of bits.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 21 of 64 459 2.4.6 RC2-CBC 460 RC2_CBC, denoted CKM_RC2_CBC, is a mechanism for single- and multiple-part encryption and 461 decryption; key wrapping; and key unwrapping, based on RSA Security’s block cipher RC2 and cipher- 462 block chaining mode as defined in FIPS PUB 81. 463 It has a parameter, a CK_RC2_CBC_PARAMS structure, where the first field indicates the effective 464 number of bits in the RC2 search space, and the next field is the initialization vector for cipher block 465 chaining mode. 466 This mechanism MAY wrap and unwrap any secret key. Of course, a particular token MAY not be able to 467 wrap/unwrap every secret key that it supports. For wrapping, the mechanism encrypts the value of the 468 CKA_VALUE attribute of the key that is wrapped, padded on the trailing end with up to seven null bytes 469 so that the resulting length is a multiple of eight. The output data is the same length as the padded input 470 data. It does not wrap the key type, key length, or any other information about the key; the application 471 must convey these separately. 472 For unwrapping, the mechanism decrypts the wrapped key, and truncates the result according to the 473 CKA_KEY_TYPE attribute of the template and, if it has one, and the key type supports it, the 474 CKA_VALUE_LEN attribute of the template. The mechanism contributes the result as the CKA_VALUE 475 attribute of the new key; other attributes required by the key type must be specified in the template. 476 Constraints on key types and the length of data are summarized in the following table: 477 Table 8, RC2-CBC: Key and Data Length

Function Key Input Output length Comments type length C_Encrypt RC2 Multiple of Same as input length No final 8 part C_Decrypt RC2 Multiple of Same as input length No final 8 part

C_WrapKey RC2 Any Input length rounded up to multiple of 8 C_UnwrapKey RC2 Multiple of Determined by type of key being unwrapped or 8 CKA_VALUE_LEN 478 For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 479 specify the supported range of RC2 effective number of bits.

480 2.4.7 RC2-CBC with PKCS padding 481 RC2-CBC with PKCS padding, denoted CKM_RC2_CBC_PAD, is a mechanism for single- and multiple- 482 part encryption and decryption; key wrapping; and key unwrapping, based on RSA Security’s block cipher 483 RC2; cipher-block chaining mode as defined in FIPS PUB 81; and the block cipher padding method 484 detailed in PKCS #7. 485 It has a parameter, a CK_RC2_CBC_PARAMS structure, where the first field indicates the effective 486 number of bits in the RC2 search space, and the next field is the initialization vector. 487 The PKCS padding in this mechanism allows the length of the plaintext value to be recovered from the 488 ciphertext value. Therefore, when unwrapping keys with this mechanism, no value should be specified 489 for the CKA_VALUE_LEN attribute. 490 In addition to being able to wrap and unwrap secret keys, this mechanism MAY wrap and unwrap RSA, 491 Diffie-Hellman, X9.42 Diffie-Hellman, EC (also related to ECDSA) and DSA private keys (see [PKCS #11- 492 Curr], Miscellaneous simple key derivation mechanisms for details). The entries in the table below 493 for data length constraints when wrapping and unwrapping keys do not apply to wrapping and 494 unwrapping private keys. 495 Constraints on key types and the length of data are summarized in the following table:

Function Key type Input length Output length

C_Encrypt RC2 Any Input length rounded up to multiple of 8

C_Decrypt RC2 Multiple of 8 Between 1 and 8 bytes shorter than input length C_WrapKey RC2 Any Input length rounded up to multiple of 8

C_UnwrapKey RC2 Multiple of 8 Between 1 and 8 bytes shorter than input length

497 For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 498 specify the supported range of RC2 effective number of bits.

499 2.4.8 General-length RC2-MAC 500 General-length RC2-MAC, denoted CKM_RC2_MAC_GENERAL, is a mechanism for single-and 501 multiple-part signatures and verification, based on RSA Security’s block cipher RC2 and data 502 authorization as defined in FIPS PUB 113. 503 It has a parameter, a CK_RC2_MAC_GENERAL_PARAMS structure, which specifies the effective 504 number of bits in the RC2 search space and the output length desired from the mechanism. 505 The output bytes from this mechanism are taken from the start of the final RC2 cipher block produced in 506 the MACing process. 507 Constraints on key types and the length of data are summarized in the following table: 508 Table 10, General-length RC2-MAC: Key and Data Length

Function Key type Data length Signature length

C_Sign RC2 Any 0-8, as specified in parameters

C_Verify RC2 Any 0-8, as specified in parameters

509 For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 510 specify the supported range of RC2 effective number of bits.

511 2.4.9 RC2-MAC 512 RC2-MAC, denoted by CKM_RC2_MAC, is a special case of the general-length RC2-MA mechanism 513 (see Section 2.4.8). Instead of taking a CK_RC2_MAC_GENERAL_PARAMS parameter, it takes a 514 CK_RC2_PARAMS parameter, which only contains the effective number of bits in the RC2 search space. 515 RC2-MAC produces and verifies 4-byte MACs. 516 Constraints on key types and the length of data are summarized in the following table: 517 Table 11, RC2-MAC: Key and Data Length

Function Key type Data length Signature length

C_Sign RC2 Any 4

C_Verify RC2 Any 4

518 For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 519 specify the supported range of RC2 effective number of bits.

521 2.5.1 Definitions 522 This section defines the key type “CKK_RC4” for type CK_KEY_TYPE as used in the CKA_KEY_TYPE 523 attribute of key objects. 524 Mechanisms 525 CKM_RC4_KEY_GEN 526 CKM_RC4

527 2.5.2 RC4 secret key objects 528 RC4 secret key objects (object class CKO_SECRET_KEY, key type CKK_RC4) hold RC4 keys. The 529 following table defines the RC4 secret key object attributes, in addition to the common attributes defined 530 for this object class: 531 Table 12, RC4 Secret Key Object

Attribute Data type Meaning

CKA_VALUE1,4,6,7 Byte array Key value (1 to 256 bytes)

CKA_VALUE_LEN2,3,6 CK_ULONG Length in bytes of key value 532 Refer to [PKCS #11-Base] table 11 for footnotes 533 The following is a sample template for creating an RC4 secret key object: 534 CK_OBJECT_CLASS class = CKO_SECRET_KEY; 535 CK_KEY_TYPE keyType = CKK_RC4; 536 CK_UTF8CHAR label[] = “An RC4 secret key object”; 537 CK_BYTE value[] = {…}; 538 CK_BBOOL true – CK_TRUE; 539 CK_ATTRIBUTE template[] = { 540 {CKA_CLASS, &class, sizeof(class)}, 541 {CKA_KEY_TYPE, &keyType, sizeof(keyType)}, 542 {CKA_TOKEN, &true, sizeof(true)}, 543 {CKA_LABEL, label, sizeof(label)-1}, 544 {CKA_ENCRYPT, &true, sizeof(true)}, 545 {CKA_VALUE, value, sizeof(value} 546 };

547 2.5.3 RC4 key generation 548 The RC4 key generation mechanism, denoted CKM_RC4_KEY_GEN, is a key generation mechanism for 549 RSA Security’s proprietary stream cipher RC4. 550 It does not have a parameter. 551 The mechanism generates RC4 keys with a particular length in bytes, as specified in the 552 CKA_VALUE_LEN attribute of the template for the key. 553 The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new 554 key. Other attributes supported by the RC4 key type (specifically, the flags indicating which functions the 555 key supports) MAY be specified in the template for the key, o r else are assigned default initial values. 556 For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 557 specify the supported range of RC4 key sizes, in bits.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 24 of 64 558 2.5.4 RC4 mechanism 559 RC4, denoted CKM_RC4, is a mechanism for single- and multiple-part encryption and decryption based 560 on RSA Security’s proprietary stream cipher RC4. 561 It does not have a parameter. 562 Constraints on key types and the length of input and output data are summarized in the following table: 563 Table 13, RC4: Key and Data Length

Function Key type Input length Output length Comments

C_Encrypt RC4 Any Same as input length No final part C_Decrypt RC4 Any Same as input length No final part

564 For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 565 specify the supported range of RC4 key sizes, in bits.

566 2.6 RC5

567 2.6.1 Definitions 568 RC5 is a parameterizable block cipher patented by RSA Security. It has a variable wordsize, a variable 569 keysize, and a variable number of rounds. The blocksize of RC5 is equal to twice its wordsize. 570 This section defines the key type “CKK_RC5” for type CK_KEY_TYPE as used in the CKA_KEY_TYPE 571 attribute of key objects. 572 Mechanisms: 573 CKM_RC5_KEY_GEN 574 CKM_RC5_ECB 575 CKM_RC5_CBC 576 CKM_RC5_MAC 577 CKM_RC5_MAC_GENERAL 578 CMK_RC5_CBC_PAD

579 2.6.2 RC5 secret key objects 580 RC5 secret key objects (object class CKO_SECRET_KEY, key type CKK_RC5) hold RC5 keys. The 581 following table defines the RC5 secret key object attributes, in addition to the common attributes defined 582 for this object class. 583 Table 14, RC5 Secret Key Object

Attribute Data type Meaning CKA_VALUE1,4,6,7 Byte array Key value (0 to 255 bytes)

CKA_VALUE_LEN2,3,6 CK_ULONG Length in bytes of key value

584 Refer to [PKCS #11-Base] table 11 for footnotes 585 586 The following is a sample template for creating an RC5 secret key object: 587 CK_OBJECT_CLASS class = CKO_SECRET_KEY; 588 CK_KEY_TYPE keyType = CKK_RC5; 589 CK_UTF8CHAR label[] = “An RC5 secret key object”; 590 CK_BYTE value[] = {…}; 591 CK_BBOOL true = CK_TRUE; pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 25 of 64 592 CK_ATTRIBUTE template[] = { 593 {CKA_CLASS, &class, sizeof(class)}, 594 {CKA_KEY_TYPE, &keyType, sizeof(keyType)}, 595 {CKA_TOKEN, &true, sizeof(true)}, 596 {CKA_LABEL, label, sizeof(label)-1}, 597 {CKA_ENCRYPT, &true, sizeof(true)}, 598 {CKA_VALUE, value, sizeof(value)} 599 };

600 2.6.3 RC5 mechanism parameters

601 2.6.3.1 CK_RC5_PARAMS; CK_RC5_PARAMS_PTR 602 CK_RC5_PARAMS provides the parameters to the CKM_RC5_ECB and CKM_RC5_MAC mechanisms. 603 It is defined as follows: 604 typedef struct CK_RC5_PARAMS { 605 CK_ULONG ulWordsize; 606 CK_ULONG ulRounds; 607 } CK_RC5_PARAMS; 608 The fields of the structure have the following meanings: 609 ulWordsize wordsize of RC5 cipher in bytes

610 ulRounds number of rounds of RC5 encipherment

611 CK_RC5_PARAMS_PTR is a pointer to a CK_RC5_PARAMS.

612 2.6.3.2 CK_RC5_CBC_PARAMS; CK_RC5_CBC_PARAMS_PTR 613 CK_RC5_CBC_PARAMS is a structure that provides the parameters to the CKM_RC5_CBC and 614 CKM_RC5_CBC_PAD mechanisms. It is defined as follows: 615 typedef struct CK_RC5_CBC_PARAMS { 616 CK_ULONG ulWordsize; 617 CK_ULONG ulRounds; 618 CK_BYTE_PTR pIv; 619 CK_ULONG ulIvLen; 620 } CK_RC5_CBC_PARAMS; 621 The fields of the structure have the following meanings: 622 ulwordSize wordsize of RC5 cipher in bytes

623 ulRounds number of rounds of RC5 encipherment

624 pIV pointer to initialization vector (IV) for CBC encryption

625 ulIVLen length of initialization vector (must be same as 626 blocksize)

627 CK_RC5_CBC_PARAMS_PTR is a pointer to a CK_RC5_CBC_PARAMS.

628 2.6.3.3 CK_RC5_MAC_GENERAL_PARAMS; 629 CK_RC5_MAC_GENERAL_PARAMS_PTR 630 CK_RC5_MAC_GENERAL_PARAMS is a structure that provides the parameters to the 631 CKM_RC5_MAC_GENERAL mechanism. It is defined as follows:

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 26 of 64 632 typedef struct CK_RC5_MAC_GENERAL_PARAMS { 633 CK_ULONG ulWordsize; 634 CK_ULONG ulRounds; 635 CK_ULONG ulMacLength; 636 } CK_RC5_MAC_GENERAL_PARAMS; 637 The fields of the structure have the following meanings: 638 ulwordSize wordsize of RC5 cipher in bytes

639 ulRounds number of rounds of RC5 encipherment

640 ulMacLength length of the MAC produced, in bytes

641 CK_RC5_MAC_GENERAL_PARAMS_PTR is a pointer to a CK_RC5_MAC_GENERAL_PARAMS.

642 2.6.4 RC5 key generation 643 The RC5 key generation mechanism, denoted CKM_RC5_KEY_GEN, is a key generation mechanism for 644 RSA Security’s block cipher RC5. 645 It does not have a parameter. 646 The mechanism generates RC5 keys with a particular length in bytes, as specified in the 647 CKA_VALUE_LEN attribute of the template for the key. 648 The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new 649 key. Other attributes supported by the RC5 key type (specifically, the flags indicating which functions the 650 key supports) MAY be specified in the template for the key, or else are assigned default initial values. 651 For this mechanism, the ulMinKeySIze and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 652 specify the supported range of RC5 key sizes, in bytes.

653 2.6.5 RC5-ECB 654 RC5-ECB, denoted CKM_RC5_ECB, is a mechanism for single- and multiple-part encryption and 655 decryption; key wrapping; and key unwrapping, based on RSA Security’s block cipher RC5 and electronic 656 codebook mode as defined in FIPS PUB 81. 657 It has a parameter, CK_RC5_PARAMS, which indicates the wordsize and number of rounds of 658 encryption to use. 659 This mechanism MAY wrap and unwrap any secret key. Of course, a particular token MAY not be able to 660 wrap/unwrap every secret key that it supports. For wrapping, the mechanism encrypts the value of the 661 CKA_VALUE attribute of the key that is wrapped, padded on the trailing end with null bytes so that the 662 resulting length is a multiple of the cipher blocksize (twice the wordsize). The output data is the same 663 length as the padded input data. It does not wrap the key type, key length, or any other information about 664 the key; the application must convey these separately. 665 For unwrapping, the mechanism decrypts the wrapped key, and truncates the result according to the 666 CKA_KEY_TYPE attributes of the template and, if it has one, and the key type supports it, the 667 CKA_VALUE_LEN attribute of the template. The mechanism contributes the result as the CKA_VALUE 668 attribute of the new key; other attributes required by the key type must be specified in the template. 669 Constraints on key types and the length of data are summarized in the following table: 670 Table 15, RC5-ECB Key and Data Length

Function Key Input length Output length Comments type

C_Encrypt RC5 Multiple of Same as input length No final blocksize part

C_WrapKey RC5 Any Input length rounded up to multiple of blocksize C_UnwrapKey RC5 Multiple of Determined by type of key being unwrapped blocksize or CKA_VALUE_LEN

671 For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 672 specify the supported range of RC5 key sizes, in bytes.

673 2.6.6 RC5-CBC 674 RC5-CBC, denoted CKM_RC5_CBC, is a mechanism for single- and multiple-part encryption and 675 decryption; key wrapping; and key unwrapping, based on RSA Security’s block cipher RC5 and cipher- 676 block chaining mode as defined in FIPS PUB 81. 677 It has a parameter, a CK_RC5_CBC_PARAMS structure, which specifies the wordsize and number of 678 rounds of encryption to use, as well as the initialization vector for cipher block chaining mode. 679 This mechanism MAY wrap and unwrap any secret key. Of course, a particular token MAY not be able to 680 wrap/unwrap every secret key that it supports. For wrapping, the mechanism encrypts the value of the 681 CKA_VALUE attribute of the key that is wrapped, padded on the trailing end with up to seven null bytes 682 so that the resulting length is a multiple of eight. The output data is the same length as the padded input 683 data. It does not wrap the key type, key length, or any other information about the key; the application 684 must convey these separately. 685 For unwrapping, the mechanism decrypts the wrapped key, and truncates the result according to the 686 CKA_KEY_TYPE attribute for the template, and, if it has one, and the key type supports it, the 687 CKA_VALUE_LEN attribute of the template. The mechanism contributes the result as the CKA_VALUE 688 attribute of the new key; other attributes required by the key type must be specified in the template. 689 Constraints on key types and the length of data are summarized in the following table: 690 Table 16, RC5-CBC Key and Data Length

Function Key Input length Output length Comments type

C_Encrypt RC5 Multiple of Same as input length No final blocksize part C_Decrypt RC5 Multiple of Same as input length No final blocksize part

C_WrapKey RC5 Any Input length rounded up to multiple of blocksize C_UnwrapKey RC5 Multiple of Determined by type of key being unwrapped blocksize or CKA_VALUE_LEN

691 For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 692 specify the supported range of RC5 key sizes, in bytes.

693 2.6.7 RC5-CBC with PKCS padding 694 RC5-CBC with PKCS padding, denoted CKM_RC5_CBC_PAD, is a mechanism for single- and multiple- 695 part encryption and decryption; key wrapping; and key unwrapping, based on RSA Security’s block cipher 696 RC5; cipher block chaining mode as defined in FIPS PUB 81; and the block cipher padding method 697 detailed in PKCS #7.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 28 of 64 698 It has a parameter, a CK_RC5_CBC_PARAMS structure, which specifies the wordsize and number of 699 rounds of encryption to use, as well as the initialization vector for cipher block chaining mode. 700 The PKCS padding in this mechanism allows the length of the plaintext value to be recovered from the 701 ciphertext value. Therefore, when unwrapping keys with this mechanism, no value should be specified 702 for the CKA_VALUE_LEN attribute. 703 In addition to being able to wrap an unwrap secret keys, this mechanism MAY wrap and unwrap RSA, 704 Diffie-Hellman, X9.42 Diffie-Hellman, EC (also related to ECDSA) and DSA private keys. The entries in 705 the table below for data length constraints when wrapping and unwrapping keys do not apply to wrapping 706 and unwrapping private keys. 707 Constraints on key types and the length of data are summarized in the following table: 708 Table 17, RC5-CBC with PKCS Padding; Key and Data Length

Function Key Input length Output length type

C_Encrypt RC5 Any Input length rounded up to multiple of blocksize

C_Decrypt RC5 Multiple of Between 1 and blocksize bytes shorter than input blocksize length C_WrapKey RC5 Any Input length rounded up to multiple of blocksize

C_UnwrapKey RC5 Multiple of Between 1 and blocksize bytes shorter than input blocksize length 709 For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 710 specify the supported range of RC5 key sizes, in bytes.

711 2.6.8 General-length RC5-MAC 712 General-length RC5-MAC, denoted CKM_RC5_MAC_GENERAL, is a mechanism for single- and 713 multiple-part signatures and verification, based on RSA Security’s block cipher RC5 and data 714 authentication as defined in FIPS PUB 113. 715 It has a parameter, a CK_RC5_MAC_GENERAL_PARAMS structure, which specifies the wordsize and 716 number of rounds of encryption to use and the output length desired from the mechanism. 717 The output bytes from this mechanism are taken from the start of the final RC5 cipher block produced in 718 the MACing process. 719 Constraints on key types and the length of data are summarized in the following table: 720 Table 18, General-length RC2-MAC: Key and Data Length

Function Key type Data length Signature length

C_Sign RC5 Any 0-blocksize, as specified in parameters C_Verify RC5 Any 0-blocksize, as specified in parameters

721 For this mechanism, the ulMinKeySize and ulMaxKeySIze fields of the CK_MECHANISM_INFO structure 722 specify the supported range of RC5 key sizes, in bytes.

723 2.6.9 RC5-MAC 724 RC5-MAC, denoted by CKM_RC5_MAC, is a special case of the general-length RC5-MAC mechanism. 725 Instead of taking a CK_RC5_MAC_GENERAL_PARAMS parameter, it takes a CK_RC5_PARAMS 726 parameter. RC5-MAC produces and verifies MACs half as large as the RC5 blocksize. 727 Constraints on key types and the length of data are summarized in the following table:

Function Key type Data length Signature length

C_Sign RC5 Any RC5 wordsize = [blocksize/2]

C_Verify RC5 Any RC5 wordsize = [blocksize/2] 729 For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 730 specify the supported range of RC5 key sizes, in bytes.

731 2.7 General block cipher

732 2.7.1 Definitions 733 For brevity’s sake, the mechanisms for the DES, CAST, CAST3, CAST128, IDEA and CDMF block 734 ciphers are described together here. Each of these ciphers ha the following mechanisms, which are 735 described in a templatized form. 736 This section defines the key types “CKK_DES”, “CKK_CAST”, “CKK_CAST3”, “CKK_CAST128”, 737 “CKK_IDEA” and “CKK_CDMF” for type CK_KEY_TYPE as used in the CKA_KEY_TYPE attribute of key 738 objects. 739 Mechanisms: 740 CKM_DES_KEY_GEN 741 CKM_DES_ECB 742 CKM_DES_CBC 743 CKM_DES_MAC 744 CKM_DES_MAC_GENERAL 745 CKM_DES_CBC_PAD 746 CKM_CDMF_KEY_GEN 747 CKM_CDMF_ECB 748 CKM_CDMF_CBC 749 CKM_CDMF_MAC 750 CKM_CDMF_MAC_GENERAL 751 CKM_CDMF_CBC_PAD 752 CKM_DES_OFB64 753 CKM_DES_OFB8 754 CKM_DES_CFB64 755 CKM_DES_CFB8 756 CKM_CAST_KEY_GEN 757 CKM_CAST_ECB 758 CKM_CAST_CBC 759 CKM_CAST_MAC 760 CKM_CAST_MAC_GENERAL 761 CKM_CAST_CBC_PAD 762 CKM_CAST3_KEY_GEN 763 CKM_CAST3_ECB 764 CKM_CAST3_CBC 765 CKM_CAST3_MAC

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 30 of 64 766 CKM_CAST3_MAC_GENERAL 767 CKM_CAST3_CBC_PAD 768 CKM_CAST128_KEY_GEN 769 CKM_CAST128_ECB 770 CKM_CAST128_CBC 771 CKM_CAST128_MAC 772 CKM_CAST128_MAC_GENERAL 773 CKM_CAST128_CBC_PAD 774 CKM_IDEA_KEY_GEN 775 CKM_IDEA_ECB 776 CKM_IDEA_MAC 777 CKM_IDEA_MAC_GENERAL 778 CKM_IDEA_CBC_PAD

779 2.7.2 DES secret key objects 780 DES secret key objects (object class CKO_SECRET_KEY, key type CKK_DES) hold single-length DES 781 keys. The following table defines the DES secret key object attributes, in addition to the common 782 attributes defined for this object class: 783 Table 20, DES Secret Key Object

Attribute Data type Meaning

CKA_VALUE1,4,6,7 Byte array Key value (8 bytes long)

784 Refer to [PKCS #11-Base] table 11 for footnotes 785 DES keys MUST have their parity bits properly set as described in FIPS PUB 46-3. Attempting to create 786 or unwrap a DES key with incorrect parity MUST return an error. 787 The following is a sample template for creating a DES secret key object: 788 CK_OBJECT_CLASS class = CKO_SECRET_KEY; 789 CK_KEY_TYPE keyType = CKK_DES; 790 CK_UTF8CHAR label[] = “A DES secret key object”; 791 CK_BYTE value[8] = {…}; 792 CK_BBOOL true = CK_TRUE; 793 CK_ATTRIBUTE template[] = { 794 {CKA_CLASS, &class, sizeof(class)}, 795 {CKA_KEY_TYPE, &keyType, sizeof(keyType)}, 796 {CKA_TOKEN, &true, sizeof(true)}, 797 {CKA_LABEL, label, sizeof(label)-1}, 798 {CKA_ENCRYPT, &true, sizeof(true)}, 799 {CKA_VALUE, value, sizeof(value} 800 }; 801 CKA_CHECK_VALUE: The value of this attribute is derived from the key object by taking the first three 802 bytes of the ECB encryption of a single block of null (0x00) bytes, using the default cipher associated with 803 the key type of the secret key object.

804 2.7.3 CAST secret key objects 805 CAST secret key objects (object class CKO_SECRET_KEY, key type CKK_CAST) hold CAST keys. 806 The following table defines the CAST secret key object attributes, in addition to the common attributes 807 defined for this object class:

Attribute Data type Meaning

CKA_VALUE1,4,6,7 Byte array Key value (1 to 8 bytes)

CKA_VALUE_LEN2,3,6 CK_ULONG Length in bytes of key value 809 Refer to [PKCS #11-Base] table 11 for footnotes 810 811 The following is a sample template for creating a CAST secret key object: 812 CK_OBJECT_CLASS class = CKO_SECRET_KEY; 813 CK_KEY_TYPE keyType = CKK_CAST; 814 CK_UTF8CHAR label[] = “A CAST secret key object”; 815 CK_BYTE value[] = {…}; 816 CK_BBOOL true = CK_TRUE; 817 CK_ATTRIBUTE template[] = { 818 {CKA_CLASS, &class, sizeof(class)}, 819 {CKA_KEY_TYPE, &keyType, sizeof(keyType)}, 820 {CKA_TOKEN, &true, sizeof(true)}, 821 {CKA_LABEL, label, sizeof(label)-1}, 822 {CKA_ENCRYPT, &true, sizeof(true)}, 823 {CKA_VALUE, value, sizeof(value)} 824 };

825 2.7.4 CAST3 secret key objects 826 CAST3 secret key objects (object class CKO_SECRET_KEY, key type CKK_CAST3) hold CAST3 keys. 827 The following table defines the CAST3 secret key object attributes, in addition to the common attributes 828 defines for this object class: 829 Table 22, CAST3 Secret Key Object Attributes

Attribute Data type Meaning

CKA_VALUE1,4,6,7 Byte array Key value (1 to 8 bytes)

CKA_VALUE_LEN2,3,6 CK_ULONG Length in bytes of key value 830 Refer to [PKCS #11-Base] table 11 for footnotes 831 The following is a sample template for creating a CAST3 secret key object: 832 CK_OBJECT_CLASS class = CKO_SECRET_KEY; 833 CK_KEY_TYPE keyType = CKK_CAST3; 834 CK_UTF8CHAR label[] = “A CAST3 secret key object”; 835 CK_BYTE value[] = {…}; 836 CK_BBOOL true = CK_TRUE; 837 CK_ATTRIBUTE template[] = { 838 {CKA_CLASS, &class, sizeof(class)}, 839 {CKA_KEY_TYPE, &keyType, sizeof(keyType)}, 840 {CKA_TOKEN, &true, sizeof(true)}, 841 {CKA_LABEL, label, sizeof(label)-1}, 842 {CKA_ENCRYPT, &true, sizeof(true)}, 843 {CKA_VALUE, value, sizeof(value)} 844 };

845 2.7.5 CAST128 secret key objects 846 CAST128 secret key objects (object class CKO_SECRET_KEY, key type CKK_CAST128) hold 847 CAST128 keys. The following table defines the CAST128 secret key object attributes, in addition to the 848 common attributes defines for this object class: pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 32 of 64 849 Table 23, CAST128 Secret Key Object Attributes

Attribute Data type Meaning

CKA_VALUE1,4,6,7 Byte array Key value (1 to 16 bytes)

CKA_VALUE_LEN2,3,6 CK_ULONG Length in bytes of key value 850 Refer to [PKCS #11-Base] table 11 for footnotes 851 The following is a sample template for creating a CAST128 secret key object: 852 CK_OBJECT_CLASS class = CKO_SECRET_KEY; 853 CK_KEY_TYPE keyType = CKK_CAST128; 854 CK_UTF8CHAR label[] = “A CAST128 secret key object”; 855 CK_BYTE value[] = {…}; 856 CK_BBOOL true = CK_TRUE; 857 CK_ATTRIBUTE template[] = { 858 {CKA_CLASS, &class, sizeof(class)}, 859 {CKA_KEY_TYPE, &keyType, sizeof(keyType)}, 860 {CKA_TOKEN, &true, sizeof(true)}, 861 {CKA_LABEL, label, sizeof(label)-1}, 862 {CKA_ENCRYPT, &true, sizeof(true)}, 863 {CKA_VALUE, value, sizeof(value)} 864 };

865 2.7.6 IDEA secret key objects 866 IDEA secret key objects (object class CKO_SECRET_KEY, key type CKK_IDEA) hold IDEA keys. The following 867 table defines the IDEA secret key object attributes, in addition to the common attributes defines for this object class: 868 Table 24, IDEA Secret Key Object

Attribute Data type Meaning

CKA_VALUE1,4,6,7 Byte array Key value (16 bytes long)

869 Refer to [PKCS #11-Base] table 11 for footnotes 870 The following is a sample template for creating an IDEA secret key object: 871 CK_OBJECT_CLASS class = CKO_SECRET_KEY; 872 CK_KEY_TYPE keyType = CKK_IDEA; 873 CK_UTF8CHAR label[] = “An IDEA secret key object”; 874 CK_BYTE value[16] = {…}; 875 CK_BBOOL true = CK_TRUE; 876 CK_ATTRIBUTE template[] = { 877 {CKA_CLASS, &class, sizeof(class)}, 878 {CKA_KEY_TYPE, &keyType, sizeof(keyType)}, 879 {CKA_TOKEN, &true, sizeof(true)}, 880 {CKA_LABEL, label, sizeof(label)-1}, 881 {CKA_ENCRYPT, &true, sizeof(true)}, 882 {CKA_VALUE, value, sizeof(value)} 883 };

884 2.7.7 CDMF secret key objects 885 IDEA secret key objects (object class CKO_SECRET_KEY, key type CKK_CDMF) hold CDMF keys. The following 886 table defines the CDMF secret key object attributes, in addition to the common attributes defines for this object class: 887 Table 25, CDMF Secret Key Object

Attribute Data type Meaning CKA_VALUE1,4,6,7 Byte array Key value (8 bytes long)

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 33 of 64 888 Refer to [PKCS #11-Base] table 11 for footnotes 889 CDMF keys MUST have their parity bits properly set in exactly the same fashion described for DES keys 890 in FIPS PUB 46-3. Attempting to create or unwrap a CDMF key with incorrect parity MUST return an 891 error. 892 The following is a sample template for creating a CDMF secret key object: 893 CK_OBJECT_CLASS class = CKO_SECRET_KEY; 894 CK_KEY_TYPE keyType = CKK_CDMF; 895 CK_UTF8CHAR label[] = “A CDMF secret key object”; 896 CK_BYTE value[8] = {…}; 897 CK_BBOOL true = CK_TRUE; 898 CK_ATTRIBUTE template[] = { 899 {CKA_CLASS, &class, sizeof(class)}, 900 {CKA_KEY_TYPE, &keyType, sizeof(keyType)}, 901 {CKA_TOKEN, &true, sizeof(true)}, 902 {CKA_LABEL, label, sizeof(label)-1}, 903 {CKA_ENCRYPT, &true, sizeof(true)}, 904 {CKA_VALUE, value, sizeof(value)} 905 };

906 2.7.8 General block cipher mechanism parameters

907 2.7.8.1 CK_MAC_GENERAL_PARAMS; CK_MAC_GENERAL_PARAMS_PTR 908 CK_MAC_GENERAL_PARAMS provides the parameters to the general-length MACing mechanisms of 909 the DES, DES3 (triple-DES), CAST, CAST3, CAST128, IDEA, CDMF and AES ciphers. It also provides 910 the parameters to the general-length HMACing mechanisms (i.e., MD2, MD5, SHA-1, SHA-256, SHA- 911 384, SHA-512, RIPEMD-128 and RIPEMD-160) and the two SSL 3.0 MACing mechanisms, (i.e., MD5 912 and SHA-1). It holds the length of the MAC that these mechanisms produce. It is defined as follows: 913 typedef CK_ULONG CK_MAC_GENERAL_PARAMS; 914 915 CK_MAC_GENERAL_PARAMS_PTR is a pointer to a CK_MAC_GENERAL_PARAMS.

916 2.7.9 General block cipher key generation 917 Cipher has a key generation mechanism, “ key generation”, denoted by 918 CKM__KEY_GEN. 919 This mechanism does not have a parameter. 920 The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new 921 key. Other attributes supported by the key type (specifically, the flags indicating which functions the key 922 supports) MAY be specified in the template for the key, or else are assigned default initial values. 923 When DES keys or CDMF keys are generated, their parity bits are set properly, as specified in FIPS PUB 924 46-3. Similarly, when a triple-DES key is generated, each of the DES keys comprising it has its parity bits 925 set properly. 926 When DES or CDMF keys are generated, it is token-dependent whether or not it is possible for “weak” or 927 “semi-weak” keys to be generated. Similarly, when triple-DES keys are generated, it is token-dependent 928 whether or not it is possible for any of the component DES keys to be “weak” or “semi-weak” keys. 929 When CAST, CAST3, or CAST128 keys are generated, the template for the secret key must specify a 930 CKA_VALUE_LEN attribute. 931 For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 932 MAY be used. The CAST, CAST3, and CAST128 ciphers have variable key sizes, and so for the key 933 generation mechanisms for these ciphers, the ulMinKeySize and ulMaxKeySize fields of the 934 CK_MECHANISM_INFO structure specify the supported range of key sizes, in bytes. For the DES, 935 DES3 (triple-DES), IDEA and CDMF ciphers, these fields and not used.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 34 of 64 936 2.7.10 General block cipher ECB 937 Cipher has an electronic codebook mechanism, “-ECB”, denoted 938 CKM__ECB. It is a mechanism for single- and multiple-part encryption and decryption; key 939 wrapping; and key unwrapping with . 940 It does not have a parameter. 941 This mechanism MAY wrap and unwrap any secret key. Of course, a particular token MAY not be able to 942 wrap/unwrap every secret key that it supports. For wrapping, the mechanism encrypts the value of the 943 CKA_VALUE attribute of the key that is wrapped, padded on the trailing end with null bytes so that the 944 resulting length is a multiple of ’s blocksize. The output data is the same length as the padded 945 input data. It does not wrap the key type, key length or any other information about the key; the 946 application must convey these separately. 947 For unwrapping, the mechanism decrypts the wrapped key, and truncates the result according to the 948 CKA_KEY_TYPE attribute of the template and, if it has one, and the key type supports it, the 949 CKA_VALUE_LEN attribute of the template. The mechanism contributes the result as the CKA_VALUE 950 attribute of the new key; other attributes required by the key must be specified in the template. 951 Constraints on key types and the length of data are summarized in the following table: 952 Table 26, General Block Cipher ECB: Key and Data Length

Function Key Input length Output length Comments type C_Encrypt Multiple of Same as input length No final blocksize part

C_Decrypt Multiple of Same as input length No final blocksize part C_WrapKey Any Input length rounded up to multiple of blocksize

C_UnwrapKey Any Determined by type of key being unwrapped or CKA_VALUE_LEN 953 For this mechanism, the ulMinKeySize and ulMaxKeySIze fields of the CK_MECHANISM_INFO structure 954 MAY be used. The CAST, CAST3, and CAST128 ciphers have variable key sizes, and so for these 955 ciphers, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the 956 supported range of key sizes, in bytes. For the DES, DES3 (triple-DES), IDEA and CDMF ciphers, these 957 fields are not used.

958 2.7.11 General block cipher CBC 959 Cipher has a cipher-block chaining mode, “-CBC”, denoted CKM__CBC. It is 960 a mechanism for single- and multiple-part encryption and decryption; key wrapping; and key unwrapping 961 with . 962 It has a parameter, an initialization vector for cipher block chaining mode. The initialization vector has the 963 same length as ’s blocksize. 964 Constraints on key types and the length of data are summarized in the following table: 965 Table 27, General Block Cipher CBC; Key and Data Length

Function Key Input length Output length Comments type

C_Encrypt Multiple of Same as input length No final blocksize part

C_WrapKey Any Input length rounded up to multiple of blocksize C_UnwrapKey Any Determined by type of key being unwrapped or CKA_VALUE_LEN

966 For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 967 MAY be used. The CAST, CAST3, and CAST128 ciphers have variable key sizes, and so for these 968 ciphers, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the 969 supported range of key sizes, in bytes. For the DES, DES3 (triple-DES), IDEA, and CDMF ciphers, these 970 fields are not used.

971 2.7.12 General block cipher CBC with PCKS padding 972 Cipher has a cipher-block chaining mode with PKCS padding, “-CBC with PKCS 973 padding”, denoted CKM__CBC_PAD. It is a mechanism for single- and multiple-part encryption 974 and decryption; key wrapping; and key unwrapping with . All ciphertext is padded with PKCS 975 padding. 976 It has a parameter, an initialization vector for cipher block chaining mode. The initialization vector has the 977 same length as ’s blocksize. 978 The PKCS padding in this mechanism allows the length of the plaintext value to be recovered from the 979 ciphertext value. Therefore, when unwrapping keys with this mechanism, no value should be specified 980 for the CKA_VALUE_LEN attribute. 981 982 In addition to being able to wrap and unwrap secret keys, this mechanism MAY wrap and unwrap RSA, 983 Diffie-Hellman, X9.42 Diffie-Hellman, EC (also related to ECDSA) and DSA private keys. The entries in 984 the table below for data length constraints when wrapping and unwrapping keys to not apply to wrapping 985 and unwrapping private keys. 986 Constraints on key types and the length of data are summarized in the following table: 987 Table 28, General Block Cipher CBC with PKCS Padding: Key and Data Length

Function Key Input length Output length type

C_Encrypt Any Input length rounded up to multiple of blocksize C_Decrypt Multiple of Between 1 and blocksize bytes shorter than input blocksize length

C_WrapKey Any Input length rounded up to multiple of blocksize C_UnwrapKey Multiple of Between 1 and blocksize bytes shorter than input blocksize length 988 For this mechanism, the ulMinKeySIze and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 989 MAY be used. The CAST, CAST3 and CAST128 ciphers have variable key sizes, and so for these 990 ciphers, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the 991 supported range of key sizes, in bytes. For the DES, DES3 (triple-DES), IDEA, and CDMF ciphers, these 992 fields are not used.

993 2.7.13 General-length general block cipher MAC 994 Cipher has a general-length MACing mode, “General-length -MAC”, denoted 995 CKM__MAC_GENERAL. It is a mechanism for single-and multiple-part signatures and

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 36 of 64 996 verification, based on the encryption algorithm and data authentication as defined in FIPS PUB 997 113. 998 It has a parameter, a CK_MAC_GENERAL_PARAMS, which specifies the size of the output. 999 The output bytes from this mechanism are taken from the start of the final cipher block produced in the 1000 MACing process. 1001 Constraints on key types and the length of input and output data are summarized in the following table: 1002 Table 29, General-length General Block Cipher MAC: Key and Data Length

Function Key type Data length Signature length

C_Sign Any 0-blocksize, depending on parameters

C_Verify Any 0-blocksize, depending on parameters 1003 For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 1004 MAY be used. The CAST, CAST3, and CAST128 ciphers have variable key sizes, and so for these 1005 ciphers, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the 1006 supported range of key sizes, in bytes. For the DES, DES3 (triple-DES), IDEA and CDMF ciphers, these 1007 fields are not used.

1008 2.7.14 General block cipher MAC 1009 Cipher has a MACing mechanism, “-MAC”, denoted CKM__MAC. This 1010 mechanism is a special case of the CKM__MAC_GENERAL mechanism described above. It 1011 produces an output of size half as large as ’s blocksize. 1012 This mechanism has no parameters. 1013 Constraints on key types and the length of data are summarized in the following table: 1014 Table 30, General Block cipher MAC: Key and Data Length

Function Key type Data length Signature length C_Sign Any [blocksize/2]

C_Verify Any [blocksize/2]

1015 For this mechanism, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure 1016 MAY be used. The CAST, CAST3, and CAST128 ciphers have variable key sizes, and so for these 1017 ciphers, the ulMinKeySize and ulMaxKeySize fields of the CK_MECHANISM_INFO structure specify the 1018 supported range of key sizes, in bytes. For the DES, DES3 (triple-DES), IDEA and CDMF ciphers, these 1019 fields are not used.

1020 2.8 SKIPJACK

1021 2.8.1 Definitions 1022 This section defines the key type “CKK_SKIPJACK” for type CK_KEY_TYPE as used in the 1023 CKA_KEY_TYPE attribute of key objects. 1024 Mechanisms: 1025 CKM_SKIPJACK_KEY_GEN 1026 CKM_SKIPJACK_ECB64 1027 CKM_SKIPJACK_CBC64 1028 CKM_SKIPJACK_OFB64 1029 CKM_SKIPJACK_CFB64

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 37 of 64 1030 CKM_SKIPJACK_CFB32 1031 CKM_SKIPJACK_CFB16 1032 CKM_SKIPJACK_CFB8 1033 CKM_SKIPJACK_WRAP 1034 CKM_SKIPJACK_PRIVATE_WRAP 1035 CKM_SKIPJACK_RELAYX

1036 2.8.2 SKIPJACK secret key objects 1037 SKIPJACK secret key objects (object class CKO_SECRET_KEY, key type CKK_SKIPJACK) holds a 1038 single-length MEK or a TEK. The following table defines the SKIPJACK secret object attributes, in 1039 addition to the common attributes defined for this object class: 1040 Table 31, SKIPJACK Secret Key Object

Attribute Data type Meaning

CKA_VALUE1,4,6,7 Byte array Key value (12 bytes long) 1041 Refer to [PKCS #11-Base] table 11 for footnotes 1042 1043 SKIPJACK keys have 16 checksum bits, and these bits must be properly set. Attempting to create or 1044 unwrap a SKIPJACK key with incorrect checksum bits MUST return an error. 1045 It is not clear that any tokens exist (or ever will exist) which permit an application to create a SKIPJACK 1046 key with a specified value. Nonetheless, we provide templates for doing so. 1047 The following is a sample template for creating a SKIPJACK MEK secret key object: 1048 CK_OBJECT_CLASS class = CKO_SECRET_KEY; 1049 CK_KEY_TYPE keyType = CKK_SKIPJACK; 1050 CK_UTF8CHAR label[] = “A SKIPJACK MEK secret key object”; 1051 CK_BYTE value[12] = {…}; 1052 CK_BBOOL true = CK_TRUE; 1053 CK_ATTRIBUTE template[] = { 1054 {CKA_CLASS, &class, sizeof(class)}, 1055 {CKA_KEY_TYPE, &keyType, sizeof(keyType)}, 1056 {CKA_TOKEN, &true, sizeof(true)}, 1057 {CKA_LABEL, label, sizeof(label)-1}, 1058 {CKA_ENCRYPT, &true, sizeof(true)}, 1059 {CKA_VALUE, value, sizeof(value)} 1060 }; 1061 The following is a sample template for creating a SKIPJACK TEK secret key object: 1062 CK_OBJECT_CLASS class = CKO_SECRET_KEY; 1063 CK_KEY_TYPE keyType = CKK_SKIPJACK; 1064 CK_UTF8CHAR label[] = “A SKIPJACK TEK secret key object”; 1065 CK_BYTE value[12] = {…}; 1066 CK_BBOOL true = CK_TRUE; 1067 CK_ATTRIBUTE template[] = { 1068 {CKA_CLASS, &class, sizeof(class)}, 1069 {CKA_KEY_TYPE, &keyType, sizeof(keyType)}, 1070 {CKA_TOKEN, &true, sizeof(true)}, 1071 {CKA_LABEL, label, sizeof(label)-1}, 1072 {CKA_ENCRYPT, &true, sizeof(true)}, 1073 {CKA_WRAP, &true, sizeof(true)}, 1074 {CKA_VALUE, value, sizeof(value)} 1075 };

1077 2.8.3.1 CK_SKIPJACK_PRIVATE_WRAP_PARAMS; 1078 CK_SKIPJACK_PRIVATE_WRAP_PARAMS_PTR 1079 CK_SKIPJACK_PRIVATE_WRAP_PARAMS is a structure that provides the parameters to the 1080 CKM_SKIPJACK_PRIVATE_WRAP mechanism. It is defined as follows: 1081 typedef struct CK_SKIPJACK_PRIVATE_WRAP_PARAMS { 1082 CK_ULONG ulPasswordLen; 1083 CK_BYTE_PTR pPassword; 1084 CK_ULONG ulPublicDataLen; 1085 CK_BYTE_PTR pPublicData; 1086 CK_ULONG ulPandGLen; 1087 CK_ULONG ulQLen; 1088 CK_ULONG ulRandomLen; 1089 CK_BYTE_PTR pRandomA; 1090 CK_BYTE_PTR pPrimeP; 1091 CK_BYTE_PTR pBaseG; 1092 CK_BYTE_PTR pSubprimeQ; 1093 } CK_SKIPJACK_PRIVATE_WRAP_PARAMS; 1094 The fields of the structure have the following meanings: 1095 ulPasswordLen length of the password

1096 pPassword pointer to the buffer which contains the user-supplied 1097 password

1098 ulPublicDataLen other party’s key exchange public key size

1099 pPublicData pointer to other party’s key exchange public key value

1100 ulPandGLen length of prime and base values

1101 ulQLen length of subprime value

1102 ulRandomLen size of random Ra, in bytes

1103 pPrimeP pointer to Prime, p, value

1104 pBaseG pointer to Base, b, value

1105 pSubprimeQ pointer to Subprime, q, value

1106 CK_SKIPJACK_PRIVATE_WRAP_PARAMS_PTR is a pointer to a 1107 CK_PRIVATE_WRAP_PARAMS.

1108 2.8.3.2 CK_SKIPJACK_RELAYX_PARAMS; 1109 CK_SKIPJACK_RELAYX_PARAMS_PTR 1110 CK_SKIPJACK_RELAYX_PARAMS is a structure that provides the parameters to the 1111 CKM_SKIPJACK_RELAYX mechanism. It is defined as follows: 1112 typedef struct CK_SKIPJACK_RELAYX_PARAMS { 1113 CK_ULONG ulOldWrappedXLen; 1114 CK_BYTE_PTR pOldWrappedX;

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 39 of 64 1115 CK_ULONG ulOldPasswordLen; 1116 CK_BYTE_PTR pOldPassword; 1117 CK_ULONG ulOldPublicDataLen; 1118 CK_BYTE_PTR pOldPublicData; 1119 CK_ULONG ulOldRandomLen; 1120 CK_BYTE_PTR pOldRandomA; 1121 CK_ULONG ulNewPasswordLen; 1122 CK_BYTE_PTR pNewPassword; 1123 CK_ULONG ulNewPublicDataLen; 1124 CK_BYTE_PTR pNewPublicData; 1125 CK_ULONG ulNewRandomLen; 1126 CK_BYTE_PTR pNewRandomA; 1127 } CK_SKIPJACK_RELAYX_PARAMS; 1128 The fields of the structure have the following meanings: 1129 ulOldWrappedLen length of old wrapped key in bytes

1130 pOldWrappedX pointer to old wrapper key

1131 ulOldPasswordLen length of the old password

1132 pOldPassword pointer to the buffer which contains the old user-supplied 1133 password

1134 ulOldPublicDataLen old key exchange public key size

1135 pOldPublicData pointer to old key exchange public key value

1136 ulOldRandomLen size of old random Ra in bytes

1137 pOldRandomA pointer to old Ra data

1138 ulNewPasswordLen length of the new password

1139 pNewPassword pointer to the buffer which contains the new user- 1140 supplied password

1141 ulNewPublicDataLen new key exchange public key size

1142 pNewPublicData pointer to new key exchange public key value

1143 ulNewRandomLen size of new random Ra in bytes

1144 pNewRandomA pointer to new Ra data

1145 CK_SKIPJACK_RELAYX_PARAMS_PTR is a pointer to a CK_SKIPJACK_RELAYX_PARAMS.

1146 2.8.4 SKIPJACK key generation 1147 The SKIPJACK key generation mechanism, denoted CKM_SKIPJACK_KEY_GEN, is a key generation 1148 mechanism for SKIPJACK. The output of this mechanism is called a Message Encryption Key (MEK). 1149 It does not have a parameter. 1150 The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new 1151 key.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 40 of 64 1152 2.8.5 SKIPJACK-ECB64 1153 SKIPJACK-ECB64, denoted CKM_SKIPJACK_ECB64, is a mechanism for single- and multiple-part 1154 encryption and decryption with SKIPJACK in 64-bit electronic codebook mode as defined in FIPS PUB 1155 185. 1156 It has a parameter, a 24-byte initialization vector. During an encryption operation, this IV is set to some 1157 value generated by the token – in other words, the application cant specify a particular IV when 1158 encrypting. It MAY, of course, specify a particular IV when decrypting. 1159 Constraints on key types and the length of data are summarized in the following table: 1160 Table 32, SKIPJACK-ECB64: Data and Length

Function Key type Input length Output length Comments

C_Encrypt SKIPJACK Multiple of 8 Same as input length No final part

C_Decrypt SKIPJACK Multiple of 8 Same as input length No final part

1161 2.8.6 SKIPJACK-CBC64 1162 SKIPJACK-CBC64, denoted CKM_SKIPJACK_CBC64, is a mechanism for single- and multiple-part 1163 encryption and decryption with SKIPJACK in 64-bit output feedback mode as defined in FIPS PUB 185. 1164 It has a parameter, a 24-byte initialization vector. During an encryption operation, this IV is set to some 1165 value generated by the token – in other words, the application MAY NOT specify a particular IV when 1166 encrypting. It MAY, of course, specify a particular IV when decrypting. 1167 Constraints on key types and the length of data are summarized in the following table: 1168 Table 33, SKIPJACK-CBC64: Data and Length

Function Key type Input length Output length Comments

C_Encrypt SKIPJACK Multiple of 8 Same as input length No final part C_Decrypt SKIPJACK Multiple of 8 Same as input length No final part

1169 2.8.7 SKIPJACK-OFB64 1170 SKIPJACK-OFB64, denoted CKM_SKIPJACK_OFB64, is a mechanism for single- and multiple-part 1171 encryption and decryption with SKIPJACK in 64-bit output feedback mode as defined in FIPS PUB 185. 1172 It has a parameter, a 24-byte initialization vector. During an encryption operation, this IV is set to some 1173 value generated by the token – in other words, the application MAY NOT specify a particular IV when 1174 encrypting. It MAY, of course, specify a particular IV when decrypting. 1175 Constraints on key types and the length of data are summarized in the following table: 1176 Table 34, SKIPJACK-OFB64: Data and Length

Function Key type Input length Output length Comments

C_Encrypt SKIPJACK Multiple of 8 Same as input length No final part

C_Decrypt SKIPJACK Multiple of 8 Same as input length No final part

1177 2.8.8 SKIPJACK-CFB64 1178 SKIPJACK-CFB64, denoted CKM_SKIPJACK_CFB64, is a mechanism for single- and multiple-part 1179 encryption and decryption with SKIPJACK in 64-bit cipher feedback mode as defined in FIPS PUB 185.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 41 of 64 1180 It has a parameter, a 24-byte initialization vector. During an encryption operation, this IV is set to some 1181 value generated by the token – in other words, the application MAY NOT specify a particular IV when 1182 encrypting. It MAY, of course, specify a particular IV when decrypting. 1183 Constraints on key types and the length of data are summarized in the following table: 1184 Table 35, SKIPJACK-CFB64: Data and Length

Function Key type Input length Output length Comments

C_Encrypt SKIPJACK Multiple of 8 Same as input length No final part C_Decrypt SKIPJACK Multiple of 8 Same as input length No final part

1185 2.8.9 SKIPJACK-CFB32 1186 SKIPJACK-CFB32, denoted CKM_SKIPJACK_CFB32, is a mechanism for single- and multiple-part 1187 encryption and decryption with SKIPJACK in 32-bit cipher feedback mode as defined in FIPS PUB 185. 1188 It has a parameter, a 24-byte initialization vector. During an encryption operation, this IV is set to some 1189 value generated by the token – in other words, the application MAY NOT specify a particular IV when 1190 encrypting. It MAY, of course, specify a particular IV when decrypting. 1191 Constraints on key types and the length of data are summarized in the following table: 1192 Table 36, SKIPJACK-CFB32: Data and Length

Function Key type Input length Output length Comments C_Encrypt SKIPJACK Multiple of 4 Same as input length No final part

C_Decrypt SKIPJACK Multiple of 4 Same as input length No final part

1193 2.8.10 SKIPJACK-CFB16 1194 SKIPJACK-CFB16, denoted CKM_SKIPJACK_CFB16, is a mechanism for single- and multiple-part 1195 encryption and decryption with SKIPJACK in 16-bit cipher feedback mode as defined in FIPS PUB 185. 1196 It has a parameter, a 24-byte initialization vector. During an encryption operation, this IV is set to some 1197 value generated by the token – in other words, the application MAY NOT specify a particular IV when 1198 encrypting. It MAY, of course, specify a particular IV when decrypting. 1199 Constraints on key types and the length of data are summarized in the following table: 1200 Table 37, SKIPJACK-CFB16: Data and Length

Function Key type Input length Output length Comments

C_Encrypt SKIPJACK Multiple of 4 Same as input length No final part

C_Decrypt SKIPJACK Multiple of 4 Same as input length No final part

1201 2.8.11 SKIPJACK-CFB8 1202 SKIPJACK-CFB8, denoted CKM_SKIPJACK_CFB8, is a mechanism for single- and multiple-part 1203 encryption and decryption with SKIPJACK in 8-bit cipher feedback mode as defined in FIPS PUB 185. 1204 It has a parameter, a 24-byte initialization vector. During an encryption operation, this IV is set to some 1205 value generated by the token – in other words, the application MAY NOT specify a particular IV when 1206 encrypting. It MAY, of course, specify a particular IV when decrypting. 1207 Constraints on key types and the length of data are summarized in the following table:

Function Key type Input length Output length Comments

C_Encrypt SKIPJACK Multiple of 4 Same as input length No final part

C_Decrypt SKIPJACK Multiple of 4 Same as input length No final part

1209 2.8.12 SKIPJACK-WRAP 1210 The SKIPJACK-WRAP mechanism, denoted CKM_SKIPJACK_WRAP, is used to wrap and unwrap a 1211 secret key (MEK). It MAY wrap or unwrap SKIPJACK, BATON, and JUNIPER keys. 1212 It does not have a parameter.

1213 2.8.13 SKIPJACK-PRIVATE-WRAP 1214 The SKIPJACK-PRIVATE-WRAP mechanism, denoted CKM_SKIPJACK_PRIVATE_WRAP, is used to 1215 wrap and unwrap a private key. It MAY wrap KEA and DSA private keys. 1216 It has a parameter, a CK_SKIPJACK_PRIVATE_WRAP_PARAMS structure.

1217 2.8.14 SKIPJACK-RELAYX 1218 The SKIPJACK-RELAYX mechanism, denoted CKM_SKIPJACK_RELAYX, is used with the C_WrapKey 1219 function to “change the wrapping” on a private key which was wrapped with the SKIPJACK-PRIVATE- 1220 WRAP mechanism (See Section 2.8.13). 1221 It has a parameter, a CK_SKIPJACK_RELAYX_PARAMS structure. 1222 Although the SKIPJACK-RELAYX mechanism is used with C_WrapKey, it differs from other key- 1223 wrapping mechanisms. Other key-wrapping mechanisms take a key handle as one of the arguments to 1224 C_WrapKey; however for the SKIPJACK_RELAYX mechanism, the [always invalid] value 0 should be 1225 passed as the key handle for C_WrapKey, and the already-wrapped key should be passed in as part of 1226 the CK_SKIPJACK_RELAYX_PARAMS structure.

1227 2.9 BATON

1228 2.9.1 Definitions 1229 This section defines the key type “CKK_BATON” for type CK_KEY_TYPE as used in the 1230 CKA_KEY_TYPE attribute of key objects. 1231 Mechanisms: 1232 CKM_BATON_KEY_GEN 1233 CKM_BATON_ECB128 1234 CKM_BATON_ECB96 1235 CKM_BATON_CBC128 1236 CKM_BATON_COUNTER 1237 CKM_BATON_SHUFFLE 1238 CKM_BATON_WRAP

1239 2.9.2 BATON secret key objects 1240 BATON secret key objects (object class CKO_SECRET_KEY, key type CKK_BATON) hold single-length 1241 BATON keys. The following table defines the BATON secret key object attributes, in addition to the 1242 common attributes defined for this object class:

Attribute Data type Meaning CKA_VALUE1,4,6,7 Byte array Key value (40 bytes long) 1244 Refer to [PKCS #11-Base] table 11 for footnotes 1245 1246 BATON keys have 160 checksum bits, and these bits must be properly set. Attempting to create or 1247 unwrap a BATON key with incorrect checksum bits MUST return an error. 1248 It is not clear that any tokens exist (or will ever exist) which permit an application to create a BATON key 1249 with a specified value. Nonetheless, we provide templates for doing so. 1250 The following is a sample template for creating a BATON MEK secret key object: 1251 CK_OBJECT_CLASS class = CKO_SECRET_KEY; 1252 CK_KEY_TYPE keyType = CKK_BATON; 1253 CK_UTF8CHAR label[] = “A BATON MEK secret key object”; 1254 CK_BYTE value[40] = {…}; 1255 CK_BBOOL true = CK_TRUE; 1256 CK_ATTRIBUTE template[] = { 1257 {CKA_CLASS, &class, sizeof(class)}, 1258 {CKA_KEY_TYPE, &keyType, sizeof(keyType)}, 1259 {CKA_TOKEN, &true, sizeof(true)}, 1260 {CKA_LABEL, label, sizeof(label)-1}, 1261 {CKA_ENCRYPT, &true, sizeof(true)}, 1262 {CKA_VALUE, value, sizeof(value)} 1263 }; 1264 The following is a sample template for creating a BATON TEK secret key object: 1265 CK_OBJECT_CLASS class = CKO_SECRET_KEY; 1266 CK_KEY_TYPE keyType = CKK_BATON; 1267 CK_UTF8CHAR label[] = “A BATON TEK secret key object”; 1268 CK_BYTE value[40] = {…}; 1269 CK_BBOOL true = CK_TRUE; 1270 CK_ATTRIBUTE template[] = { 1271 {CKA_CLASS, &class, sizeof(class)}, 1272 {CKA_KEY_TYPE, &keyType, sizeof(keyType)}, 1273 {CKA_TOKEN, &true, sizeof(true)}, 1274 {CKA_LABEL, label, sizeof(label)-1}, 1275 {CKA_ENCRYPT, &true, sizeof(true)}, 1276 {CKA_WRAP, &true, sizeof(true)}, 1277 {CKA_VALUE, value, sizeof(value)} 1278 };

1279 2.9.3 BATON key generation 1280 The BATON key generation mechanism, denoted CKM_BATON_KEY_GEN, is a key generation 1281 mechanism for BATON. The output of this mechanism is called a Message Encryption Key (MEK). 1282 It does not have a parameter. 1283 The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new 1284 key.

1285 2.9.4 BATON-ECB128 1286 BATON-ECB128, denoted CKM_BATON_ECB128, is a mechanism for single- and multiple-part 1287 encryption and decryption with BATON in 128-bit electronic codebook mode.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 44 of 64 1288 It has a parameter, a 24-byte initialization vector. During an encryption operation, this IV is set to some 1289 value generated by the token – in other words, the application MAY NOT specify a particular IV when 1290 encrypting. It MAY, of course, specify a particular IV when decrypting. 1291 Constraints on key types and the length of data are summarized in the following table: 1292 Table 40, BATON-ECB128: Data and Length

Function Key type Input length Output length Comments

C_Encrypt BATON Multiple of 16 Same as input length No final part C_Decrypt BATON Multiple of 16 Same as input length No final part

1293 2.9.5 BATON-ECB96 1294 BATON-ECB96, denoted CKM_BATON_ECB96, is a mechanism for single- and multiple-part encryption 1295 and decryption with BATON in 96-bit electronic codebook mode. 1296 It has a parameter, a 24-byte initialization vector. During an encryption operation, this IV is set to some 1297 value generated by the token – in other words, the application MAY NOT specify a particular IV when 1298 encrypting. It MAY, of course, specify a particular IV when decrypting. 1299 Constraints on key types and the length of data are summarized in the following table: 1300 Table 41, BATON-ECB96: Data and Length

Function Key type Input length Output length Comments C_Encrypt BATON Multiple of 12 Same as input length No final part

C_Decrypt BATON Multiple of 12 Same as input length No final part

1301 2.9.6 BATON-CBC128 1302 BATON-CBC128, denoted CKM_BATON_CBC128, is a mechanism for single- and multiple-part 1303 encryption and decryption with BATON in 128-bit cipher-block chaining mode. 1304 It has a parameter, a 24-byte initialization vector. During an encryption operation, this IV is set to some 1305 value generated by the token – in other words, the application MAY NOT specify a particular IV when 1306 encrypting. It MAY, of course, specify a particular IV when decrypting. 1307 Constraints on key types and the length of data are summarized in the following table: 1308 Table 42, BATON-CBC128

Function Key type Input length Output length Comments

C_Encrypt BATON Multiple of 16 Same as input length No final part

C_Decrypt BATON Multiple of 16 Same as input length No final part

1309 2.9.7 BATON-COUNTER 1310 BATON-COUNTER, denoted CKM_BATON_COUNTER, is a mechanism for single- and multiple-part 1311 encryption and decryption with BATON in counter mode. 1312 It has a parameter, a 24-byte initialization vector. During an encryption operation, this IV is set to some 1313 value generated by the token – in other words, the application MAY NOT specify a particular IV when 1314 encrypting. It MAY, of course, specify a particular IV when decrypting. 1315 Constraints on key types and the length of data are summarized in the following table:

Function Key type Input length Output length Comments

C_Encrypt BATON Multiple of 16 Same as input length No final part

C_Decrypt BATON Multiple of 16 Same as input length No final part

1317 2.9.8 BATON-SHUFFLE 1318 BATON-SHUFFLE, denoted CKM_BATON_SHUFFLE, is a mechanism for single- and multiple-part 1319 encryption and decryption with BATON in shuffle mode. 1320 It has a parameter, a 24-byte initialization vector. During an encryption operation, this IV is set to some 1321 value generated by the token – in other words, the application MAY NOT specify a particular IV when 1322 encrypting. It MAY, of course, specify a particular IV when decrypting. 1323 Constraints on key types and the length of data are summarized in the following table: 1324 Table 44, BATON-SHUFFLE: Data and Length

Function Key type Input length Output length Comments

C_Encrypt BATON Multiple of 16 Same as input length No final part C_Decrypt BATON Multiple of 16 Same as input length No final part

1325 2.9.9 BATON WRAP 1326 The BATON wrap and unwrap mechanism, denoted CKM_BATON_WRAP, is a function used to wrap 1327 and unwrap a secret key (MEK). It MAY wrap and unwrap SKIPJACK, BATON and JUNIPER keys. 1328 It has no parameters. 1329 When used to unwrap a key, this mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and 1330 CKA_VALUE attributes to it.

1331 2.10 JUNIPER

1332 2.10.1 Definitions 1333 This section defines the key type “CKK_JUNIPER” for type CK_KEY_TYPE as used in the 1334 CKA_KEY_TYPE attribute of key objects. 1335 Mechanisms: 1336 CKM_JUNIPER_KEY_GEN 1337 CKM_JUNIPER_ECB128 1338 CKM_JUNIPER_CBC128 1339 CKM_JUNIPER_COUNTER 1340 CKM_JUNIPER_SHUFFLE 1341 CKM_JUNIPER_WRAP

1342 2.10.2 JUNIPER secret key objects 1343 JUNIPER secret key objects (object class CKO_SECRET_KEY, key type CKK_JUNIPER) hold single- 1344 length JUNIPER keys. The following table defines the BATON secret key object attributes, in addition to 1345 the common attributes defined for this object class:

Attribute Data type Meaning CKA_VALUE1,4,6,7 Byte array Key value (40 bytes long) 1347 Refer to [PKCS #11-Base] table 11 for footnotes 1348 1349 JUNIPER keys have 160 checksum bits, and these bits must be properly set. Attempting to create or 1350 unwrap a BATON key with incorrect checksum bits MUST return an error. 1351 It is not clear that any tokens exist (or will ever exist) which permit an application to create a BATON key 1352 with a specified value. Nonetheless, we provide templates for doing so. 1353 The following is a sample template for creating a JUNIPER MEK secret key object: 1354 CK_OBJECT_CLASS class = CKO_SECRET_KEY; 1355 CK_KEY_TYPE keyType = CKK_JUNIPER; 1356 CK_UTF8CHAR label[] = “A JUNIPER MEK secret key object”; 1357 CK_BYTE value[40] = {…}; 1358 CK_BBOOL true = CK_TRUE; 1359 CK_ATTRIBUTE template[] = { 1360 {CKA_CLASS, &class, sizeof(class)}, 1361 {CKA_KEY_TYPE, &keyType, sizeof(keyType)}, 1362 {CKA_TOKEN, &true, sizeof(true)}, 1363 {CKA_LABEL, label, sizeof(label)-1}, 1364 {CKA_ENCRYPT, &true, sizeof(true)}, 1365 {CKA_VALUE, value, sizeof(value)} 1366 }; 1367 The following is a sample template for creating a JUNIPER TEK secret key object: 1368 CK_OBJECT_CLASS class = CKO_SECRET_KEY; 1369 CK_KEY_TYPE keyType = CKK_JUNIPER; 1370 CK_UTF8CHAR label[] = “A JUNIPER TEK secret key object”; 1371 CK_BYTE value[40] = {…}; 1372 CK_BBOOL true = CK_TRUE; 1373 CK_ATTRIBUTE template[] = { 1374 {CKA_CLASS, &class, sizeof(class)}, 1375 {CKA_KEY_TYPE, &keyType, sizeof(keyType)}, 1376 {CKA_TOKEN, &true, sizeof(true)}, 1377 {CKA_LABEL, label, sizeof(label)-1}, 1378 {CKA_ENCRYPT, &true, sizeof(true)}, 1379 {CKA_WRAP, &true, sizeof(true)}, 1380 {CKA_VALUE, value, sizeof(value)} 1381 };

1382 2.10.3 JUNIPER key generation 1383 The JUNIPER key generation mechanism, denoted CKM_JUNIPER_KEY_GEN, is a key generation 1384 mechanism for JUNIPER. The output of this mechanism is called a Message Encryption Key (MEK). 1385 It does not have a parameter. 1386 The mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and CKA_VALUE attributes to the new 1387 key.

1388 2.10.4 JUNIPER-ECB128 1389 JUNIPER-ECB128, denoted CKM_JUNIPER_ECB128, is a mechanism for single- and multiple-part 1390 encryption and decryption with JUNIPER in 128-bit electronic codebook mode.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 47 of 64 1391 It has a parameter, a 24-byte initialization vector. During an encryption operation, this IV is set to some 1392 value generated by the token – in other words, the application MAY NOT specify a particular IV when 1393 encrypting. It MAY, of course, specify a particular IV when decrypting. 1394 Constraints on key types and the length of data are summarized in the following table. For encryption 1395 and decryption, the input and output data (parts) MAY begin at the same location in memory. 1396 Table 46, JUNIPER-ECB128: Data and Length

Function Key type Input length Output length Comments

C_Encrypt JUNIPER Multiple of 16 Same as input length No final part C_Decrypt JUNIPER Multiple of 16 Same as input length No final part

1397 2.10.5 JUNIPER-CBC128 1398 JUNIPER-CBC128, denoted CKM_JUNIPER_CBC128, is a mechanism for single- and multiple-part 1399 encryption and decryption with JUNIPER in 128-bit cipher block chaining mode. 1400 It has a parameter, a 24-byte initialization vector. During an encryption operation, this IV is set to some 1401 value generated by the token – in other words, the application MAY NOT specify a particular IV when 1402 encrypting. It MAY, of course, specify a particular IV when decrypting. 1403 Constraints on key types and the length of data are summarized in the following table. For encryption 1404 and decryption, the input and output data (parts) MAY begin at the same location in memory. 1405 Table 47, JUNIPER-CBC128: Data and Length

Function Key type Input length Output length Comments

C_Encrypt JUNIPER Multiple of 16 Same as input length No final part

C_Decrypt JUNIPER Multiple of 16 Same as input length No final part

1406 2.10.6 JUNIPER-COUNTER 1407 JUNIPER-COUNTER, denoted CKM_JUNIPER_COUNTER, is a mechanism for single- and multiple- 1408 part encryption and decryption with JUNIPER in counter mode. 1409 It has a parameter, a 24-byte initialization vector. During an encryption operation, this IV is set to some 1410 value generated by the token – in other words, the application MAY NOT specify a particular IV when 1411 encrypting. It MAY, of course, specify a particular IV when decrypting. 1412 Constraints on key types and the length of data are summarized in the following table. For encryption 1413 and decryption, the input and output data (parts) MAY begin at the same location in memory. 1414 Table 48, JUNIPER-COUNTER: Data and Length

Function Key type Input length Output length Comments C_Encrypt JUNIPER Multiple of 16 Same as input length No final part

C_Decrypt JUNIPER Multiple of 16 Same as input length No final part

1415 2.10.7 JUNIPER-SHUFFLE 1416 JUNIPER-SHUFFLE, denoted CKM_JUNIPER_SHUFFLE, is a mechanism for single- and multiple-part 1417 encryption and decryption with JUNIPER in shuffle mode. 1418 It has a parameter, a 24-byte initialization vector. During an encryption operation, this IV is set to some 1419 value generated by the token – in other words, the application MAY NOT specify a particular IV when 1420 encrypting. It MAY, of course, specify a particular IV when decrypting.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 48 of 64 1421 Constraints on key types and the length of data are summarized in the following table. For encryption 1422 and decryption, the input and output data (parts) MAY begin at the same location in memory. 1423 Table 49, JUNIPER-SHUFFLE: Data and Length

Function Key type Input length Output length Comments

C_Encrypt JUNIPER Multiple of 16 Same as input length No final part C_Decrypt JUNIPER Multiple of 16 Same as input length No final part

1424 2.10.8 JUNIPER WRAP 1425 The JUNIPER wrap and unwrap mechanism, denoted CKM_JUNIPER_WRAP, is a function used to wrap 1426 and unwrap an MEK. It MAY wrap or unwrap SKIPJACK, BATON and JUNIPER keys. 1427 It has no parameters. 1428 When used to unwrap a key, this mechanism contributes the CKA_CLASS, CKA_KEY_TYPE, and 1429 CKA_VALUE attributes to it.

1430 2.11 MD2

1431 2.11.1 Definitions 1432 Mechanisms: 1433 CKM_MD2 1434 CKM_MD2_HMAC 1435 CKM_MD2_HMAC_GENERAL 1436 CKM_MD2_KEY_DERIVATION

1437 2.11.2 MD2 digest 1438 The MD2 mechanism, denoted CKM_MD2, is a mechanism for message digesting, following the MD2 1439 message-digest algorithm defined in RFC 6149. 1440 It does not have a parameter. 1441 Constraints on the length of data are summarized in the following table: 1442 Table 50, MD2: Data Length

Function Data length Digest Length C_Digest Any 16

1443 2.11.3 General-length MD2-HMAC 1444 The general-length MD2-HMAC mechanism, denoted CKM_MD2_HMAC_GENERAL, is a mechanism for 1445 signatures and verification. It uses the HMAC construction, based on the MD2 hash function. The keys it 1446 uses are generic secret keys. 1447 It has a parameter, a CK_MAC_GENERAL_PARAMS, which holds the length in bytes of the desired 1448 output. This length should be in the range 0-16 (the output size of MD2 is 16 bytes). Signatures (MACs) 1449 produced by this mechanism MUST be taken from the start of the full 16-byte HMAC output. 1450 Table 51, General-length MD2-HMAC: Key and Data Length

Function Key type Data length Signature length C_Sign Generic secret Any 0-16, depending on parameters

1451 2.11.4 MD2-HMAC 1452 The MD2-HMAC mechanism, denoted CKM_MD2_HMAC, is a special case of the general-length MD2- 1453 HMAC mechanism in Section 2.11.3. 1454 It has no parameter, and produces an output of length 16.

1455 2.11.5 MD2 key derivation 1456 MD2 key derivation, denoted CKM_MD2_KEY_DERIVATION, is a mechanism which provides the 1457 capability of deriving a secret key by digesting the value of another secret key with MD2. 1458 The value of the base key is digested once, and the result is used to make the value of the derived secret 1459 key. 1460 • If no length or key type is provided in the template, then the key produced by this mechanism MUST 1461 be a generic secret key. Its length MUST be 16 bytes (the output size of MD2).. 1462 • If no key type is provided in the template, but a length is, then the key produced by this mechanism 1463 MUST be a generic secret key of the specified length. 1464 • If no length was provided in the template, but a key type is, then that key type must have a well- 1465 defined length. If it does, then the key produced by this mechanism MUST be of the type specified in 1466 the template. If it doesn’t, an error MUST be returned. 1467 • If both a key type and a length are provided in the template, the length must be compatible with that 1468 key type. The key produced by this mechanism MUST be of the specified type and length. 1469 If a DES, DES2, or CDMF key is derived with this mechanism, the parity bits of the key MUST be set 1470 properly. 1471 If the requested type of key requires more than 16 bytes, such as DES2, an error is generated. 1472 This mechanism has the following rules about key sensitivity and extractability: 1473 • The CKA_SENSITIVE and CKA_EXTRACTABLE attributes in the template for the new key MAY 1474 both be specified to be either CK_TRUE or CK_FALSE. If omitted, these attributes each take on 1475 some default value. 1476 • If the base key has its CKA_ALWAYS_SENSITIVE attribute set to CK_FALSE, then the derived key 1477 MUST as well. If the base key has its CKA_ALWAYS_SENSITIVE attribute set to CK_TRUE, then 1478 the derived key has its CKA_ALWAYS_SENSITIVE attribute set to the same value as its 1479 CKA_SENSITIVE attribute. 1480 • Similarly, if the base key has its CKA_NEVER_EXTRACTABLE attribute set to CK_FALSE, then the 1481 derived key MUST, too. If the base key has its CKA_NEVER_EXTRACTABLE attribute set to 1482 CK_TRUE, then the derived key has its CKA_NEVER_EXTRACTABLE attribute set to the opposite 1483 value from its CKA_EXTRACTABLE attribute.

1484 2.12 MD5

1485 2.12.1 Definitions 1486 Mechanisms: 1487 CKM_MD5 1488 CKM_MD5_HMAC 1489 CKM_MD5_HMAC_GENERAL 1490 CKM_MD5_KEY_DERIVATION

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 50 of 64 1491 2.12.2 MD5 Digest 1492 The MD5 mechanism, denoted CKM_MD5, is a mechanism for message digesting, following the MD5 1493 message-digest algorithm defined in RFC 1321. 1494 It does not have a parameter. 1495 Constraints on the length of input and output data are summarized in the following table. For single-part 1496 digesting, the data and the digest MAY begin at the same location in memory. 1497 Table 52, MD5: Data Length

Function Data length Digest length C_Digest Any 16

1498 2.12.3 General-length MD5-HMAC 1499 The general-length MD5-HMAC mechanism, denoted CKM_MD5_HMAC_GENERAL, is a mechanism for 1500 signatures and verification. It uses the HMAC construction, based on the MD5 hash function. The keys it 1501 uses are generic secret keys. 1502 It has a parameter, a CK_MAC_GENERAL_PARAMS, which holds the length in bytes of the desired 1503 output. This length should be in the range 0-16 (the output size of MD5 is 16 bytes). Signatures (MACs) 1504 produced by this mechanism MUST be taken from the start of the full 16-byte HMAC output. 1505 Table 53, General-length MD5-HMAC: Key and Data Length

Function Key type Data length Signature length C_Sign Generic secret Any 0-16, depending on parameters C_Verify Generic secret Any 0-16, depending on parameters

1506 2.12.4 MD5-HMAC 1507 The MD5-HMAC mechanism, denoted CKM_MD5_HMAC, is a special case of the general-length MD5- 1508 HMAC mechanism in Section 2.12.3. 1509 It has no parameter, and produces an output of length 16.

1510 2.12.5 MD5 key derivation 1511 MD5 key derivation denoted CKM_MD5_KEY_DERIVATION, is a mechanism which provides the 1512 capability of deriving a secret key by digesting the value of another secret key with MD5. 1513 The value of the base key is digested once, and the result is used to make the value of derived secret 1514 key. 1515 • If no length or key type is provided in the template, then the key produced by this mechanism MUST 1516 be a generic secret key. Its length MUST be 16 bytes (the output size of MD5). 1517 • If no key type is provided in the template, but a length is, then the key produced by this mechanism 1518 MUST be a generic secret key of the specified length. 1519 • If no length was provided in the template, but a key type is, then that key type must have a well- 1520 defined length. If it does, then the key produced by this mechanism MUST be of the type specified in 1521 the template. If it doesn’t, an error MUST be returned. 1522 • If both a key type and a length are provided in the template, the length must be compatible with that 1523 key type. The key produced by this mechanism MUST be of the specified type and length. 1524 If a DES, DES2, or CDMF key is derived with this mechanism, the parity bits of the key MUST be set 1525 properly. 1526 If the requested type of key requires more than 16 bytes, such as DES3, an error is generated.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 51 of 64 1527 This mechanism has the following rules about key sensitivity and extractability. 1528 • The CKA_SENSITIVE and CKA_EXTRACTABLE attributes in the template for the new key MAY 1529 both be specified to either CK_TRUE or CK_FALSE. If omitted, these attributes each take on some 1530 default value. 1531 • If the base key has its CKA_ALWAYS_SENSITIVE attribute set to CK_FALSE, then the derived key 1532 MUST as well. If the base key has its CKA_ALWAYS_SENSITIVE attribute set to CK_TRUE, then 1533 the derived key has its CKA_ALWAYS_SENSITIVE attribute set to the same value as its 1534 CKA_SENSITIVE attribute. 1535 • Similarly, if the base key has its CKA_NEVER_EXTRACTABLE attribute set to CK_FALSE, then the 1536 derived key MUST, too. If the base key has its CKA_NEVER_EXTRACTABLE attribute set to 1537 CK_TRUE, then the derived key has its CKA_NEVER_EXTRACTABLE attribute set to the opposite 1538 value from its CKA_EXTRACTABLE attribute.

1539 2.13 FASTHASH

1540 2.13.1 Definitions 1541 Mechanisms: 1542 CKM_FASTHASH

1543 2.13.2 FASTHASH digest 1544 The FASTHASH mechanism, denoted CKM_FASTHASH, is a mechanism for message digesting, 1545 following the U.S. government’s algorithm. 1546 It does not have a parameter. 1547 Constraints on the length of input and output data are summarized in the following table: 1548 Table 54, FASTHASH: Data Length

Function Input length Digest length C_Digest Any 40

1549 2.14 PKCS #5 and PKCS #5-style password-based encryption (PBD)

1550 2.14.1 Definitions 1551 The mechanisms in this section are for generating keys and IVs for performing password-based 1552 encryption. The method used to generate keys and IVs is specified in PKCS #5. 1553 Mechanisms: 1554 CKM_PBE_MD2_DES_CBC 1555 CKM_PBE_MD5_DES_CBC 1556 CKM_PBE_MD5_CAST_CBC 1557 CKM_PBE_MD5_CAST3_CBC 1558 CKM_PBE_MD5_CAST128_CBC 1559 CKM_PBE_SHA1_CAST128_CBC 1560 CKM_PBE_SHA1_RC4_128 1561 CKM_PBE_SHA1_RC4_40 1562 CKM_PBE_SHA1_RC2_128_CBC 1563 CKM_PBE_SHA1_RC2_40_CBC

1565 2.14.2.1 CK_PBE_PARAMS; CK_PBE_PARAMS_PTR 1566 CK_PBE_PARAMS is a structure which provides all of the necessary information required by the 1567 CKM_PBE mechanisms (see PKCS #5 and PKCS #12 for information on the PBE generation 1568 mechanisms) and the CKM_PBA_SHA1_WITH_SHA1_HMAC mechanism. It is defined as follows: 1569 typedef struct CK_PBE_PARAMS { 1570 CK_BYTE_PTR pInitVector; 1571 CK_UTF8CHAR_PTR pPassword; 1572 CK_ULONG ulPasswordLen; 1573 CK_BYTE_PTR pSalt; 1574 CK_ULONG ulSaltLen; 1575 CK_ULONG ulIteration; 1576 } CK_PBE_PARAMS; 1577 The fields of the structure have the following meanings: 1578 pInitVector pointer to the location that receives the 8-byte 1579 initialization vector (IV), if an IV is required

1580 pPassword points to the password to be used in the PBE key 1581 generation

1582 ulPasswordLen length in bytes of the password information

1583 pSalt points to the salt to be used in the PBE key generation

1584 ulSaltLen length in bytes of the salt information

1585 ulIteration number of iterations required for the generation

1586 CK_PBE_PARAMS_PTR is a pointer to a CK_PBE_PARAMS.

1587 2.14.3 MD2-PBE for DES-CBC 1588 MD2-PBE for DES-CBC, denoted CKM_PBE_MD2_DES_CBC, is a mechanism used for generating a 1589 DES secret key and an IV from a password and a salt value by using the MD2 digest algorithm and an 1590 iteration count. This functionality is defined in PKCS #5 as PBKDF1. 1591 It has a parameter, a CK_PBE_PARAMS structure. The parameter specifies the input information for the 1592 key generation process and the location of the application-supplied buffer which receives the 8-byte IV 1593 generated by the mechanism.

1594 2.14.4 MD5-PBE for DES-CBC 1595 MD5-PBE for DES-CBC, denoted CKM_PBE_MD5_DES_CBC, is a mechanism used for generating a 1596 DES secret key and an IV from a password and a salt value by using the MD5 digest algorithm and an 1597 iteration count. This functionality is defined in PKCS #5 as PBKDF1. 1598 It has a parameter, a CK_PBE_PARAMS structure. The parameter specifies the input information for the 1599 key generation process and the location of the application-supplied buffer which receives the 8-byte IV 1600 generated by the mechanism.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 53 of 64 1601 2.14.5 MD5-PBE for CAST-CBC 1602 MD5-PBE for CAST-CBC, denoted CKM_PBE_MD5_CAST_CBC, is a mechanism used for generating a 1603 CAST secret key and an IV from a password and a salt value by using the MD5 digest algorithm and an 1604 iteration count. This functionality is analogous to that defined in PKCS #5 PBKDF1 for MD5 and DES. 1605 It has a parameter, a CK_PBE_PARAMS structure. The parameter specifies the input information for the 1606 key generation process and the location of the application-supplied buffer which receives the 8-byte IV 1607 generated by the mechanism 1608 The length of the CAST key generated by this mechanism MAY be specified in the supplied template; if it 1609 is not present in the template, it defaults to 8 bytes.

1610 2.14.6 MD5-PBE for CAST3-CBC 1611 MD5-PBE for CAST3-CBC, denoted CKM_PBE_MD5_CAST3_CBC, is a mechanism used for generating 1612 a CAST3 secret key and an IV from a password and a salt value by using the MD5 digest algorithm and 1613 an iteration count. This functionality is analogous to that defined in PKCS #5 PBKDF1 for MD5 and DES. 1614 It has a parameter, a CK_PBE_PARAMS structure. The parameter specifies the input information for the 1615 key generation process and the location of the application-supplied buffer which receives the 8-byte IV 1616 generated by the mechanism 1617 The length of the CAST3 key generated by this mechanism MAY be specified in the supplied template; if 1618 it is not present in the template, it defaults to 8 bytes.

1619 2.14.7 MD5-PBE for CAST128-CBC 1620 MD5-PBE for CAST128-CBC, denoted CKM_PBE_MD5_CAST128_CBC, is a mechanism used for 1621 generating a CAST128 secret key and an IV from a password and a salt value by using the MD5 digest 1622 algorithm and an iteration count. This functionality is analogous to that defined in PKCS #5 PBKDF1 for 1623 MD5 and DES. 1624 It has a parameter, a CK_PBE_PARAMS structure. The parameter specifies the input information for the 1625 key generation process and the location of the application-supplied buffer which receives the 8-byte IV 1626 generated by the mechanism 1627 The length of the CAST128 key generated by this mechanism MAY be specified in the supplied template; 1628 if it is not present in the template, it defaults to 8 bytes.

1629 2.14.8 SHA-1-PBE for CAST128-CBC 1630 SHA-1-PBE for CAST128-CBC, denoted CKM_PBE_SHA1_CAST128_, is a mechanism used for 1631 generating a CAST128 secret key and an IV from a password and salt value using the SHA-1 digest 1632 algorithm and an iteration count. This functionality is analogous to that defined in PKCS #5 PBKDF1 for 1633 MD5 and DES. 1634 It has a parameter, a CK_PBE_PARAMS structure. The parameter specifies the input information for the 1635 key generation process and the location of the application-supplied buffer which receives the 8-byte IV 1636 generated by the mechanism 1637 The length of the CAST128 key generated by this mechanism MAY be specified in the supplied template; 1638 if it is not present in the template, it defaults to 8 bytes

1639 2.15 PKCS #12 password-based encryption/authentication 1640 mechanisms

1641 2.15.1 Definitions 1642 The mechanisms in this section are for generating keys and IVs for performing password-based 1643 encryption or authentication. The method used to generate keys and IVs is based on a method that was 1644 specified in PKCS #12.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 54 of 64 1645 We specify here a general method for producing various types of pseudo-random bits from a password, 1646 p; a string of salt bits, s; and an iteration count, c. The “type” of pseudo-random bits to be produced is 1647 identified by an identification byte, ID, described at the end of this section.

u v u 1648 Let H be a hash function built around a compression function ∫:Z2 × Z2 → Z2 (that is, H has a chaining 1649 variable and output of length u bits, and the message input to the compression function of H is v bits). For 1650 MD2 and MD5, u=128 and v=512; for SHA-1, u=160 and v=512. 1651 We assume here that u and v are both multiples of 8, as are the lengths in bits of the password and salt 1652 strings and the number n of pseudo-random bits required. In addition, u and v are of course nonzero. 1653 1. Construct a string, D (the “diversifier”), by concatenating v/8 copies of ID. 1654 2. Concatenate copies of the salt together to create a string S of length v⋅⎡s/v⎤ bits (the final copy of 1655 the salt MAY be truncated to create S). Note that if the salt is the empty string, then so is S 1656 3. Concatenate copies of the password together to create a string P of length v⋅⎡p/v⎤ bits (the final 1657 copy of the password MAY be truncated to create P). Note that if the password is the empty 1658 string, then so is P. 1659 4. Set I=S||P to be the concatenation of S and P. 1660 5. Set j=⎡n/u⎤. 1661 6. For i=1, 2, …, j, do the following: 1662 a. Set Ai=Hc(D||I), the cth hash of D||I. That is, compute the hash of D||I; compute the hash 1663 of that hash; etc.; continue in this fashion until a total of c hashes have been computed, 1664 each on the result of the previous hash. 1665 b. Concatenate copies of Ai to create a string B of length v bits (the final copy of Ai MAY be 1666 truncated to create B). 1667 c. Treating I as a concatenation I0, I1, …, Ik-1 of v-bit blocks, where k=⎡s/v⎤+⎡p/v⎤, modify I 1668 by setting Ij=(Ij+B+1) mod 2v for each j. To perform this addition, treat each v-bit block as 1669 a binary number represented most-significant bit first 1670 7. Concatenate A1, A2, …, Aj together to form a pseudo-random bit string, A. 1671 8. Use the first n bits of A as the output of this entire process 1672 When the password-based encryption mechanisms presented in this section are used to generate a key 1673 and IV (if needed) from a password, salt, and an iteration count, the above algorithm is used. To 1674 generate a key, the identifier byte ID is set to the value 1; to generate an IV, the identifier byte ID is set to 1675 the value 2. 1676 When the password-based authentication mechanism presented in this section is used to generate a key 1677 from a password, salt and an iteration count, the above algorithm is used. The identifier ID is set to the 1678 value 3.

1679 2.15.2 SHA-1-PBE for 128-bit RC4 1680 SHA-1-PBE for 128-bit RC4, denoted CKM_PBE_SHA1_RC4_128, is a mechanism used for generating 1681 a 128-bit RC4 secret key from a password and a salt value by using the SHA-1 digest algorithm and an 1682 iteration count. The method used to generate the key is described above. 1683 It has a parameter, a CK_PBE_PARAMS structure. The parameter specifies the input information for the 1684 key generation process. The parameter also has a field to hold the location of an application-supplied 1685 buffer which receives an IV; for this mechanism, the contents of this field are ignored, since RC4 does not 1686 require an IV. 1687 The key produced by this mechanism will typically be used for performing password-based encryption.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 55 of 64 1688 2.15.3 SHA-1_PBE for 40-bit RC4 1689 SHA-1-PBE for 40-bit RC4, denoted CKM_PBE_SHA1_RC4_40, is a mechanism used for generating a 1690 40-bit RC4 secret key from a password and a salt value by using the SHA-1 digest algorithm and an 1691 iteration count. The method used to generate the key is described above. 1692 It has a parameter, a CK_PBE_PARAMS structure. The parameter specifies the input information for the 1693 key generation process. The parameter also has a field to hold the location of an application-supplied 1694 buffer which receives an IV; for this mechanism, the contents of this field are ignored, since RC4 does not 1695 require an IV. 1696 The key produced by this mechanism will typically be used for performing password-based encryption.

1697 2.15.4 SHA-1_PBE for 128-bit RC2-CBC 1698 SHA-1-PBE for 128-bit RC2-CBC, denoted CKM_PBE_SHA1_RC2_128_CBC, is a mechanism used for 1699 generating a 128-bit RC2 secret key from a password and a salt value by using the SHA-1 digest 1700 algorithm and an iteration count. The method used to generate the key and IV is described above. 1701 It has a parameter, a CK_PBE_PARAMS structure. The parameter specifies the input information for the 1702 key generation process and the location of an application-supplied buffer which receives the 8-byte IV 1703 generated by the mechanism. 1704 When the key and IV generated by this mechanism are used to encrypt or decrypt, the effective number 1705 of bits in the RC2 search space should be set to 128. This ensures compatibility with the ASN.1 Object 1706 Identifier pbeWithSHA1And128BitRC2-CBC. 1707 The key and IV produced by this mechanism will typically be used for performing password-based 1708 encryption.

1709 2.15.5 SHA-1_PBE for 40-bit RC2-CBC 1710 SHA-1-PBE for 40-bit RC2-CBC, denoted CKM_PBE_SHA1_RC2_40_CBC, is a mechanism used for 1711 generating a 40-bit RC2 secret key from a password and a salt value by using the SHA-1 digest algorithm 1712 and an iteration count. The method used to generate the key and IV is described above. 1713 It has a parameter, a CK_PBE_PARAMS structure. The parameter specifies the input information for the 1714 key generation process and the location of an application-supplied buffer which receives the 8-byte IV 1715 generated by the mechanism. 1716 When the key and IV generated by this mechanism are used to encrypt or decrypt, the effective number 1717 of bits in the RC2 search space should be set to 40. This ensures compatibility with the ASN.1 Object 1718 Identifier pbeWithSHA1And40BitRC2-CBC. 1719 The key and IV produced by this mechanism will typically be used for performing password-based 1720 encryption

1721 2.16 RIPE-MD

1722 2.16.1 Definitions 1723 Mechanisms: 1724 CKM_RIPEMD128 1725 CKM_RIPEMD128_HMAC 1726 CKM_RIPEMD128_HMAC_GENERAL 1727 CKM_RIPEMD160 1728 CKM_RIPEMD160_HMAC 1729 CKM_RIPEMD160_HMAC_GENERAL

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 56 of 64 1730 2.16.2 RIPE-MD 128 Digest 1731 The RIPE-MD 128 mechanism, denoted CKM_RIPEMD128, is a mechanism for message digesting, 1732 following the RIPE-MD 128 message-digest algorithm. 1733 It does not have a parameter. 1734 Constraints on the length of data are summarized in the following table: 1735 Table 55, RIPE-MD 128: Data Length

Function Data length Digest length C_Digest Any 16 1736

1737 2.16.3 General-length RIPE-MD 128-HMAC 1738 The general-length RIPE-MD 128-HMAC mechanism, denoted CKM_RIPEMD128_HMAC_GENERAL, is 1739 a mechanism for signatures and verification. It uses the HMAC construction, based on the RIPE-MD 128 1740 hash function. The keys it uses are generic secret keys. 1741 It has a parameter, a CK_MAC_GENERAL_PARAMS, which holds the length in bytes of the desired 1742 output. This length should be in the range 0-16 (the output size of RIPE-MD 128 is 16 bytes). Signatures 1743 (MACs) produced by this mechanism MUST be taken from the start of the full 16-byte HMAC output. 1744 Table 56, General-length RIPE-MD 128-HMAC

Function Key type Data length Signature length C_Sign Generic secret Any 0-16, depending on parameters C_Verify Generic secret Any 0-16, depending on parameters

1745 2.16.4 RIPE-MD 128-HMAC 1746 The RIPE-MD 128-HMAC mechanism, denoted CKM_RIPEMD128_HMAC, is a special case of the 1747 general-length RIPE-MD 128-HMAC mechanism in Section 2.16.3. 1748 It has no parameter, and produces an output of length 16.

1749 2.16.5 RIPE-MD 160 1750 The RIPE-MD 160 mechanism, denoted CKM_RIPEMD160, is a mechanism for message digesting, 1751 following the RIPE-MD 160 message-digest defined in ISO-10118. 1752 It does not have a parameter. 1753 Constraints on the length of data are summarized in the following table: 1754 Table 57, RIPE-MD 160: Data Length

Function Data length Digest length C_Digest Any 20

1755 2.16.6 General-length RIPE-MD 160-HMAC 1756 The general-length RIPE-MD 160-HMAC mechanism, denoted CKM_RIPEMD160_HMAC_GENERAL, is 1757 a mechanism for signatures and verification. It uses the HMAC construction, based on the RIPE-MD 160 1758 hash function. The keys it uses are generic secret keys.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 57 of 64 1759 It has a parameter, a CK_MAC_GENERAL_PARAMS, which holds the length in bytes of the desired 1760 output. This length should be in the range 0-20 (the output size of RIPE-MD 160 is 20 bytes). Signatures 1761 (MACs) produced by this mechanism MUST be taken from the start of the full 20-byte HMAC output. 1762 Table 58, General-length RIPE-MD 160-HMAC: Data and Length

Function Key type Data length Signature length C_Sign Generic secret Any 0-20, depending on parameters C_Verify Generic secret Any 0-20, depending on parameters

1763 2.16.7 RIPE-MD 160-HMAC 1764 The RIPE-MD 160-HMAC mechanism, denoted CKM_RIPEMD160_HMAC, is a special case of the 1765 general-length RIPE-MD 160HMAC mechanism in Section 2.16.6. 1766 It has no parameter, and produces an output of length 20.

1767 2.17 SET

1768 2.17.1 Definitions 1769 Mechanisms: 1770 CKM_KEY_WRAP_SET_OAEP

1771 2.17.2 SET mechanism parameters

1772 2.17.2.1 CK_KEY_WRAP_SET_OAEP_PARAMS; 1773 CK_KEY_WRAP_SET_OAEP_PARAMS_PTR 1774 CK_KEY_WRAP_SET_OAEP_PARAMS is a structure that provides the parameters to the 1775 CKM_KEY_WRAP_SET_OAEP mechanism. It is defined as follows: 1776 typedef struct CK_KEY_WRAP_SET_OAEP_PARAMS { 1777 CK_BYTE bBC; 1778 CK_BYTE_PTR pX; 1779 CK_ULONG ulXLen; 1780 } CK_KEY_WRAP_SET_OAEP_PARAMS; 1781 The fields of the structure have the following meanings: 1782 bBC block contents byte

1783 pX concatenation of hash of plaintext data (if present) and 1784 extra data (if present)

1785 ulXLen length in bytes of concatenation of hash of plaintext data 1786 (if present) and extra data (if present). 0 if neither is 1787 present.

1788 CK_KEY_WRAP_SET_OAEP_PARAMS_PTR is a pointer to a 1789 CK_KEY_WRAP_SET_OAEP_PARAMS.

1790 2.17.3 OAEP key wrapping for SET 1791 The OAEP key wrapping for SET mechanism, denoted CKM_KEY_WRAP_SET_OAEP, is a mechanism 1792 for wrapping and unwrapping a DES key with an RSA key. The hash of some plaintext data and/or some

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 58 of 64 1793 extra data MAY be wrapped together with the DES key. This mechanism is defined in the SET protocol 1794 specifications. 1795 It takes a parameter, a CK_KEY_WRAP_SET_OAEP_PARAMS structure. This structure holds the 1796 “Block Contents” byte of the data and the concatenation of the hash of plaintext data (if present) and the 1797 extra data to be wrapped (if present). If neither the hash nor the extra data is present, this is indicated by 1798 the ulXLen field having the value 0. 1799 When this mechanism is used to unwrap a key, the concatenation of the hash of plaintext data (if present) 1800 and the extra data (if present) is returned following the convention described [PKCS #11-Curr], 1801 Miscellaneous simple key derivation mechanisms. Note that if the inputs to C_UnwrapKey are such 1802 that the extra data is not returned (e.g. the buffer supplied in the 1803 CK_KEY_WRAP_SET_OAEP_PARAMS structure is NULL_PTR), then the unwrapped key object MUST 1804 NOT be created, either. 1805 Be aware that when this mechanism is used to unwrap a key, the bBC and pX fields of the parameter 1806 supplied to the mechanism MAY be modified. 1807 If an application uses C_UnwrapKey with CKM_KEY_WRAP_SET_OAEP, it may be preferable for it 1808 simply to allocate a 128-byte buffer for the concatenation of the hash of plaintext data and the extra data 1809 (this concatenation MUST NOT be larger than 128 bytes), rather than calling C_UnwrapKey twice. Each 1810 call of C_UnwrapKey with CKM_KEY_WRAP_SET_OAEP requires an RSA decryption operation to be 1811 performed, and this computational overhead MAY be avoided by this means.

1812 2.18 LYNKS

1813 2.18.1 Definitions 1814 Mechanisms: 1815 CKM_KEY_WRAP_LYNKS

1816 2.18.2 LYNKS key wrapping 1817 The LYNKS key wrapping mechanism, denoted CKM_KEY_WRAP_LYNKS, is a mechanism for 1818 wrapping and unwrapping secret keys with DES keys. It MAY wrap any 8-byte secret key, and it produces 1819 a 10-byte wrapped key, containing a cryptographic checksum. 1820 It does not have a parameter. 1821 To wrap an 8-byte secret key K with a DES key W, this mechanism performs the following steps:

1822 1. Initialize two 16-bit integers, sum1 and sum2, to 0 1823 2. Loop through the bytes of K from first to last.

1824 3. Set sum1= sum1+the key byte (treat the key byte as a number in the range 0-255). 1825 4. Set sum2= sum2+ sum1. 1826 5. Encrypt K with W in ECB mode, obtaining an encrypted key, E. 1827 6. Concatenate the last 6 bytes of E with sum2, representing sum2 most-significant bit first. The 1828 result is an 8-byte block, T 1829 7. Encrypt T with W in ECB mode, obtaining an encrypted checksum, C. 1830 8. Concatenate E with the last 2 bytes of C to obtain the wrapped key. 1831 When unwrapping a key with this mechanism, if the cryptographic checksum does not check out properly, 1832 an error is returned. In addition, if a DES key or CDMF key is unwrapped with this mechanism, the parity 1833 bits on the wrapped key must be set appropriately. If they are not set properly, an error is returned.

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 59 of 64 1834 3 PKCS #11 Implementation Conformance 1835 An implementation is a conforming implementation if it meets the conditions specified in one or more 1836 server profiles specified in [PKCS #11-Prof]. 1837 A PKCS #11 implementation SHALL be a conforming PKCS #11 implementation. 1838 If a PKCS #11 implementation claims support for a particular profile, then the implementation SHALL 1839 conform to all normative statements within the clauses specified for that profile and for any subclauses to 1840 each of those clauses.

1842 The following individuals have participated in the creation of this specification and are gratefully 1843 acknowledged: 1844 Participants: 1845 Benton Stark - Cisco Systems 1846 Anthony Berglas - Cryptsoft Pty Ltd. 1847 Justin Corlett - Cryptsoft Pty Ltd. 1848 Tony Cox - Cryptsoft Pty Ltd. 1849 Tim Hudson - Cryptsoft Pty Ltd. 1850 Bruce Rich - Cryptsoft Pty Ltd. 1851 Greg Scott - Cryptsoft Pty Ltd. 1852 Jason Thatcher - Cryptsoft Pty Ltd. 1853 Magda Zdunkiewicz - Cryptsoft Pty Ltd. 1854 Andrew Byrne - Dell 1855 David Horton - Dell 1856 Kevin Mooney - Fornetix 1857 Gerald Stueve - Fornetix 1858 Charles White - Fornetix 1859 Matt Bauer - Galois, Inc. 1860 Wan-Teh Chang - Google Inc. 1861 Patrick Steuer - IBM 1862 Michele Drgon - Individual 1863 Gershon Janssen - Individual 1864 Oscar So - Individual 1865 Michelle Brochmann - Information Security Corporation 1866 Michael Mrkowitz - Information Security Corporation 1867 Jonathan Schulze-Hewett - Information Security Corporation 1868 Philip Lafrance - ISARA Corporation 1869 Thomas Hardjono - M.I.T. 1870 Hamish Cameron - nCipher 1871 Paul King - nCipher 1872 Sander Temme - nCipher 1873 Chet Ensign - OASIS 1874 Jane Harnad - OASIS 1875 Web Master - OASIS 1876 Dee Schur - OASIS 1877 Xuelei Fan - Oracle 1878 Jan Friedel - Oracle 1879 Susan Gleeson - Oracle 1880 Dina Kurktchi-Nimeh - Oracle 1881 John Leser - Oracle

pkcs11-hist-v3.0-os 15 June 2020 Standards Track Work Product Copyright © OASIS Open 2020. All Rights Reserved. Page 61 of 64 1882 Darren Moffat - Oracle 1883 Mark Joseph - P6R, Inc 1884 Jim Susoy - P6R, Inc 1885 Roland Bramm - PrimeKey Solutions AB 1886 Warren Armstrong - QuintessenceLabs Pty Ltd. 1887 Kenli Chong - QuintessenceLabs Pty Ltd. 1888 John Leiseboer - QuintessenceLabs Pty Ltd. 1889 Florian Poppa - QuintessenceLabs Pty Ltd. 1890 Martin Shannon - QuintessenceLabs Pty Ltd. 1891 Jakub Jelen - Red Hat 1892 Chris Malafis - Red Hat 1893 Robert Relyea - Red Hat 1894 Christian Bollich - Utimaco IS GmbH 1895 Dieter Bong - Utimaco IS GmbH 1896 Chris Meyer - Utimaco IS GmbH 1897 Daniel Minder - Utimaco IS GmbH 1898 Roland Reichenberg - Utimaco IS GmbH 1899 Manish Upasani - Utimaco IS GmbH 1900 Steven Wierenga - Utimaco IS GmbH

1902 The definitions for manifest constants specified in this document can be found in the following normative 1903 computer language definition files: 1904 • include/pkcs11-v3.0/pkcs11.h 1905 • include/pkcs11-v3.0/pkcs11t.h 1906 • include/pkcs11-v3.0/pkcs11f.h 1907 These files are linked from the "Additional artifacts" section at the top of this specification.

1909

Revision Date Editor Changes Made

wd01 20 April Dieter Bong - All CAST5 definitions removed 2019 - Replaced reference to [PKCS11-Base] table 10 by [PKCS11-Base] table 11 throughout whole document

wd02 May 28, Tony Cox Final cleanup of front introductory texts and 2019 links prior to CSPRD

1910