Convertible Forms with Multiple Keys and Signatures For Use In Internet X.509 Certificates
draft-sun-lamps-hybrid-scheme-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Sun Shuzhou , Yidi He , Hsiao-Ying Lin | ||
| Last updated | 2024-10-16 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sun-lamps-hybrid-scheme-00
LAMPS S. Sun
Internet-Draft Y. He
Intended status: Standards Track H. Y. Lin
Expires: 20 April 2025 Huawei
17 October 2024
Convertible Forms with Multiple Keys and Signatures For Use In Internet
X.509 Certificates
draft-sun-lamps-hybrid-scheme-00
Abstract
This document presents a hybrid key and signature solution, which
allows to integrate two public keys and/or two signatures into a
single certificate. The scheme enables a single certificate to be
converted between different forms, allowing an alternative public key
and/or an alternative signature to be transmitted either by direct
inclusion or by referencing external data. This flexibility ensures
that the scheme is backward-compatible with legacy devices, while
also providing enhanced security support for upgraded devices. Four
CSR attributes and two new X.509v3 certificate extensions are
defined, and the procedures for signing and verifying certificates
containing the defined attributes and extensions are described.
Status of This Memo
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 20 April 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Sun, et al. Expires 20 April 2025 [Page 1]
Internet-Draft Convertible Forms In Certificates October 2024
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 4
3. Alternative Public-Key Algorithm Objects . . . . . . . . . . 5
3.1. OIDs . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. CSR Attributes . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Alternative Subject Public Key Hash Algorithm
Attribute . . . . . . . . . . . . . . . . . . . . . . 6
3.2.2. Alternative Subject Public Key Location Attribute . . 6
3.2.3. Alternative Signature Value Hash Algorithm
Attribute . . . . . . . . . . . . . . . . . . . . . . 6
3.2.4. Alternative Signature Value Location Attribute . . . 7
3.3. X.509v3 Extension . . . . . . . . . . . . . . . . . . . . 7
3.3.1. Alternative Subject Public Key Extension . . . . . . 7
3.3.2. Alternative Signature Extension . . . . . . . . . . . 8
4. Scheme Workflow: From CSR to Signed Certificate . . . . . . . 9
4.1. Creating CSRs . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Verifying CSRs . . . . . . . . . . . . . . . . . . . . . 10
4.3. Creating Certificates . . . . . . . . . . . . . . . . . . 11
4.3.1. Creating AltSubPubKeyExt extension and
preTbsCertificate . . . . . . . . . . . . . . . . . . 11
4.3.2. Creating AltSignatureExt extension and
tbsCertificate . . . . . . . . . . . . . . . . . . . 12
4.3.3. Creating Certificate . . . . . . . . . . . . . . . . 13
4.4. Converting Forms of Certificates . . . . . . . . . . . . 13
4.4.1. Converting Forms of Extensions . . . . . . . . . . . 13
4.4.2. Converting Forms of Certificates . . . . . . . . . . 14
4.5. Verifying Certificates . . . . . . . . . . . . . . . . . 15
4.6. Revoking Certificates . . . . . . . . . . . . . . . . . . 16
5. Use Case: Post-Quantum Migration . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Appendix 1 [REPLACE/DELETE] . . . . . . . . . . . . 19
Sun, et al. Expires 20 April 2025 [Page 2]
Internet-Draft Convertible Forms In Certificates October 2024
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
The advent of quantum computing poses a significant threat to the
security of traditional cryptographic systems. Classical
cryptographic algorithms, such as RSA, ECDSA, and their elliptic
curve variants, rely on the computational difficulty of certain
number-theoretic problems. However, these algorithms are vulnerable
to attacks by adversaries with access to a Cryptograpically-Relevant
Quantum Computer (CRQC), which can efficiently solve these problems
and compromise the security of the entire system.
To address this vulnerability, there is a pressing need to migrate to
post-quantum cryptography (PQC), which employs algorithms resistant
to quantum attacks. This transition presents unique challenges, as
the security of PQC algorithms is not yet fully established and
requires extensive evaluation. Additionally, during the migration
period, systems must maintain compatibility with legacy devices that
do not support PQC.
This document introduces new Certificate Signing Request (CSR)
attributes and X.509v3 certificate extensions to facilitate the
migration of post-quantum signature algorithms while ensuring
compatibility with existing systems. A key design requirement for
this scheme is to enable the coexistence of two public keys and two
signatures within a single certificate, and allowing for switching
between four distinct certificate forms during transmission without
impacting verification.
By embedding an alternative public key and an alternative signature
into extensions, multiple certificate chains can be effectively
embedded within a single chain. This enables legacy devices to
continue using traditional cryptographic algorithms, while upgraded
devices can utilize PQC algorithms and remain interoperable with
legacy devices. The scheme also allows for the flexible selection of
certificate forms, including both "by reference" and "by value"
options, to accommodate different device scenarios and optimize
bandwidth usage.
1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Sun, et al. Expires 20 April 2025 [Page 3]
Internet-Draft Convertible Forms In Certificates October 2024
1.2. Terminology
Alternative Subject Public Key: The keys, whose usage is profiled in
this document, which can be used to verify a signature instead of, or
in addition to, the traditional keys.
Alternative Signature: The signature, whose usage is profiled in this
document, which can be used to validate a certificate instead of, or
in addition to, the traditional signature.
Subscriber: An entity that applies a signed certificate.
Relying Party: An entity that receives and verifies certificates.
Issuer: An entity that signs and issues certificates;
Upgraded Device: An entity which is capable of understanding and
using the extensions introduced in this document.
2. Design Overview
+------------+ CSR (pk_1, pk_2, sig_1, sig_2) +------------+
| Subscriber | ----------------------------------------> | Issuer |
| sk_1, sk_2 | <---------------------------------------- | sk_3, sk_4 |
+------------+ Certificate (pk_1, pk_2, sig_3, sig_4) +------------+
^ ^ ^
| | |
| | | ByRef Certificate (pk_1, hash(pk_2), hash(sig_3), sig_4)
| | +---------------------------------------------------+
| | |
| | ByVal Certificate (pk_1, pk_2, sig_3, sig_4) |
| | or ByRef Certificate |
| +------- ------------------------------+ |
| | |
v v v
+-------------+ Download data +------------------+ +----------------+
| Store | <-------------> | Upgraded Devices | | Legacy Devices |
| pk_2, sig_3 | | pk_3, pk_4 | | pk_4 |
+-------------+ +------------------+ +----------------+
Figure 1: Design Overview
To achieve hybrid signatures in a PKI system, a subscriber needs to
apply a certificate that contains two public keys to use hybrid
signature schemes. Meanwhile, the issuer needs to sign a certificate
with two secret keys and include two signatures in the certificate.
The design of this document is outlined as follows:
Sun, et al. Expires 20 April 2025 [Page 4]
Internet-Draft Convertible Forms In Certificates October 2024
1. A subscriber selects two signature algorithms and generates two
key pairs (pk_1, sk_1) and (pk_2, sk_2). It then uses sk_1 and
sk_2 to generate sig_1 and sig_2, respectively. The signatures
are proof-of-possession of the secret keys sk_1 and sk_2. The
two public keys and signatures are included in a Certificate
Signing Request as defined in Section 4.1.
2. An issuer holds two key pairs (pk_3, sk_3) and (pk_4, sk_4).
Upon receiving a CSR, the issuer uses its two secret keys to sign
the information provided in the CSR and constructs a certificate
as defined in Section 4.3. A certificate has at most four forms
as defined in Table 1. The issuer signs Form 4 of the
certificate, which includes the values of pk_1 and sig_4, and the
hashes of pk_2 and sig_3. The issuer converts the certificate to
Form 1 as in Section 4.4, which includes all plain values, and
sends the certificate in Form 1 to the subscriber.
3. Upon receiving the certificate, a subscriber puts the alternative
public key pk_2 and the alternative signature sig_3 into specific
locaitons.
4. For legacy devices that have not been upgraded, only traditional
algorithms are used to establish communication with the
subscriber. In this case, certificates in Form 4 are transfered,
which only include pk_1, sig_4 and hashes of pk_2 and sig_3.
5. For upgraded devices, both traditional algorithms and post-
quantum algorithms can be used. In this case, the devices can
select a proper certificate form base on their preferences.
3. Alternative Public-Key Algorithm Objects
3.1. OIDs
The following OIDs are used to identify the CSR attributes and
X.509v3 extensions defined in the subsequent sections.
id-altSubPubKeyHashAlgAttr OBJECT IDENTIFIER ::= {TBD}
id-altSubPubKeyLocAttr OBJECT IDENTIFIER ::= {TBD}
id-altSigValueHashAlgAttr OBJECT IDENTIFIER ::= {TBD}
id-altSigValueLocAttr OBJECT IDENTIFIER ::= {TBD}
id-altSubPubKeyExt OBJECT IDENTIFIER ::= {TBD}
id-altSignatureExt OBJECT IDENTIFIER ::= {TBD}
Sun, et al. Expires 20 April 2025 [Page 5]
Internet-Draft Convertible Forms In Certificates October 2024
3.2. CSR Attributes
Four new CSR attributes are defined. The first two attributes are
used to submit associated information about the alternative public
key of the subscriber for certification. The latter two attributes
specify parameters related to the alternative signature generated by
the issuer. A CSR MAY include any one or multiple of these
attributes.
3.2.1. Alternative Subject Public Key Hash Algorithm Attribute
This attribute specifies the identifier for the algorithm used to
hash the alternative public key of a subscriber. The
AlgorithmIdentifier type is defined in Section 4.2 of [RFC2986].
This attribute is identified using the id-altSubPubKeyHashAlgAttr
OID.
altSubPubKeyHashAlgAttr ATTRIBUTE ::= {
WITH SYNTAX AlgorithmIdentifier
ID id-altSubPubKeyHashAlgAttr }
3.2.2. Alternative Subject Public Key Location Attribute
This attribute specifies a URI indicating the location where the
alternative public key will be stored. This attribute MAY be
omitted, if the subscriber and the relying partiy wish to establish a
mutually agreed-upon location through external means. The details of
this negotiation are outside the scope of this document.
This attribute is identified using the id-altSubPubKeyLocAttr OID.
altSubPubKeyLocAttr ATTRIBUTE ::= {
location URI
ID id-altSubPubKeyLocAttr }
3.2.3. Alternative Signature Value Hash Algorithm Attribute
This attribute specifies the identifier for the algorithm used to
hash the alternative signature generated by an issuer.
This attribute is identified using the id-altSigValueHashAlgAttr OID.
altSigValueHashAlgAttr ATTRIBUTE ::= {
WITH SYNTAX AlgorithmIdentifier
ID id-altSigValueHashAlgAttr }
Sun, et al. Expires 20 April 2025 [Page 6]
Internet-Draft Convertible Forms In Certificates October 2024
3.2.4. Alternative Signature Value Location Attribute
This attribute specifies a URI indicating the location where the
alternative signature generated by the issuer can be stored. The
subscriber will store the alternative signature once received from
the issuer. This attribute MAY be omitted, if the subscriber and the
relying party wish to establish a mutually agreed-upon location
through external means. The details of this negotiation are outside
the scope of this document.
This attribute is identified using the id-altSigValueLocAttr OID.
altSigValueLocAttr ATTRIBUTE ::= {
location URI
ID id-altSigValueLocAttr }
3.3. X.509v3 Extension
Two new X.509v3 extensions are defined. One is designed to include a
subscriber's alternative public key in the certificate, while the
other is designed to include an issuer's alternative signature. Both
extensions have a similar structure.
3.3.1. Alternative Subject Public Key Extension
This extension is identified using the id-altSubPubKeyExt OID.
Conforming issuers MUST mark this extension as non-critical.
This extension, containing the alternative public key and associated
metadata, is the DER encoding of the following structure:
AltSubPubKeyExt ::= SEQUENCE {
byVal BOOLEAN DEFAULT FALSE,
plainOrHash BIT STRING,
altAlgorithm AlgorithmIdentifier,
hashAlg AlgorithmIdentifier OPTIONAL,
location URI OPTIONAL }
The fields of extension AltSubPubKeyExt have the following meanings:
* byVal is a boolean with a default value of FALSE. This field
indicates whether the alternative public key is transferred by its
actual value or by reference, and determines the content of the
plainOrHash field.
Sun, et al. Expires 20 April 2025 [Page 7]
Internet-Draft Convertible Forms In Certificates October 2024
* plainOrHash stores the alternative public key or its hash value.
When byVal is FALSE, the plainOrHash field stores the hash value
of the alternative public key. When byVal is TRUE, plainOrHash
stores the actual value of alternative public key.
* altAlgorithm identifies the algorithm of the alternative public
key.
* hashAlg and location fields are optional. hashAlg field indicates
the algorithm used to hash the alternative public key and location
field represents the location where the actual value of
alternative public key is stored.
3.3.2. Alternative Signature Extension
This extension is identified by the id-altSignatureExt OID.
Conforming issuers MUST mark this extension as non-critical.
This extension contains the alternative signature generated by the
issuer, which is the DER encoding of the following structure:
AltSignatureExt ::= SEQUENCE {
byVal BOOLEAN DEFAULT FALSE,
plainOrHash BIT STRING,
altSigAlgorithm AlgorithmIdentifier,
hashAlg AlgorithmIdentifier OPTIONAL,
location URI OPTIONAL }
The fields of the AltSignatureExt extension have the following
meanings:
* byVal is a boolean with a default value of FALSE. This field
indicates whether the alternative signature is transferred by its
actual value or by reference, and determines the content of the
plainOrHash field.
* plainOrHash stores the alternative signature or its hash value.
When byVal is FALSE, the plainOrHash field stores the hash value
of the alternative signature. When byVal is TRUE, plainOrHash
stores the actual value of signature.
* altSigAlgorithm identifies the algorithm to generate alternative
signature.
Sun, et al. Expires 20 April 2025 [Page 8]
Internet-Draft Convertible Forms In Certificates October 2024
* hashAlg and location fields are optional. hashAlg field indicates
the algorithm used to hash the alternative signature and location
field represents the location where the actual value of
alternative signature is stored.
4. Scheme Workflow: From CSR to Signed Certificate
4.1. Creating CSRs
A Certificate Signing Request (CSR) has three fields, as defined in
Section 4.2 of [RFC2986].
CertificationRequest ::= SEQUENCE {
certificationRequestInfo CertificationRequestInfo,
signatureAlgorithm AlgorithmIdentifier{{ SignatureAlgorithms }},
signature BIT STRING
}
The signature is the result of signing the ASN.1 DER encoding of the
certificationRequestInfo field with a subcriber's private key.
CertificationRequestInfo ::= SEQUENCE {
version INTEGER { v1(0) } (v1,...),
subject Name,
subjectPKInfo SubjectPublicKeyInfo{{ PKInfoAlgorithms }},
attributes [0] Attributes{{ CRIAttributes }}
}
The syntax of CSR allows a subscriber to proof possession of one
secret key. To prove possession of two secret keys, there are many
possible ways. This document adopts the composite signature schemes
as defined in a recent IETF draft
[I.D.draft-ietf-lamps-pq-composite-sigs-02]. Namely, two public keys
are concatenated to obtain a single public key, and two signatures
are concatenated to obtain a single signature. So the syntax of CSR
does not need to be changed. In the following description, the terms
CompositeKeyGen, CompositeSign, and CompositeVerify refer to the
KeyGen, Sign, and Verify algorithms defined in Section 4
of[I.D.draft-ietf-lamps-pq-composite-sigs-02], respectively.
At the same time, the subscriber is allowed to select one hash
algorithm and a location for the alternative subject public key, and
another hash algorithm and location pair for the alternative
signature generated by the issuer. These four fields are included as
additional CSR attributes.
The process of generating a CSR is detailed as follows:
Sun, et al. Expires 20 April 2025 [Page 9]
Internet-Draft Convertible Forms In Certificates October 2024
1. Select two signature algorithms A1 and A2 and calls
CompositeKeyGen algorithms to generate a key pair (pk, sk).
Internally, pk consists of pk_1 and pk_2. sk consists of sk_1 and
sk_2. Some combinations and their identifiers have already been
defined in Section 7. of
[I.D.draft-ietf-lamps-pq-composite-sigs-02]. Specially, pk_2 is
the alternative public key.
2. Construct a CompositeSignaturePublicKey object from the pk as
defined in Section 5.2. of
[I.D.draft-ietf-lamps-pq-composite-sigs-02].
CompositeSignaturePublicKey ::= SEQUENCE SIZE (2) OF BIT STRING
3. Construct a SubjectPublicKeyInfo object from the
CompositeSignaturePublicKey object and the algorithm identifier
of the selected composite signature scheme.
4. Select two hash algorithms: one for hashing alternative public
key pk_2, specified in the altSubPubKeyHashAlgAttr attribute, and
another for hashing alternative signature, specified in the
altSigValueHashAlgAttr attribute. The subscriber MAY leave these
two attributes empty, in which case the hash algorithm specified
in the selected composite signature scheme will be used.
5. Select two locations: one for storing the plain alternative
public key pk_2, specified in altSubPubKeyLocAttr attribute, and
another one for storing the alternative signature, specified in
altSigValueLocAttr attribute. The subscriber MAY leave these two
attributes empty.
6. Construct a CertificationRequestInfo object from the constructed
SubjectPublicKeyInfo object, the four new CSR attributes
(AltPublicKeyHashAlgorithmAttr, altSigValueHashAlgAttr,
altSubPubKeyLocAttr, and altSigValueLocAttr), and other
attributes.
7. Sign the CertificationRequestInfo object with the algorithm
CompositeSign using the private key sk.
8. Construct a CertificationRequest object from the
CertificationRequestInfo object, the identifier of the compsite
signature scheme, and the signature.
4.2. Verifying CSRs
An issuer verifies a CSR by verifying the composite signature using
the algorithm CompositeVerify with the pk extracted from CSR.
Sun, et al. Expires 20 April 2025 [Page 10]
Internet-Draft Convertible Forms In Certificates October 2024
4.3. Creating Certificates
An X.509 digital certificate is a sequence of three fields as defined
in [RFC5280].
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
The tbsCertificate field contains the subject and issuer names, a
public key associated with the subject, a validity period, and other
associated information and extensions.
To include two subject public keys in a certificate, the
AltSubPubKeyExt extension is used to hold the alternative public key.
Meanwhile, if an issuer wants to use two different cryptographic
algorithms to sign a certificate, the AltSignatureExt extension is
used to hold the alternative signature.
To facilitate understanding, a preTbsCertificate is defined, which
has the same type as TBSCertificate:
preTbsCertificate ::= TBSCertificate
The preTbsCertificate is signed by the alternative private key to
generate the alternative signature. This alternative signature is
then used to construct the AltSignatureExt extension, which is
appended to the end of the extension list in the preTbsCertificate,
resulting the tbsCertificate object. In other words, tbsCertificate
is essentially preTbsCertificate appended with the AltSignatureExt
extension.
After verifying a CSR, the issuer proceeds with the certificate
creation process, which can be divided into 3 stages:
1. Creating AltSubPubKeyExt extension and preTbsCertificate.
2. Creating AltSignatureExt extension and tbsCertificate.
3. Creating certificates.
4.3.1. Creating AltSubPubKeyExt extension and preTbsCertificate
To create an AltSubPubKeyExt extension, an issuer does the following
steps:
Sun, et al. Expires 20 April 2025 [Page 11]
Internet-Draft Convertible Forms In Certificates October 2024
1. Extract the two public keys pk_1 and pk_2 from the pk in CSR.
Obtain the two component algorithm identifiers from the composite
signature scheme as defined in Table 2. of
[I.D.draft-ietf-lamps-pq-composite-sigs-02].
2. Construct a SubjectPublicKeyInfo object from pk_1 and the
algorithm identifier of the first public key.
3. Determinate the hash algorithm to be used to generate a hash of
the alternative public key by checking the
AltPublicKeyHashAlgorithmAttr attribute in the CSR. If this
attribute is not present, use the hash algorithm defined in the
composite signature scheme.
4. Compute a hash by hashing pk_2 with the determined hash
algorithm.
5. Construct an AltSubPubKeyExt extension: a) Set the byVal field to
FALSE. b) Set the plainOrHash field to the hash calculated in
step 4. c) Set the altAlgorithm field to the algorithm identifier
of the alternative public key. d) Set the hashAlg to the
identifier of hash algorithm determinated by step 3. e) Set the
location field to the location field given in the
altSubPubKeyLocAttr attribute in the CSR. If this attribute is
not present, leave the location field empty.
After creating an AltSubPubKeyExt extension, an issuer constructs a
TBSCertificate object from attributes in the given CSR following
existing standards, e.g., [RFC2986] and [RFC5280]. The constructed
TBSCertificate object is the preTbsCertificate field, which MUST
inlude the created AltSubPubKeyExt extension.
4.3.2. Creating AltSignatureExt extension and tbsCertificate
To create an AltSignatureExt extension, an issuer does the following
steps:
1. Determine the hash algorithm to be used to generate a hash of the
alternative signature by checking the altSigValueHashAlgAttr
attribute in the given CSR. If this attribute is not present,
use the hash algorithm defined in the composite signature scheme.
2. Sign the preTbsCertificate constructed in Section 4.3.1 with the
issuer's alternative private key to obtain the alternative
signature.
3. Compute a hash by hashing the alternative signature (obtained in
step 2) with the hash algorithm determined in step 1.
Sun, et al. Expires 20 April 2025 [Page 12]
Internet-Draft Convertible Forms In Certificates October 2024
4. Construct an AltSignatureExt extension: a) Set the byVal field to
FALSE. b) Set the plainOrHash field to the hash calculated in
step 3. c) Set the altAlgorithm field to the algorithm identifier
of the alternative signature. d) Set the hashAlg field to the
identifier of the hash algorithm determined in step 1. e) Set the
location field to the location field given in the
altSigValueLocAttr attribute in the CSR. If this attribute is
not present, leave the location field empty.
After creating an AltSignatureExt extension, an issuer obtains a new
TBSCertificate object by appending the created extension to the
extension list of preTbsCertificate.
4.3.3. Creating Certificate
An issuer signs the tbsCertificate with its first private key and
algorithm, and then constructs the digital certificate as defined in
[RFC5280].
Note that the certificate has both the AltSubPubKeyExt and
AltSignatureExt extensions with byVal fields set to FALSE, indicating
that the certificate is signed with the hashes of the alternative
public key and the alternative signature.
4.4. Converting Forms of Certificates
4.4.1. Converting Forms of Extensions
The two newly introduced extensions, AltSubPubKeyExt and
AltSignatureExt, are independent and each can exist in one of two
forms:
* ByValue: The extension provides the actual value of a public key
or a signature. Namely, the plainOrHash field is set to the
actual value, and the byVal field is set to TRUE.
* ByReference: The extension provides the hash of a public key or a
signature. Namely, the plainOrHash field is set to the hash of
the plain value, and the byVal field is set to FALSE.
The exact form of a given extension object can be determined by
checking the byVal field.
To convert a ByValue form to a ByReference form, an entity sets the
byVal field to FALSE, computes the hash of the plainOrHash field, and
replaces the plainOrHash field with its hash.
Sun, et al. Expires 20 April 2025 [Page 13]
Internet-Draft Convertible Forms In Certificates October 2024
To convert a ByReference form to a ByValue form, an entity sets the
byVal field to TRUE, replaces the plainOrHash field with the actual
value. The entity MUST have the actual value of the alternative
public key or the alternative signature.
Note that the other fields in the extensions remain the same in both
forms.
4.4.2. Converting Forms of Certificates
A certificate contains the two proposed extensions can exist in 4
forms as follows.
+========+===================+=================+
| | AltSubKeyValueExt | AltSignatureExt |
+========+===================+=================+
| Form 1 | ByValue | ByValue |
+--------+-------------------+-----------------+
| Form 2 | ByValue | ByReference |
+--------+-------------------+-----------------+
| Form 3 | ByReference | ByValue |
+--------+-------------------+-----------------+
| Form 4 | ByReference | ByReference |
+--------+-------------------+-----------------+
Table 1: Form of Certificate
To convert a certificate from one form to another form, an entity
converts the included extensions from one form to another form
following the Section 4.4.1.
During the issuance of a certificate, Form 4 is the signed form.
After constructing a certificate as in Section 4.3, an issuer MUST
send the certificate in FORM 1 or FORM 3 to the subscriber.
Otherwise, there is no way for the subscriber to obtain the value of
the alternative signature.
During the communication of a subscriber and a relying party, all of
these forms MAY be used to transfer a certificate. However, all
other forms MUST be converted to Form 4 before certificate
verification. Meanwhile, an entity MAY fetch the alternative public
key and/or the alternative signature from the given locations. The
entity MAY also cache the alternative materials locally. Figure 2
shows the example process:
Sun, et al. Expires 20 April 2025 [Page 14]
Internet-Draft Convertible Forms In Certificates October 2024
Issuer Subscriber Relying Party Location
| <------- CSR --------- | | |
|[Sign on Form 4] | | |
| Certificate /Form 1/3--> | | |
| [extract pk_2,sig_3] | |
| | -------------Upload pk_2, sig_3-----------> |
| [Construct Form 1/2/3/4] | |
| | | |
| | | |
| | Certificate /Form 1--> | |
| | [Convert to Form 4] |
| | [verify] |
| | | |
| | Certificate /Form 2--> | |
| | | <----Fetch sig_3-----> |
| | [Convert to Form 4] |
| | [verify] |
| | | |
| | Certificate /Form 3--> | |
| | | <----Fetch pk_2------> |
| | [Convert to Form 4] |
| | [verify] |
| | | |
| | Certificate /Form 4--> | |
| | | <--Fetch pk_2,sig_3--> |
| | [verify] |
Figure 2: Transmission and Verification of Different Certificate
Forms
4.5. Verifying Certificates
Given a certificate, a relying party MAY download the actual value of
a public key or a signature if a extension is given in ByReference
form.
1. Retrieve the external reference address from the location field
in the extension, and fetch the actual value from that address.
If the location attribute is absent, the actual value can be
obtained through other agreed-upon means, i.e., from previous
local cache. If the actual value cannot be obtained, this
procedure fails.
2. Determine the hash algorithm by checking the hashAlg field in the
extension.
3. Compute the hash of the actual value and compare it with the
plainOrHash field. If they do not match, this procedure fails.
Sun, et al. Expires 20 April 2025 [Page 15]
Internet-Draft Convertible Forms In Certificates October 2024
To verify a certificate, a relying party MUST convert it into FORM 4
as described in Section 4.4. After the conversion, the relying party
verifies the signature field using the issuer's public key following
[RFC5280]. Meanwhile, the relying party MAY construct the
PreTBSCertificate object by removing the AltSignatureExt from the
extension list of the TBSCertificate object, and verify the
altSignatureValue field using the issuer's alternative public key.
4.6. Revoking Certificates
In certain situations, certificates must be revoked. This can occur
due to various reasons, such as key compromise, CA compromise, or
changes in affiliation. Generally, Certificate Revocation Lists
(CRLs) are authenticated lists of revoked certificates, as defined in
[RFC5280].
In the context of certificates with multiple keys and signatures, the
compromise of any private key (whether traditional or alternative)
MUST result in the revocation of the entire certificate. Conversely,
if a certificate with multiple keys and signatures is revoked, both
the traditional and alternative keys SHOULD be treated as revoked.
This approach prevents the unnecessary complexity of managing a
certificate where one key is compromised while the other remains
secure.
5. Use Case: Post-Quantum Migration
During the post-quantum migration, there is going to be a long period
of time where legacy devices and upgraded devices coexist. In this
scenario, when applying for a certificate, the subscriber selects a
traditional signature algorithm for the first public key and a post-
quantum signature algorithm for the alternative public key. The
issuer also uses a traditional signature algorithm and a post-quantum
signature algorithm for its first and alternative public keys,
respectively.
Assume that a device have some mechanisms to share its capabilities
with a subscriber. For example, in TLS, the client sends a
ClientHello message, which includes its supported algorithm list and
a set of extension requests.
Legacy devices only support traditional algorithms and do not
recognize the AltSubPubKeyExt extension. In this case, the
subscriber sends a certificate in Form 4 to legacy devices. Then,
the legacy device ignores the proposed two extensions, verifies the
certificate with the issuer's traditional public key, and retrieves
the subject's traditional public key from the certificate. The
legacy device can then use the subject's traditional public key to
Sun, et al. Expires 20 April 2025 [Page 16]
Internet-Draft Convertible Forms In Certificates October 2024
verify the identity of the subscriber. This allows legacy devices to
continue using traditional algorithms as before, ensuring backward
compatibility.
Upgraded devices, which support both traditional and post-quantum
algorithms, recognize the proposed two extensions. An upgraded
device can request any form of a certificate according to its
preference. Given a certificate, the device determines its form and
verifies the certificate follows Section 4.5. After the
verification, the device can use subject's one or two public keys to
verify the identity of the subscriber.
An upgraded device can obtain the actual value of the alternative
materials by requesting a certificate in FORM 1 during the first
communication with the subscriber and cache the alternative public
key. Later the device can select certificates in other forms to save
transmission overhead.
6. IANA Considerations
TODO: ADD a table to include the required OIDs.
7. Security Considerations
Many of the security considerations for this document closely follow
those of [RFC5280] and
[I.D.draft-truskovsky-lamps-pq-hybrid-x509-02]. However, the
extension introduced in this document does bring rise to additional
considerations.
The certificate issued as in this document MAY has location fields to
allow the relying party to download the alternative materials. It is
possible that a malicious actor replaces the content at the refered
location, but this action will be detected since the hash of the
actual value is given in the certificate.
This document uses the composite hybrid signature scheme in CSR
follows the description in
[I.D.draft-truskovsky-lamps-pq-hybrid-x509-02]. It achieves the Non-
Separability security property, which is defined in Section 1.4.3. of
[I.D.draft-ietf-pquip-hybrid-signature-spectrums-00]. So an attempt
to remove any of the public key or signature of a subscriber will be
detected.
For the certificate issuance, the issuer uses the nested hybrid
signature scheme to sign the information of a certificate with two
private keys. To achieve backward-compatibility, the subscriber
SHOULD use a traditional signature algorithm and a post-quantum
Sun, et al. Expires 20 April 2025 [Page 17]
Internet-Draft Convertible Forms In Certificates October 2024
signature algorithm for the outer and inner signature algorithms,
respectively. One of the main drawback of nested hybrid signature is
that the outer signature can be stripped. But in the case of a
certificate, the strpping attack will be detected. Another problem
is that if a malicious actor with a CRQC breaks the outer traditional
signature algorithm, it can alter all the inner message, including
the location, flag and hash for the inner signature. In this
powerful attack, a relying party will download a forged signature
from a location controlled by the attacker and passed the hash
comparison. But when the relying party use the issue's alternative
public key to verify the downloaded signature, the verification will
certainly fail.
For certificate transparency services, certificates in FORM 4 SHOULD
be logged and monitored.
For a legacy device, to achieve backward-compatibility, it uses the
signature field to verify the certificate and the first public key of
the subscriber to authenticate handshake transcripts. In this case,
there is no post-quantum security.
For an upgraded device, the situation is more complicated. It can
only use the first public key or two public keys. It can only verify
the signature field or verify two signatures. All these choices
depend on the communication parties' preferences and/or
configuration. The mechanism described in this document gives 4
forms of a certificate. However, the upper-layer applications or
protocols needs to decide the strategy when applying the proposed
mechanism.
8. References
8.1. Normative References
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/rfc/rfc5234>.
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
DOI 10.17487/RFC2986, November 2000,
<https://www.rfc-editor.org/rfc/rfc2986>.
Sun, et al. Expires 20 April 2025 [Page 18]
Internet-Draft Convertible Forms In Certificates October 2024
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
8.2. Informative References
[I.D.draft-truskovsky-lamps-pq-hybrid-x509-02]
Truskovsky, A., Geest, D. V., Fluhrer, S., Kampanakis, P.,
Ounsworth, M., and S. Mister, "Multiple Public-Key
Algorithm X.509 Certificates", 25 February 2024,
<https://datatracker.ietf.org/doc/draft-truskovsky-lamps-
pq-hybrid-x509/02/>.
[I.D.draft-ietf-lamps-pq-composite-sigs-02]
Ounsworth, M., Gray, J., Pala, M., Klaussner, J., and S.
Fluhrer, "Composite ML-DSA for use in Internet PKI", 8
July 2024, <https://datatracker.ietf.org/doc/draft-ietf-
lamps-pq-composite-sigs/02/>.
[I.D.draft-ounsworth-lamps-pq-external-pubkeys-03]
Ounsworth, M., Saarinen, M.-J. O., Gray, J., and D. Hook,
"External Keys For Use In Internet X.509 Certificates", 2
April 2024, <https://datatracker.ietf.org/doc/draft-
ounsworth-lamps-pq-external-pubkeys/03/>.
[I.D.draft-ietf-pquip-hybrid-signature-spectrums-00]
Bindel, N., Hale, B., Connolly, D., and F. Driscoll,
"Hybrid signature spectrums", 24 May 2024,
<https://datatracker.ietf.org/doc/draft-ietf-pquip-hybrid-
signature-spectrums/00/>.
Appendix A. Appendix 1 [REPLACE/DELETE]
This becomes an Appendix [REPLACE]
Sun, et al. Expires 20 April 2025 [Page 19]
Internet-Draft Convertible Forms In Certificates October 2024
Acknowledgements
This template uses extracts from templates written by Pekka Savola,
Elwyn Davies and Henrik Levkowetz. [REPLACE]
Authors' Addresses
Shuzhou Sun
Huawei
China
Email: [email protected]
Yidi He
Huawei
Singapore
Email: [email protected]
Hsiao Ying Lin
Huawei
France
Email: [email protected]
Sun, et al. Expires 20 April 2025 [Page 20]