]> CableLabs Inc.

858 Coal Creek Cir Louisville, Colorado 80027 United States of America director@openca.org

D-Trust GmbH

Kommandantenstr. 15 Berlin 10969 Germany jan.klaussner@d-trust.net

Entrust Limited

2500 Solandt Road -- Suite 100 Ottawa, Ontario K2K 3G5 Canada mike.ounsworth@entrust.com

Entrust Limited

2500 Solandt Road -- Suite 100 Ottawa, Ontario K2K 3G5 Canada john.gray@entrust.com

Security LAMPS Internet-Draft With the need to evolve the cryptography used in today applications, devices, and networks, there are many scenarios where the use of a single-algorithm is not sufficient. For example, there might be the need for migrating between two existing algorithms because of a weakening of earlier generations (e.g., from classic or traditional to post-quantum or quantum-safe). Another example might involve the need to test, instead, the capabilities of devices via test drivers and/or non-standard algorithms. Another very common case is the need to combine certified cryptography (e.g., FIPS) with newer algorithms that are not yet certified or that are not planned for certification. This work extends the options provided by Explicit Composite, defined in , by providing a mechanism to manage backward and forward compatibility via k-of-n signature validation procedures. This document provides the definition of a new type of the kofn-CompositePublicKey and kofn-CompositeSignature which are aligned with the definitions of the respective structures for Explicit Composite .

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 when, and only when, they appear in all capitals, as shown here. These words may also appear in this document in lower case as plain English words, absent their normative meanings. This document is consistent with the terminology defined in . In addition, the following terminology is used throughout this document: ALGORITHM: A standardized cryptographic primitive, as well as any ASN.1 structures needed for encoding data and metadata needed to use the algorithm. This document is primarily concerned with algorithms for producing digital signatures. BER: Basic Encoding Rules (BER) as defined in . COMPONENT ALGORITHM: A single basic algorithm which is contained within a composite algorithm. COMPONENT KEY: One component of the Composite Key. For example, an RSA, a ML-DSA or a FN-DSA key. COMPOSITE ALGORITHM: An algorithm which is a sequence of two or more component algorithms, as defined in . CLIENT: Any software that is making use of a cryptographic key. This includes a signer, verifier, encrypter, decrypter. DER: Distinguished Encoding Rules as defined in . PKI: Public Key Infrastructure, as defined in . POST-QUANTUM ALGORITHM: Any cryptographic algorithm which is believed to be resistant to classical and quantum cryptanalysis, such as the algorithms being considered for standardization by NIST. PUBLIC / PRIVATE KEY: The public and private portion of an asymmetric cryptographic key, making no assumptions about which algorithm. K-of-N: A k-of-n signature is a signature that is valid if and only if at least k of the n component signatures are supported. N: The number of component signatures in a K-of-N signature. The maximum value of N is kofn-CompositeComponentsMax (16). K: The number of component signatures that must be supported (and correctly validated) in order for the k-of-n signature to be valid. The maximum value of K is kofn-CompositeThresholdMax (15). SIGNATURE: A digital cryptographic signature, making no assumptions about which algorithm. STRIPPING ATTACK: An attack in which the attacker is able to downgrade the cryptographic object to an attacker-chosen subset of original set of component algorithms in such a way that it is not detectable by the receiver. For example, substituting a composite public key or signature for a version with fewer components.

Introduction When the trust in the cryptographic algorithms is not static (e.g., not enough crypto-analysis has happened yet or a new threat is envisioned to be deployable in the next future), there might be the need to combine multiple algorithms together to provide different security properties. Similar considerations apply to the deployment of certified algorithms together with experimental or non-standard ones. Even after a migration period, it may be advantageous for an entity cryptographic identity to be composed of multiple public-key algorithms where different security and non-security properties might be provided through the use of hybrid solutions (multi-algorithms). In other words, this work provides a flexible mechanism for crypto-agility and migration paths deployments especially suited for critical infrastructures, device networks, and environments where the use of multiple algorithms is required but no change in the protocol is desired. For further considerations on the challenges related to crypto-agility, please refer to .

