| Internet-Draft | QSC Keys for SPHINCS-PLUS | October 2022 |
| Vredendaal, et al. | Expires 26 April 2023 | [Page] |
This proposal defines key management approaches for the Quantum Safe Cryptographic (QSC) algorithm SPHINCS+ (or SPHINCS-PLUS) which has been selected for standardization by the NIST Post Quantum Cryptography (PQC) process. This includes key identification and key serialization. The purpose is to provide guidance such that the adoption of quantum safe algorithms is not hampered with the fragmented evolution of necessary key management standards. Early definition of key material standards will help expedite the adoption of new quantum safe algorithms at the same time as improving interoperability between implementations and minimizing divergence across standards.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 26 April 2023.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
QSC algorithms being standardized in the NIST PQC Process have evolved through several rounds and iterations. Keys are neither easily identifiable nor compatible across rounds. It is also expected that algorithms will evolve after final candidates have been selected. The lack of binary compatibility between algorithm versions and variants means that it is important to clearly identify key material. Parallel to the NIST process, industry is evaluating the impact of adopting new PQC algorithms, in particular key management. Here it is important to define and standardize key serialization and encoding formats. Finally, we have seen that many platforms and protocols are very constrained when it comes to the amount of memory or space available for key objects. This makes it important to define and standardize key compression formats. This proposal addresses aspects of key identification and key serialization for the future NIST PQC Digital Signature standard, SPHINCS-PLUS. For the other schemes, see draft-uni-qsckeys-dilithium, draft-uni-qsckeys-falcon, draft-uni-qsckeys-kyber and the previous Internet-Draft [draft-uni-qsckeys-01]. This proposal will be updated when the final NIST standard for SPHINCS-PLUS becomes available.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] .¶
Algorithm identification is important for several reasons:¶
The current standardization of quantum safe algorithms does not address the definition of serialization structures for keys. As a result, it has become commonplace for the cryptographic community working on and with these algorithms to define their own approaches. This leads to proprietary and internal representations for key material. This has certain advantages in terms of ease of experimentation while focusing on finding the best-performing QSC algorithms. In terms of longer-term support where algorithm versions change this is a problem. This proposal defines in section 2 a long-term structured key representation format useful to address the goals outlined above.¶
Algorithm and algorithm parameter information shall have ASN.1 type AlgorithmIdentifier as given in [RFC5280] and shall be extended by an pqcAlgorithmParameterName type in the optional parameters field:¶
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER, - OID: algorithm and algo parameter
parameters pqcAlgorithmParameterName OPTIONAL
}
pqcAlgorithmParameterName ::= PrintableString
¶
SPHINCS-PLUS consists of 18 different parameter sets. This memo attributes a name and a placeholder for an OID to the different parameter sets of SPHINCS-PLUS. The following table gives an overview of the possible OIDs in the algorithm field and possible parameters set names in the parameters field of the AlgorithmIdentifier type. Each name or OID represents a single parameter set of given security. Details can be found in the next section.¶
|=========+=====+======================================================|
| SPHINCS-PLUS (PQC Digital Signature) |
|=========+=====+======================================================|
| sphincsplus-sha2-128s-r3 |
|---------+-----+------------------------------------------------------|
| |ASN.1| {..*.. pqc-ds-sphincsplus sphincsplus-sha2-128s-r3} |
| |dot. | |
|---------+-----+------------------------------------------------------|
| sphincsplus-shake-128s-r3 |
|---------+-----+------------------------------------------------------|
| |ASN.1| {..*.. pqc-ds-sphincsplus sphincsplus-shake-128s-r3} |
| |dot. | |
|---------+-----+------------------------------------------------------|
| sphincsplus-haraka-128s-r3 |
|---------+-----+------------------------------------------------------|
| |ASN.1| {..*.. pqc-ds-sphincsplus sphincsplus-haraka-128s-r3}|
| |dot. | |
|---------+-----+------------------------------------------------------|
| sphincsplus-sha2-128f-r3 |
|---------+-----+------------------------------------------------------|
| |ASN.1| {..*.. pqc-ds-sphincsplus sphincsplus-sha2-128f-r3} |
| |dot. | |
|---------+-----+------------------------------------------------------|
| sphincsplus-shake-128f-r3 |
|---------+-----+------------------------------------------------------|
| |ASN.1| {..*.. pqc-ds-sphincsplus sphincsplus-shake-128f-r3} |
| |dot. | |
|---------+-----+------------------------------------------------------|
| sphincsplus-haraka-128f-r3 |
|---------+-----+------------------------------------------------------|
| |ASN.1| {..*.. pqc-ds-sphincsplus sphincsplus-haraka-128f-r3}|
| |dot. | |
|---------+-----+------------------------------------------------------|
| sphincsplus-sha2-192s-r3 |
|---------+-----+------------------------------------------------------|
| |ASN.1| {..*.. pqc-ds-sphincsplus sphincsplus-sha2-192s-r3} |
| |dot. | |
|---------+-----+------------------------------------------------------|
| sphincsplus-shake-192s-r3 |
|---------+-----+------------------------------------------------------|
| |ASN.1| {..*.. pqc-ds-sphincsplus sphincsplus-shake-192s-r3} |
| |dot. | |
|---------+-----+------------------------------------------------------|
| sphincsplus-haraka-192s-r3 |
|---------+-----+------------------------------------------------------|
| |ASN.1| {..*.. pqc-ds-sphincsplus sphincsplus-haraka-192s-r3}|
| |dot. | |
|---------+-----+------------------------------------------------------|
| sphincsplus-sha2-192f-r3 |
|---------+-----+------------------------------------------------------|
| |ASN.1| {..*.. pqc-ds-sphincsplus sphincsplus-sha2-192f-r3} |
| |dot. | |
|---------+-----+------------------------------------------------------|
| sphincsplus-shake-192f-r3 |
|---------+-----+------------------------------------------------------|
| |ASN.1| {..*.. pqc-ds-sphincsplus sphincsplus-shake-192f-r3} |
| |dot. | |
|---------+-----+------------------------------------------------------|
| sphincsplus-haraka-192f-r3 |
|---------+-----+------------------------------------------------------|
| |ASN.1| {..*.. pqc-ds-sphincsplus sphincsplus-haraka-192f-r3}|
| |dot. | |
|---------+-----+------------------------------------------------------|
| sphincsplus-sha2-256s-r3 |
|---------+-----+------------------------------------------------------|
| |ASN.1| {..*.. pqc-ds-sphincsplus sphincsplus-sha2-256s-r3} |
| |dot. | |
|---------+-----+------------------------------------------------------|
| sphincsplus-shake-256s-r3 |
|---------+-----+------------------------------------------------------|
| |ASN.1| {..*.. pqc-ds-sphincsplus sphincsplus-shake-256s-r3} |
| |dot. | |
|---------+-----+------------------------------------------------------|
| sphincsplus-haraka-256s-r3 |
|---------+-----+------------------------------------------------------|
| |ASN.1| {..*.. pqc-ds-sphincsplus sphincsplus-haraka-256s-r3}|
| |dot. | |
|---------+-----+------------------------------------------------------|
| sphincsplus-sha2-256f-r3 |
|---------+-----+------------------------------------------------------|
| |ASN.1| {..*.. pqc-ds-sphincsplus sphincsplus-sha2-256f-r3} |
| |dot. | |
|---------+-----+------------------------------------------------------|
| sphincsplus-shake-256f-r3 |
|---------+-----+------------------------------------------------------|
| |ASN.1| {..*.. pqc-ds-sphincsplus sphincsplus-shake-256f-r3} |
| |dot. | |
|---------+-----+------------------------------------------------------|
| sphincsplus-haraka-256f-r3 |
|---------+-----+------------------------------------------------------|
| |ASN.1| {..*.. pqc-ds-sphincsplus sphincsplus-haraka-256f-r3}|
| |dot. | |
|=========+=====+======================================================|
The private key format defined is from PKCS#8 [RFC5208] . PKCS#8 PrivateKeyInfo is defined as:¶
PrivateKeyInfo ::= SEQUENCE {
version INTEGER -- PKCS#8 syntax ver
privateKeyAlgorithm AlgorithmIdentifier -- see chapter above
privateKey OCTET STRING, -- see chapter below
attributes [0] IMPLICIT Attributes OPTIONAL
}
¶
Distributing a PQC private key requires a PKCS#8 PrivateKeyInfo with a joined PQC algorithm and algorithm parameter OID in the algorithm field of AlgorithmIdentifier and a PQC algorithm specific private key object in the privateKey field of PrivateKeyInfo. Both objects are defined in the specific algorithm sections of this document. For an overview see tables above and below.¶
RFC5280 subjectPublicKeyInfo is defined in as:¶
SubjectPublicKeyInfo := SEQUENCE {
algorithm AlgorithmIdentifier -- see chapter above
subjectPublicKey BIT STRING -- see chapter below
}
¶
Distributing a PQC public key requires a [RFC5480] subjectPublicKeyInfo with a joined PQC algorithm and algorithm parameter OID in the algorithm field of AlgorithmIdentifier and a PQC algorithm specific public key object in the subjectPublicKey field of subjectPublicKeyInfo. Both objects are defined in the specific algorithm sections of this document. For an overview see tables above and below.¶
The privateKey field in the PrivateKeyInfo type [RFC5480] is an OCTET STRING whose contents are the value of the private key. The interpretation of the content differs from PQC algorithm to algorithm. The subjectPublicKey field in the subjectPublicKeyInfo type [RFC5480] is a BIT STRING whose contents are the value of the public key. Here also the interpretation of the content differs from PQC algorithm to algorithm.¶
SPHINCS-PLUS is a hash-based signature scheme. The algoritm is based on the hardness assumptions of its underlying hash functions, which can be chosen from the set Haraka, SHA2 or SHAKE.¶
Since the underlying hash function can be chosen, for each parameter set identified in the SPHINCS-PLUS specification in fact three parameter OIDs exist. The parameters are the same across the three parameter OIDs.¶
|=========================+=====================================|
| SPHINCS-PLUS-128s |
|=========================+=====================================|
| Parameter OID | {..*.. sphincsplus-sha2-128s-r3} |
| | <.> |
| NIST Level Security | Level 1 |
|-------------------------|-------------------------------------|
| Parameter OID | {..*.. sphincsplus-shake-128s-r3} |
| | <.> |
| NIST Level Security | Level 1 |
|-------------------------|-------------------------------------|
| Parameter OID | {..*.. sphincsplus-haraka-128s-r3} |
| | <.> |
| NIST Level Security | Level 1 |
|-------------------------|-------------------------------------|
| Parameters | Security parameter n = 16 |
| | Hypertree height h = 63 |
| | Hypertree layers d = 7 |
| | FORS tree leaves log(t) = 12 |
| | Number of FORS trees k = 14 |
| | Winternitz parameter w = 16 |
|=========================+=====================================|
| SPHINCS-PLUS-128f |
|=========================+=====================================|
| Parameter OID | {..*.. sphincsplus-sha2-128f-r3} |
| | <.> |
| NIST Level Security | Level 1 |
|-------------------------|-------------------------------------|
| Parameter OID | {..*.. sphincsplus-shake-128f-r3} |
| | <.> |
| NIST Level Security | Level 1 |
|-------------------------|-------------------------------------|
| Parameter OID | {..*.. sphincsplus-haraka-128f-r3} |
| | <.> |
| NIST Level Security | Level 1 |
|-------------------------|-------------------------------------|
| Parameters | Security parameter n = 16 |
| | Hypertree height h = 66 |
| | Hypertree layers d = 22 |
| | FORS tree leaves log(t) = 6 |
| | Number of FORS trees k = 33 |
| | Winternitz parameter w = 16 |
|=========================+=====================================|
| SPHINCS-PLUS-192s |
|=========================+=====================================|
| Parameter OID | {..*.. sphincsplus-sha2-192s-r3} |
| | <.> |
| NIST Level Security | Level 3 |
|-------------------------|-------------------------------------|
| Parameter OID | {..*.. sphincsplus-shake-192s-r3} |
| | <.> |
| NIST Level Security | Level 3 |
|-------------------------|-------------------------------------|
| Parameter OID | {..*.. sphincsplus-haraka-192s-r3} |
| | <.> |
| NIST Level Security | Level 2 |
|-------------------------|-------------------------------------|
| Parameters | Security parameter n = 24 |
| | Hypertree height h = 63 |
| | Hypertree layers d = 7 |
| | FORS tree leaves log(t) = 14 |
| | Number of FORS trees k = 17 |
| | Winternitz parameter w = 16 |
|=========================+=====================================|
| SPHINCS-PLUS-192f |
|=========================+=====================================|
| Parameter OID | {..*.. sphincsplus-sha2-192f-r3} |
| | <.> |
| NIST Level Security | Level 3 |
|-------------------------|-------------------------------------|
| Parameter OID | {..*.. sphincsplus-shake-192f-r3} |
| | <.> |
| NIST Level Security | Level 3 |
|-------------------------|-------------------------------------|
| Parameter OID | {..*.. sphincsplus-haraka-192f-r3} |
| | <.> |
| NIST Level Security | Level 2 |
|-------------------------|-------------------------------------|
| Parameters | Security parameter n = 24 |
| | Hypertree height h = 66 |
| | Hypertree layers d = 22 |
| | FORS tree leaves log(t) = 8 |
| | Number of FORS trees k = 33 |
| | Winternitz parameter w = 16 |
|=========================+=====================================|
| SPHINCS-PLUS-256s |
|=========================+=====================================|
| Parameter OID | {..*.. sphincsplus-sha2-256s-r3} |
| | <.> |
| NIST Level Security | Level 5 |
|-------------------------|-------------------------------------|
| Parameter OID | {..*.. sphincsplus-shake-256s-r3} |
| | <.> |
| NIST Level Security | Level 5 |
|-------------------------|-------------------------------------|
| Parameter OID | {..*.. sphincsplus-haraka-256s-r3} |
| | <.> |
| NIST Level Security | Level 2 |
|-------------------------|-------------------------------------|
| Parameters | Security parameter n = 32 |
| | Hypertree height h = 64 |
| | Hypertree layers d = 8 |
| | FORS tree leaves log(t) = 14 |
| | Number of FORS trees k = 22 |
| | Winternitz parameter w = 16 |
|=========================+=====================================|
| SPHINCS-PLUS-256f |
|=========================+=====================================|
| Parameter OID | {..*.. sphincsplus-sha2-256f-r3} |
| | <.> |
| NIST Level Security | Level 5 |
|-------------------------|-------------------------------------|
| Parameter OID | {..*.. sphincsplus-shake-256f-r3} |
| | <.> |
| NIST Level Security | Level 5 |
|-------------------------|-------------------------------------|
| Parameter OID | {..*.. sphincsplus-haraka-256f-r3} |
| | <.> |
| NIST Level Security | Level 2 |
|-------------------------|-------------------------------------|
| Parameters | Security parameter n = 32 |
| | Hypertree height h = 68 |
| | Hypertree layers d = 17 |
| | FORS tree leaves log(t) = 9 |
| | Number of FORS trees k = 35 |
| | Winternitz parameter w = 16 |
|=========================+=====================================|
The SPHINCS-PLUS secret key contains 4 n-byte components SK.seed, SK.prf, PK.seed and PK.root. The latter 2 components are equivalent to the SPHINCS-PLUS public key.¶
|============================+=========+==========| | Algorithm OID | Params | Secret | | | | Key | | | | Length | |============================+=========+==========+ | sphincsplus-sha2-128s-r3 | n=16 | 64 | | sphincsplus-sha2-128f-r3 | | | | sphincsplus-shake-128s-r3 | | | | sphincsplus-shake-128f-r3 | | | | sphincsplus-haraka-128s-r3 | | | | sphincsplus-haraka-128f-r3 | | | |============================+=========+==========+ | sphincsplus-sha2-192s-r3 | n=24 | 96 | | sphincsplus-sha2-192f-r3 | | | | sphincsplus-shake-192s-r3 | | | | sphincsplus-shake-192f-r3 | | | | sphincsplus-haraka-192s-r3 | | | | sphincsplus-haraka-192f-r3 | | | |============================+=========+==========+ | sphincsplus-sha2-256s-r3 | n=32 | 128 | | sphincsplus-sha2-256f-r3 | | | | sphincsplus-shake-256s-r3 | | | | sphincsplus-shake-256f-r3 | | | | sphincsplus-haraka-256s-r3 | | | | sphincsplus-haraka-256f-r3 | | | |============================+=========+==========+
Encoding a SPHINCS-PLUS private key with PKCS#8 must include the following two fields:¶
For a signing operation of SPHINCS-PLUS the PK.seed of the Public Key is required. Therefore the SPHINCS-PLUS public key is included in the distributed PrivateKeyInfo, and the PublicKey field in SPHINCSPLUSPrivateKey is used (see description of SPHINCSPLUSPublicKey below).¶
ASN.1 Encoding for a SPHINCS-PLUS secret key:¶
SPHINCSPLUSPrivateKey ::= SEQUENCE {
version INTEGER {v2(1)} --syntax version 2 (round 3)
skseed OCTET STRING, --n-byte private key seed
skprf OCTET STRING, --n-byte private key seed
PublicKey SPHINCSPLUSPublicKey --public key
}
¶
The SPHINCS-PLUS public key contains 2 n-byte components PK.seed and PK.root.¶
|============================+=========+==========| | Algorithm OID | Params | Secret | | | | Key | | | | Length | |============================+=========+==========+ | sphincsplus-sha2-128s-r3 | n=16 | 32 | | sphincsplus-sha2-128f-r3 | | | | sphincsplus-shake-128s-r3 | | | | sphincsplus-shake-128f-r3 | | | | sphincsplus-haraka-128s-r3 | | | | sphincsplus-haraka-128f-r3 | | | |============================+=========+==========+ | sphincsplus-sha2-192s-r3 | n=24 | 48 | | sphincsplus-sha2-192f-r3 | | | | sphincsplus-shake-192s-r3 | | | | sphincsplus-shake-192f-r3 | | | | sphincsplus-haraka-192s-r3 | | | | sphincsplus-haraka-192f-r3 | | | |============================+=========+==========+ | sphincsplus-sha2-256s-r3 | n=32 | 64 | | sphincsplus-sha2-256f-r3 | | | | sphincsplus-shake-256s-r3 | | | | sphincsplus-shake-256f-r3 | | | | sphincsplus-haraka-256s-r3 | | | | sphincsplus-haraka-256f-r3 | | | |============================+=========+==========+
SPHINCSPPLUSPublicKey := SEQUENCE {
pkseed OCTET STRING, --n-byte public key seed
pkroot OCTET STRING --n-byte public hypertree root
}
¶
This template was derived from an initial version written by Pekka Savola and contributed by him to the xml2rfc project.¶
This document is part of a plan to make xml2rfc indispensable.¶
This memo includes no request to IANA.¶
Any processing of the ASN.1 private key structures, such as base64 en/decoding shall be performed in "constant-time", meaning without secret-dependent control flow and table lookups. The ASN.1 structures in this document are defined with fixed tag-lengths. The purpose is to prevent side-channel leakage of variable lengths during DER parsing. Any DER parsing of the private key ASN.1 key structures shall be performed with these fixed lengths.¶
This becomes an Appendix.¶