]>

The Netherlands dirk@ddoesburg.nl

Operations and Management SIDR Operations This document specifies the Null Scheme for use in Signed Objects in the Resource Public Key Infrastructure (RPKI). The Null Scheme is a niche signature scheme that can replace the redundant and costly use of actual digital signatures from so-called "one-time-use" key pairs in Signed Objects. The Null Scheme has as public key the digest of the message to be signed, and the signature is always empty. When a Null Scheme public key is the subject of a Signed Object's one-time-use End-Entity (EE) certificate, it establishes a secure binding between the issuer of the EE certificate and the message to be signed. This is cheaper in terms of size and verification time than using a real signature scheme, while providing the same security guarantees. About This Document Status information for this document may be found at . Discussion of this document takes place on the SIDR Operations Working Group mailing list (), which is archived at . Subscribe at .

Introduction This document specifies the Null Scheme for use in Signed Objects in the Resource Public Key Infrastructure (RPKI) . The Null Scheme is a niche signature scheme that can replace the redundant and costly use of actual digital signatures from so-called "one-time-use" key pairs in RPKI Signed Objects . Signed Objects contain an End-Entity (EE) certificate issued by a Certificate Authority (CA). This EE certificate usually contains a public key corresponding to a one-time-use key pair, which is used to sign a single CMS signed-data object . The practice of using each key pair for only one Signed Object enables the use of a CRL to revoke individual objects. However, it means that each Signed Object consists of two signatures and a public key, whereas, intuitively, only one signature should be needed to bind the object to its issuer. The Null Scheme is not an actual digital signature algorithm, or even a One-Time Signature : it requires the (single) message to be signed to be known before the public key can be generated. Essentially, the Null Scheme works as follows:

• the public key is the digest of the single message to be signed,
• there is no private key, and
• the signature is always empty.

Signature generation has to happen together with generation of the public key, taking the message to be signed as input. A public key cannot be generated without the message being known in advance. Verification is done by simply comparing the message digest with the public key. As the input to a signing algorithm when signing a CMS signed-data object is the output of the Message Digest Calculation Process defined in , the Null Scheme's public key is technically directly the input of the signing algorithm, rather than a digest of that input. This avoids an unnecessary extra hashing step.

Requirements Language 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 BCP 14 when, and only when, they appear in all capitals, as shown here.

Related Work The Null Scheme is inspired by the idea that the one-time-use key pairs in RPKI Signed Objects could be replaced using One-Time Signature (OTS) algorithms, such as hash-based Lamport or Winternitz signatures as used in XMSS and LMS . While this could be a suitable post-quantum alternative to current signature schemes, these hash-based OTS algorithms have large signatures. It was then observed that the requirements for the one-time-use key pairs in Signed Objects are even weaker than those offered by OTS algorithms: it is possible to know the message to be signed before generating the key pair. The Null Scheme takes advantage of this to achieve optimal size and verification time while preserving the structure and validation process of Signed Objects. This makes it possible to introduce the Null Scheme in the RPKI without requiring any changes to its specifications such as and : only the algorithms specification needs to be updated.

Attribute Certificates Several other niche signature schemes exist that have some similarities to the Null Scheme, but serve a different purpose. describes the use of 'Attribute Certificates' that can allow something other than a public key to be the subject of an X509 certificate. Through using the 'ObjectDigestInfo' holder type (see ) something equivalent to the Null Scheme can be achieved: the 'holder' of an Attribute Certificate is the digest of an RPKI Signed Object's payload. However, compared to the Null Scheme, using Attribute Certificates in place of plain X.509 EE certificates would require much more extensive changes to the RPKI specifications, making it operationally less practical to introduce.

No-Signature and define a No-Signature algorithm for signatures in X.509 certificates and CMS signed-data objects. These specifications are intended for use-cases where a signature is not needed at all. However, in RPKI Signed Objects, something is needed to bind the Signed Object to an EE certificate. This can be achieved by removing the signature from the CMS signed-data (as in the No-Signature scheme) only if the signed-data is linked to the EE certificate in some other way. That binding is provided by the Null Scheme through the EE certificate's public key. Many alternative ways to provide such a binding exist (such as using Attribute Certificates as mentioned above), but require more extensive changes to the structure of Signed Objects.

Relying on digest in Manifests Another more radical way of reducing the cryptographic overhead in the RPKI is to remove the CMS signed-data wrapper and EE certificate from Signed Objects (other than Manifests ) entirely, and instead rely on the digest of the Signed Object being listed in a valid Manifest. This is a major change to the workings of the RPKI. It would reduce the cryptographic overhead much more (removing a public key and not one but two signatures per object), but would be very hard to introduce in practice.

Definition The Null Scheme MUST only be used to sign and verify the CMS signed-data object contained in an RPKI Signed Object . Consequently, when it is used, a Null Scheme public key appears as the subject of a one-time-use EE certificate attached in the certificates field of the Signed Object's CMS signed-data object. The Null Scheme signature appears in the single SignerInfo object included in the signed-data object's signerInfos field. As the Null Scheme requires the message to be signed to be known before the public key can be generated, it consists of two algorithms: SignOnce and Verify, rather than the usual KeyGen, Sign, and Verify algorithms.

Public Key and Signature Generation The SignOnce algorithm takes as input the message to be signed m. It produces as output a public key pk and a signature sig. As the Null Scheme must only be used to sign CMS signed-data objects, the input message m is the output of the Message Digest Calculation Process defined in . Therefore, although the Null Scheme's public key is always a digest of the message, the SignOnce algorithm actually returns its input m directly. The digest algorithm used is indicated by the SignerInfo object's digestAlgorithm field.