Alternative Algorithms Support (k-of-n) Although Composite cryptography and Hybrid solutions can be used in many common use-cases to protect against algorithmic failures over time, there are other use-cases that mandate for supporting crypto-interoperability to continue to be able to operate old devices (e.g., not upgradable) when deploying newer devices and crypto algorithms. This is particularly true in environments where deployed devices might be distributed in the field such as infrastructure's network elements (e.g., network routers, amplifiers, monitoring devices, cable modems, public access points, etc.) and access to resources outside the managed network is highly restricted (i.e., control interface traffic, not user-generated traffic). The use of multi-algorithms provides a mechanism for enabling forward and/or backward compatibility across devices with mixed upgrade capabilities. This work introduces the concept of K-of-N threshold signatures which joins the family of hybrid options such as the Explicit Composite signatures and KEMs.

Differences between K-of-N Composite and Explicit Composite K-of-N Composite keys and signatures work very similarly to Explicit Composite signatures. When generating a K-of-N Composite key, the process used is the same as the one used for the Explicit Composite case with the addition of required parameters that provide the details for the algorithms and the individual component's details. When generating a signature, the process used for K-of-N Composite signatures is exactly the same as the one used in the Explicit Composite case. When validating a signature, the K-of-N Composite signatures' validation process MAY differ from the Explicit Composite case when parameters are present in the K-of-N Composite public key. In fact, as discussed in more details in a later Section, K-of-N Composite keys use parameters to specify the number of component algorithms that are required to be known by the crypto layer (and must validate correctly) and/or which components are considered required and which ones can be skipped. In other words, the K-of-N approach differs from the Explicit Composite crypto in that it allows relying parties to perform the validation of a subset of signatures if and only if the K-of-N parameter is present in the PublicKey (i.e., with the K value) and up to X algorithms are unknown to the device. It is obvious that X must be less then or equal to K - N . One of the important aspect that is worth mentioning is that the K-of-N approach only allows to skip validations of signatures if the specific component algorithm is not supported and it does NOT allow to skip the validation of a known algorithm if the signature is not correctly verified. In this work, we define N the number of component key in the K-of-N Composite key, and K the minimum number of component algorithms that must be supported by the cypto layer (and successfully verified) for the K-of-N Composite signature to be considered valid. The maximum allowed value for N is MaxComponents (16) and the maximum allowed value for K is MaxThreshold (15). When K is used, it MUST be less than N to allow for N - K algorithms to be skipped (if unknown).

K-of-N Composite Keys K-of-N Composite Crypto algorithm is identified by the id-kofn-CompositeCrypto OID defined as follows:

Private Keys This section provides an encoding for K-of-N Composite private keys intended for PKIX protocols and other applications that require an interoperable format for transmitting private keys, such as PKCS #8 , PKCS #12 , CMP , or CRMF . Although it is possible to use different types of storage for the individual components of a K-of-N Composite key (e.g., certified key modules and non-certified key modules), this document does not cover this use-case. The K-of-N Composite private key data use the same structure as in CompositePrivateKey where each component key is a OneAsymmetricKey object:

The parameters field is of type kofn-CompositeParams and is defined as follows:

The use of any Composite or hybrid algorithm (e.g., the pk-kofn-CompositePublicKey or any of the Explicit Composite algorithms defined in ) is NOT allowed as a component of a kofn-CompositePrivateKey. The order of the component keys MUST be the same as the order defined for the corresponding public key components. When a kofn-CompositePrivateKey is conveyed inside a OneAsymmetricKey structure (version 1 of which is also known as PrivateKeyInfo) , the privateKeyAlgorithm field SHALL be set to id-kofn-CompositeCrypto value, the privateKey field SHALL contain the kofn-CompositePrivateKey data. Associated public key material MAY be present in the the publicKey field. In some usecases the private keys that comprise a composite key may not be represented in a single structure or even be contained in a single cryptographic module; for example if one component is within the FIPS boundary of a cryptographic module and the other is not; see {sec-fips} for more discussion. The establishment of correspondence between public keys in a kofn-CompositePublicKey and kofn-CompositePrivateKey not represented in a single composite structure is beyond the scope of this document.

