| Internet-Draft | Null Scheme for the RPKI | September 2025 |
| Doesburg | Expires 10 March 2026 | [Page] |
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.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-doesburg-sidrops-nullscheme/.¶
Discussion of this document takes place on the SIDR Operations Working Group mailing list (mailto:sidrops@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/sidrops/. Subscribe at https://www.ietf.org/mailman/listinfo/sidrops/.¶
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 10 March 2026.¶
Copyright (c) 2025 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.¶
This document specifies the Null Scheme for use in Signed Objects in the Resource Public Key Infrastructure (RPKI) [RFC6480]. 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 [RFC6488].¶
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 [RFC5652]. The practice of using each key pair for only one Signed Object enables the use of a CRL [RFC5280] 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 [OTS]: 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 Section 5.4 of [RFC5652], 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The Null Scheme MUST only be used to sign and verify the CMS signed-data object contained in an RPKI Signed Object [RFC6488].
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.¶
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 Section 5.4 of [RFC5652]. 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.¶
1. pk = m # The output of the message digest calculation process 2. sig = "" # Empty octet string 3. return (pk, sig)
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 Section 5.4 of [RFC5652]. It produces as output either "valid" or "invalid".¶
1. if sig == "" and pk == m then return "valid" 2. return "invalid"
RPKINullScheme2025
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) null-scheme-2025(TBD) }
--
-- TODO: module ID to be replaced by IANA
--
DEFINITIONS IMPLICIT TAGS ::= BEGIN
EXPORTS ALL;
IMPORTS
PUBLIC-KEY, SIGNATURE-ALGORITHM
FROM AlgorithmInformation-2009 -- RFC 5912
{ iso(1) i id-mod(0)
id-mod-algorithmInformation-02(58) }
;
--
-- TODO: OIDs to be replaced by IANA
--
id-RPKI-NULL-SCHEME OBJECT IDENTIFIER ::= {
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) alg(6) TBD
}
pk-RPKI-NULL-SCHEME PUBLIC-KEY ::= {
IDENTIFIER id-RPKI-NULL-SCHEME
-- The digest algorithm used to determine the input to the signing / verification
-- algorithms is determined by the SignerInfo's digestAlgorithm field. The signing
-- and verification algorithms themselves are not dependent on the digest algorithm,
-- so we don't need PARAMS or distinct OIDs for pairing different digest algorithms.
PARAMS ARE absent
-- A Null Scheme public key should only be certified by EE certificates.
-- So, in accordance with RFC6487, only the digitalSignature bit is valid.
CERT-KEY-USAGE {digitalSignature}
}
sa-RPKI-NULL-SCHEME SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-RPKI-NULL-SCHEME
PARAMS ARE absent
PUBLIC-KEYS {pk-RPKI-NULL-SCHEME}
}
END
¶
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 is requested to allocate a value from the "SMI Security for S/MIME Module Identifier" registry [RFC7299] 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 [RFC7299].¶
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.¶
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.¶
MIIExwYJKoZIhvcNAQcCoIIEuDCCBLQCAQMxDTALBglghkgBZQMEAgEwKAYLKoZI hvcNAQkQARigGQQXMBUCAQUwEDAOBAIAATAIMAYDBAB7DCKgggPLMIIDxzCCAq+g AwIBAgIUfsjuEOuYMPFgVb8W26Oa9upWd3owDQYJKoZIhvcNAQELBQAwMzExMC8G A1UEAxMoRTU4QzAzRjlGQUNDM0I5QUIxMEY3OEJEQTZDODZDNkQ1N0IyNTBGMzAe Fw0yNTA5MTkxODQ5MzNaFw0yNjA5MTgxODU0MzNaMDMxMTAvBgNVBAMTKDhGQjJE NkY0MjkzNTNCMENBRTQ0MDM5NjRDOUI3MDk3N0I5M0RDMDAwMTAMBgorBgEEAYP1 cQEBAyEAs4nZPXR8JArehzIBiIrCTWPw2Hw2w+m5L+uO+7aW7FmjggHEMIIBwDAd BgNVHQ4EFgQUj7LW9Ck1OwyuRAOWTJtwl3uT3AAwHwYDVR0jBBgwFoAU5YwD+frM O5qxD3i9pshsbVeyUPMwDgYDVR0PAQH/BAQDAgeAMFwGA1UdHwRVMFMwUaBPoE2G S3JzeW5jOi8vbG9jYWxob3N0L3JlcG8vY2hpbGQvMC9FNThDMDNGOUZBQ0MzQjlB QjEwRjc4QkRBNkM4NkM2RDU3QjI1MEYzLmNybDBoBggrBgEFBQcBAQRcMFowWAYI KwYBBQUHMAKGTHJzeW5jOi8vbG9jYWxob3N0L3JlcG8vb25saW5lLzAvRTU4QzAz RjlGQUNDM0I5QUIxMEY3OEJEQTZDODZDNkQ1N0IyNTBGMy5jZXIwawYIKwYBBQUH AQsEXzBdMFsGCCsGAQUFBzALhk9yc3luYzovL2xvY2FsaG9zdC9yZXBvL2NoaWxk LzAvMzEzMjMzMmUzMTMyMmUzMzM0MmUzMDJmMzIzNDJkMzIzNDIwM2QzZTIwMzUu cm9hMBgGA1UdIAEB/wQOMAwwCgYIKwYBBQUHDgIwHwYIKwYBBQUHAQcBAf8EEDAO MAwEAgABMAYDBAB7DCIwDQYJKoZIhvcNAQELBQADggEBAI/6f6QVtlCDdeUtSaDY +hcI3MQy8I68o3u7dBK492bzhEHX94EbXF8vJCqqckBCHUUJwOb2MfUiUq0ZjUyG baBksk+4k55CaFTi0QAgbnCYZ+08bTCd61yc7bYiyPpHOW3MWX9evTir+h2uFJyT ETWtkb7APGJgTA9KtIxCj2rNveKv+gmci/mi3FMELLn/y0QAexBMVPIyU142KUrM X5SeHvHYz9QzXwpyhKVeyqD3wMTe+I70mEMnCjMZTHGSYsfykXbXKmAmnk76SB7n C1MCy8BhCUBLBAn+QcK4aTpqVi3i/2V2a3EZm+nfcNB/kb/wMCCYawrS6XjFpWL8 LoYxgaYwgaMCAQOAFI+y1vQpNTsMrkQDlkybcJd7k9wAMAsGCWCGSAFlAwQCAaBr MBoGCSqGSIb3DQEJAzENBgsqhkiG9w0BCRABGDAcBgkqhkiG9w0BCQUxDxcNMjUw OTE5MTg1NDMzWjAvBgkqhkiG9w0BCQQxIgQgaoUbRc3K1OCIGMdQhz9HjaFxJhrc dEXSKTTashDvSv0wDAYKKwYBBAGD9XEBAQQA
The EE certificate in the Signed Object is issued with the following RSA public key:¶
-----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2nyEbcU+KLPQYfV+NYVD 2GVy06sXSoWSMbHl4BNgpkyaVT+wmXfiBq5RT33Nb5bm6mNsX6rZzRBm9BT6p5wb y+eMpVHqbrLb4JfBXSQnq+7132iTkfgBbIt5v5Z2Ly6UfiBb/Ftpz/5NeYpDpd65 A0qngooYjY6Loyjvfoa53Rc40/bfWGkValseQ0qrww9t3ztejpWUIY8p5FzNdjeV XfkB1DgMmllLAUcRb+yC844oEGNJyZL1Stspo9+HVLUOUUXpoylXjd7rOStuq8Y1 JGa6VWHq6q0hwd67oEcZRwGmExJKhvuRPy+Udk1a2S3X60s9pqMOd4Soo5cKtul4 ZQIDAQAB -----END PUBLIC KEY-----
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.¶