Algorithm SignOnce(m)

Signature Verification The Verify algorithm takes as input a message m, a public key pk, and a signature sig. Like SignOnce, the input m is the output of the Message Digest Calculation Process defined in . It produces as output either "valid" or "invalid".

Algorithm Verify(m, pk, sig)

ASN.1 Module

Security Considerations

Security Reduction to Second-Preimage Resistance Although the Null Scheme cannot be used as a general-purpose digital signature algorithm, it does provably provide the same security properties that are expected from normal digital signatures. Given a public key pk and corresponding message-signature pair (m, sig), finding another valid message-signature pair (m', sig') is clearly impossible: a pair (m', sig') is only valid under public key pk if m' == pk and sig' == "", and therefore m' == m. As the Null Scheme is used to sign CMS signed-data objects, it is, as with any other signature scheme, possible for two distinct messages to lead to the same message digest. Finding such a second message m' given a message m that is valid under public key pk is breaking the second-preimage resistance of H. This would not only allow forging (or reusing) a Null Scheme signature on m', but also reusing the signature of any other signature scheme. This makes the Null Scheme strictly no less secure than any other signature scheme paired with the same digest algorithm H.

IANA Considerations IANA is requested to allocate a value from the "SMI Security for S/MIME Module Identifier" registry for the ASN.1 module RPKINullScheme2025 defined in this document, and a value for id-RPKI-NULL-SCHEME-SHA256 from the "SMI Security for PKIX Algorithms" registry . Editorial note: the assigned OID values will need to be added in the ASN.1 module, and test vectors regenerated using the definitive value for id-RPKI-NULL-SCHEME-SHA256.

References Normative References This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. [STANDARDS-TRACK] This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK] This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK] This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] When the Public-Key Infrastructure using X.509 (PKIX) Working Group was chartered, an object identifier arc was allocated by IANA for use by that working group. This document describes the object identifiers that were assigned in that arc, returns control of that arc to IANA, and establishes IANA allocation policies for any future assignments within that arc. National Institute of Standards and Technology (U.S.) In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. [STANDARDS-TRACK] This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures. This note describes the eXtended Merkle Signature Scheme (XMSS), a hash-based digital signature system that is based on existing descriptions in scientific literature. This note specifies Winternitz One-Time Signature Plus (WOTS+), a one-time signature scheme; XMSS, a single-tree scheme; and XMSS^MT, a multi-tree variant of XMSS. Both XMSS and XMSS^MT use WOTS+ as a main building block. XMSS provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions. XMSS provides strong security guarantees and is even secure when the collision resistance of the underlying hash function is broken. It is suitable for compact implementations, is relatively simple to implement, and naturally resists side-channel attacks. Unlike most other signature systems, hash-based signatures can so far withstand known attacks using quantum computers. This note describes a digital-signature system based on cryptographic hash functions, following the seminal work in this area of Lamport, Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in 1995. It specifies a one-time signature scheme and a general signature scheme. These systems provide asymmetric authentication without using large integer mathematics and can achieve a high security level. They are suitable for compact implementations, are relatively simple to implement, and are naturally resistant to side-channel attacks. Unlike many other signature systems, hash-based signatures would still be secure even if it proves feasible for an attacker to build a quantum computer. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This has been reviewed by many researchers, both in the research group and outside of it. The Acknowledgements section lists many of them. This specification defines a profile for the use of X.509 Attribute Certificates in Internet Protocols. Attribute certificates may be used in a wide range of applications and environments covering a broad spectrum of interoperability goals and a broader spectrum of operational and assurance requirements. The goal of this document is to establish a common baseline for generic applications requiring broad interoperability as well as limited special purpose requirements. The profile places emphasis on attribute certificate support for Internet electronic mail, IPsec, and WWW security applications. This document obsoletes RFC 3281. [STANDARDS-TRACK] This document defines the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This protocol addresses two immediate needs within the Internet Public Key Infrastructure (PKI) community: 1. The need for an interface to public key certification products and services based on CMS and PKCS #10 (Public Key Cryptography Standard), and 2. The need for a PKI enrollment protocol for encryption only keys due to algorithm or hardware design. CMC also requires the use of the transport document and the requirements usage document along with this document for a full definition. [STANDARDS-TRACK] Google LLC This document defines a placeholder X.509 signature algorithm that may be used in contexts where the consumer of the certificate does not intend to verify the signature. MSc Thesis, Radboud University SRI International, CSL-98

Test Vectors The following test vector is a base-64 encoded RPKI Signed Object containing an EE certificate with as subject a Null Scheme public key matching the signed content. The EE certificate is issued by an RSA key pair, whose public key is also added below. Editorial note: the test vectors below are generated using placeholder OID value 1.3.6.1.4.1.64241.1.1 for id-RPKI-NULL-SCHEME-SHA256. Once IANA has assigned a value, the test vectors will need to be regenerated using that definitive OID value.

RPKI Signed Object with Null Scheme EE Certificate

The EE certificate in the Signed Object is issued with the following RSA public key:

RSA Public Key of EE Certificate Issuer

Acknowledgments The author would like to thank Moritz Müller, Ralph Koning and Lisa Bruder who supervised the thesis that led to the idea of the Null Scheme, and especially to Job Snijders for his valuable comments and suggestions on earlier drafts of this document.