Public Keys K-of-N Composite Public Keys are identified by the id-kofn-CompositeCrypto OID and the associated definition of K-of-N Composite public key (pk-kofn-CompositePublicKey) is provided as follows:

The use of any Composite algorithms (e.g., the pk-kofn-CompositePublicKey or any of the Explicit Composite algorithms defined in ) is NOT allowed as a component of a pk-kofn-CompositePublicKey.

Key Generation The KeyGen() -> (pk, sk) is defined as a probabilistic key generation algorithm, which generates a public key pk and a secret key sk. The KeyGen() -> (pk, sk) of a composite algorithm performs the KeyGen() of the respective component signature algorithms and it produces a composite public key pk as per and a composite secret key sk is per .

K-of-N Composite Signatures A K-of-N Composite signature allows two or more underlying signature algorithms to be combined into a single cryptographic signature operation and can be used for applications that require signatures. In this section, we detail the K-of-N Composite signature definition and two associated algorithms for signature generation and validation. Although K-of-N Composite signatures are defined as a sequence of component signatures, as detailed in many parts of this document and in alignment with Explicit Composite processes, the sign and verify algorithms are to be considered as a single atomic operations.

Signature Data Structures The kofn-CompositeSignatureParams and sa-kofn-CompositeSignature structures are defined as follows:

When a K-of-N Composite Public Key has no defined hashAlgorithm parameter, the signer MUST include the hashAlgorithm parameter in the kofn-CompositeSignatureParams structure to specify which hash algorithm was used to pre-hash the message before signing as described in . When a K-of-N Composite Public Key has the hashAlgorithm parameter defined, the signer MUST NOT include the hashAlgorithm parameter in the kofn-CompositeSignatureParams structure. In case both the K-of-N Composite Public Key and the kofn-CompositeSignatureParams structure contain the hashAlgorithm parameter, the verifier MUST ignore the hashAlgorithm parameter from the kofn-CompositeSignatureParams structure and use the one from the K-of-N Composite Public Key.

Cryptographic Primitives In this section we define K-of-N Composite Signatures as a cryptographic primitive that consists of three algorithms. The first one is the kofn-KeyGen() and is defined in . The remaining two algorithms are the Sign() and Verify() algorithms, which are defined in and respectively and can be summarized as follows: kofn-Sign(sk, Message) -> (signature): A signing algorithm which takes as input a secret key sk and a Message, and outputs a signature. kofn-Verify(pk, Message, signature) -> true or false: A verification algorithm which takes as input a public key, a Message, an optional hashing algorithm, and a signature and outputs true if the signature and public key can be used to verify the message. Thus it proves the Message was signed with the secret key associated with the public key and verifies the integrity of the Message. If the signature and public key cannot verify the Message, it returns false.

The kofn-Sign() primitive When using K-of-N Composite Private Keys to generate signatures, the process is the same as in the Explicit Composite case (see section 5.1 of ). Specifically, the generation of a K-of-N Composite signature involves pre-hashing the message to be signed with key-binding data to provide non-separability properties for the signature, and then applying each component algorithm's signature process to the modified input message according to its specification. Each component signature value is then placed into the CompositeSignatureValue structure defined in . The following process is used to generate composite signature values.

(signature) Input: K1..KN Signing private keys for each component. See note below on composite inputs. A1..AN Component signature algorithms. See note below on composite inputs. Message The Message to be signed, an octet string HASH The Message Digest Algorithm used for pre-hashing. See section on pre-hashing below. OID The Composite Signature String Algorithm Name converted from ASCII to bytes. See section on OID concatenation below. Output: signature The composite signature, a CompositeSignatureValue Signature Generation Process: 1. Compute a Hash of the Message M' = HASH(Message) 2. Generate the n component signatures independently, according to their algorithm specifications. S1 := Sign( K1, A1, DER(OID) || DER(kofn-CompositeKeyParams) || M' ) ... SN := Sign( KN, AN, OID || M' ) 3. Encode each component signature S1..SN into a sequence of BIT STRING according to its algorithm specification. signatureComponent ::= BIT STRING signature ::= SEQUENCE (1..N) OF signatureComponent 4. Output signature ]]>

Note on composite inputs: the method of providing the list of component keys and algorithms is flexible and beyond the scope of this pseudo-code. When passed to the Composite Sign(sk, Message) API the sk is a kofn-CompositePrivateKey. It is possible to construct a kofn-CompositePrivateKey from component keys stored in separate software or hardware keystores. Variations in the process to accommodate particular private key storage mechanisms are considered to be conformant to this document so long as it produces the same output as the process sketched above. Since recursive composite public keys are disallowed, no component signature may itself be a composite of any kind (K-of-N or Explicit); this means that the signature generation process MUST fail if one of the private keys K1..KN is a composite. A composite signature MUST produce, and include in the output, a signature value for every component key in the corresponding kofn-CompositePublicKey, and they MUST be in the same order; ie in the output, S1 MUST correspond to K1, S2 to K2, ..., and SN to KN.

The kofn-Verify() primitive When validating composite signatures generated via id-kofn-CompositeCrypto algorithm, the validation procedures, when compared to the Explicit Composite, are modified to allow for a well-defined number of component signatures validation failures to occur before failing the validation of the composite signature as a whole. The possibility to be able to still consider a composite signature valid in the presence of unsupported algorithms is a useful feature for guaranteeing the interoperability of newer devices with older ones that might not be able to correctly process all the algorithms (but they can still validate a subset of them). In fact, when validating signatures generated via MultiKey keys, the total number of successful component signature validations shall be equal or greater than the public key parameter K (when present). After that, additional component signatures' validations may be skipped, if and only if the algorithm is unknown to the crypto layer, without impacting the validity of the whole composite signature. If any of the signatures of supported algorithms should fail the validation, the K-of-N Composite signature validation MUST fail, independently of the value of K. When the public key parameter K is absent or its value is set to the number of components in the signing key (i.e., K = n), the validation process for MultiKey and Composite are the same as they both require the successful validation of all the signatures. When the public key parameter K is set to one (1), the validation process for K-of-N Composite signatures provides support for fully alternative signatures where a single successful component signature's validation validates the whole composite signature. When compared to the composite signatures' validation process, we modify the for..loop cycle where the invalid signature output is not emitted if the algorithm is unknown, but only if the number of unsupported algorithms is greated than the value N - K. The second optimization allowed by MultiKey keys is to be able to consider a composite signature successful right after at least K successful component signatures' validations, without the need for even attempting at performing the remaining ones. The Input and Output definitions are the same as defined in the Explicit Composite case:

The following process is used to perform composite signatures verification with a K-of-N Composite algorithm:

Algorithm Management Traditionally, a public key, certificate, or signature contains a single cryptographic algorithm. To revoke such a certificate due to algorithm depecation we still need to use serial-number-based revocations. However, in a Composite environment (e.g., supported via Explicit Composite, K-of-N Composite, or other Hybrid approaches), it might be possible to deprecate an entire algorithm and still be able to securely continue performing authentications and validations instead of revoking (or simply distrust) the entire infrastructure (and without adding every single certificate that relies on the deprecated algorithm on the revocation list). By integrating the concept of deprecated algorithms, in the K-of-N case it is possible to dynamically switch among which algorithms are going to be used for signature validations by informing the validating entity about the OIDs of the individual algorithms that are considered "failures". Additionally, by integrating the concept of required algorithms, in the K-of-N case it is possible to make sure that specific algorithms are always required to be supported by the validating entity. This could be the case, for example, when the trust in one of the algorithm might be higher (e.g., certified and/or longer crypto-analysis history).

Validation Policy and Revocation Information As we just mentioned, in multi-algorithm environments, there are situations where the validation of a component signature that carries a deprecated algorithm identifier might still be allowed, e.g. when at least another K algorithms validate correctly. In a K-of-N environment, this means that the device does not need to be re-provisioned (or replaced) and can continue to operate by relying on the non-deprecated algorithm(s). On top of that, there are also typical use-cases where the deprecation of an algorithm is paramount to make sure that authentications do not rely only on deprecated algorithms. This is the case, for example, when older devices that can only successfully validate one algorithm from a composite signature (e.g., it can validate RSA signatures but no other) are still part of the network. When the only algorithm that they can use is deprecated, validation of composite signature MUST fail. The list of deprecated algorithms that are to be considered automatic validation "unknowns" can be directly configured as a parameter in the validating entity's process, or by accessing a trusted source of information such as a trusted Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) response. Similarly, the list of required algorithms that cannot be skipped, even if not supported by the device can be directly configured as a parameter in the validating entity's process, or by accessing a trusted source of information such as a trusted Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) response.

The DeprecatedKeyTypes extension In an ecosystem such as the Internet PKI or IoT PKIs, since algorithm deprecation can be seen as another form of (mass) revocation, a convenient mechanism to distribute the list of deprecated algorithms by adding a specific extension to Certificate Revocation Lists or Online Certificate Status Protocol responses. We define a new DeprecatedKeyTypes extension together with the associated id-ce-deprecatedKeyTypes identifier. The data structure of the extension is defined as a SEQUENCE of OBJECT IDENTIFIER. The corresponding ASN.1 structures are defined as follows:

When this extension is present in a CRL or OCSP response, the validating party MUST consider the algorithms listed in the extension as "unknown", even in the case where the algorithm is supported by the device. At a practical level, this means that the validation of a component signature that carries a deprecated algorithm identifier MUST fail if the threshold (or K-of-N) validations is not met because of the deprecation of algorithms. For example, let's imagine a K-of-N Composite key that combines AlgorithmA and AlgorithmB together. Let's also imagine that a device can only validate AlgorithmA and does not have support for AlgorithmB. If the K-of-N threshold is set to 1, then the device can still validate the composite signature since it can still rely on AlgorithmA. However, if AlgorithmA is deprecated via the DeprecatedKeyTypes extension, then the validation MUST fail because the device can no longer rely on AlgorithmA.

The RequiredKeyTypes extension When backward or forward compatibility is required, it might be useful to provide the possibility to pin specific algorithms to be required to be supported during signature and validations processes. For example, when a K-of-N is used with N = 3 and K =2, there migth be requirements to make sure that one of the two required algorithms to be validated is a specific one (e.g., AlgorithmA). To handle this situation, we define a new RequiredKeyTypes extension, together with the associated id-ce-requiredKeyTypes identifier, that can be added to Certificate Revocation Lists , Online Certificate Status Protocol responses. We define a new RequiredKeyTypes extension together with the associated id-ce-requiredKeyTypes identifier. The data structure of the extension is defined as a SEQUENCE of OBJECT IDENTIFIER. The corresponding ASN.1 structures are defined as follows:

IANA Considerations No IANA actions are required by this document.

Security Considerations TBD.

Contributors and Acknowledgements This document incorporates contributions and comments from a large group of experts. The Editors would especially like to acknowledge the expertise and tireless dedication of the following people, who attended many long meetings and generated millions of bytes of electronic mail and VOIP traffic over the past year in pursuit of this document: Serge Mister (Entrust), Scott Fluhrer (Cisco Systems), Klaus-Dieter Wirth (D-Trust), and Francois Rousseau. We are grateful to all, including any contributors who may have been inadvertently omitted from this list. This document borrows text from similar documents, including those referenced below. Thanks go to the authors of those documents. "Copying always makes things easier and less error prone" - .

&I-D.ounsworth-pq-composite-keys; &I-D.ounsworth-pq-composite-sigs; ITU-T &RFC2119; &RFC8174; &RFC5280; &RFC5958; &RFC7292; &RFC4210; &RFC4211; &RFC6960; &RFC8411; &I-D.driscoll-pqt-hybrid-terminology;

ASN.1 Module

Intellectual Property Considerations The following IPR Disclosure relates to this draft: https://datatracker.ietf.org/ipr/3588/

Making contributions Additional contributions to this draft are welcome. Please see the working copy of this draft at, as well as open issues at: https://github.com/EntrustCorporation/draft-klaussner-pala-composite-kofn