]> DigiCert

corey.bonnell@digicert.com

Entrust

john.gray@entrust.com

KeyFactor

david.hook@keyfactor.com

DigiCert

tomofumi.okubo@digicert.com

Entrust

mike.ounsworth@entrust.com

Security delta certificate chameleon certificate paired certificate This document specifies a method to efficiently convey the differences between two certificates in an X.509 version 3 extension. This method allows a relying party to extract information sufficient to construct the paired certificate and perform certification path validation using the constructed certificate. In particular, this method is especially useful as part of a key or signature algorithm migration, where subjects may be issued multiple certificates containing different public keys or signed with different CA private keys or signature algorithms. This method does not require any changes to the certification path validation algorithm as described in RFC 5280. Additionally, this method does not violate the constraints of serial number uniqueness for certificates issued by a single certification authority. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Limited Additional Mechanisms for PKIX and SMIME (lamps) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction In certain public key infrastructures, it is common to issue multiple certificates to a single subject. In particular, as part of an algorithm migration, multiple certificates may be issued to a single subject which convey public keys of different types or are signed with different signature algorithms. In cases where relying party systems cannot be immediately updated to support new algorithms, it is useful to issue certificates to subjects that convey public keys whose algorithm is being phased out to maintain interoperability. However, multiple certificates adds complexity to certificate management for relying parties and exposes limitations in applications and protocols that support a single certificate chain. For this reason, it is useful to efficiently convey information concerning the elements of two certificates within a single certificate. This information can then be used to construct the paired certificate as needed by relying parties. This document specifies an X.509 v3 certificate extension that includes sufficient information for a relying party to construct both paired certificates with a single certificate. This method does not require any changes to the certification path validation algorithm as described in . Additionally, this method does not violate the constraints of serial number uniqueness for certificates issued by a single certification authority. In addition to the certificate extension, this document specifies two PKCS #10 Certificate Signing Request attributes that can be used by applicants to request Paired Certificates using a single PKCS #10 Certificate Signing Request.

Conventions and Definitions 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.

Definitions For conciseness, this document defines several terms that are frequently used throughout. Base Certificate: A X.509 v3 certificate which contains a delta certificate descriptor extension. DCD: An acronym meaning "Delta Certificate descriptor", which is a reference to the X.509 v3 certificate extension defined in this document. Delta Certificate: A X.509 v3 certificate which can be reconstructed by incorporating the fields and extensions contained in a Base Certificate. Paired Certificates: A Base Certificate and the corresponding Delta Certificate whose information is encoded in the Base Certificate's DCD extension.

Relationship between Base Certificates and Delta Certificates In some public key infrastructures, it may be common to issue multiple certificates to the same subject. For example, these certificates generally contain the same (or substantially similar) identity information and generally have identical validity periods. The differences in certificate content generally stem from the certification of different keys, where the named subject may have multiple keys of different algorithms certified by separate certificates. The use of different keys allows for the subject to use the key that is most appropriate for a given operation and intended recipient. For example, as part of an ongoing algorithm migration, it is useful to use stronger algorithms when both of the systems utilized by the subscriber/sender and recipient have been upgraded. However, in the case where systems have not yet been updated, the use of a legacy key algorithm may be required. Additionally, multiple certificates may be issued to the same subject that certify keys for different purposes, such as one key for signing and another key for encryption. The management of multiple certificates may be complex, and there may be limitations in protocols regarding the handling of multiple certificate chains. To account for these concerns, this document proposes a method to efficiently encode the differences between two certificates with sufficient information such that a relying party can derive the complete certificate from another. For the purposes of this document, the "Base Certificate" contains its own fields and extensions and additionally includes an extension that conveys all differences contained within the paired certificate. The certificate whose elements which differ from the Base Certificate and are captured in the Delta Certificate descriptor extension of the Base Certificate is known as the "Delta Certificate". Delta Certificates are reconstructed from the Base Certificate either on the sender's side or the recipient's side depending on the protocol and application(s) in use. The sender may elect to send the Base Certificate or the Delta Certificate based on information that it has about what the recipient can process. Similarly, the client may send either the Base Certificate or the Delta Certificate based on what the server can process. This assures backwards compatibility as the certificate sent to the peer (server or client) is chosen based on what it can process. The negotiation on which certificate to use is out-of-scope of this document and is deferred to each protocol and application. In the absence of information concerning the capabilities of the peer, it is unknown whether it understands the DCD extension in the Base Certificate. When the recipient does not understand the DCD extension, it only processes the information within the Base Certificate and ignores the information found in a non-critical DCD extension. If the recipient receives a Base Certificate and is capable of processing the DCD extension, then it may reconstruct the Delta Certificate to be used for processing. In a protocol, the sender may perform a cryptographic operation with the key conveyed within the Base Certificate. If it understands the DCD extension, then it may reconstruct the Delta Certificate and choose to perform the same operation with the key conveyed within the DCD extension. Alternatively, if the sender understands the DCD extension and knows that the receiver will only process the Delta Certificate, the sender can reconstruct and send only the Delta Certificate. This behavior is deferred to the software in use.

Delta certificate descriptor extension The Delta Certificate descriptor ("DCD") extension is used to reconstruct the Delta Certificate by incorporating both the fields and extensions present in the Base Certificate as well as the information contained within the extension itself. Certification authorities SHOULD NOT mark this extension as critical so that applications that do not understand the extension will still be able to process the Base Certificate. The inclusion of the DCD extension within a Base Certificate is not a statement from the issuing Certification Authority of the Base Certificate that the contents of the Delta Certificate have been verified. Conversely, the DCD extension is merely a mechanism to encode the differences between two Paired Certificates. Given this, it is possible for the Base Certificate to expire prior to the Delta Certificate, and vice versa. However, the policies governing a public key infrastructure may add additional requirements for the content of the DCD extension or alignment of validity periods for Base Certificates and Delta Certificates. For example, a policy may require that the validity periods of the Base Certificate and Delta Certificate be identical, or that if the Delta Certificate is revoked, the Base Certificate must also be revoked.

Delta certificate descriptor content The DCD extension is identified with the following object identifier: (TODO: replace this temporary OID) The ASN.1 syntax of the extension is as follows: The serialNumber field MUST be present and contain the serial number of the Delta Certificate. The signature field specifies the signature algorithm used by the issuing certification authority to sign the Delta Certificate. If the DER encoding of the value of the signature field of the Base Certificate and Delta Certificate is the same, then this field MUST be absent. Otherwise, it MUST contain the DER encoding of the value of the signature field of the Delta Certificate. The issuer field specifies the distinguished name of the issuing certification authority which signed the Delta Certificate. If the DER encoding of the value of the issuer field of the Base Certificate and Delta Certificate is the same, then this field MUST be absent. Otherwise, it MUST contain the DER encoding of the value of the issuer field of the Delta Certificate. The validity field specifies the validity period of the Delta Certificate. If the DER encoding of the value of the validity field of the Base Certificate and Delta Certificate is the same, then this field MUST be absent. Otherwise, it MUST contain the DER encoding of the value of the validity field of the Delta Certificate. The subject field specifies the distinguished name of the named subject as encoded in the Delta Certificate. If the DER encoding of the value of the subject field of the Base Certificate and Delta Certificate is the same, then this field MUST be absent. Otherwise, it MUST contain the DER encoding of the value of the subject field of the Delta Certificate. The subjectPublicKeyInfo field contains the public key certified in the Delta Certificate. The value of this field MUST differ from the value of the subjectPublicKeyInfo field of the Base Certificate. In other words, the Base Certificate and Delta Certificate MUST certify different keys. The extensions field contains the extensions whose criticality and/or DER-encoded value are different in the Delta Certificate compared to the Base Certificate with the exception of the DCD extension itself. If the extensions field is absent, then all extensions in the Delta Certificate MUST have the same criticality and DER-encoded value as the Base Certificate (except for the DCD extension, which MUST be absent from the Delta Certificate). This field MUST NOT contain any extension:

• which has the same criticality and DER-encoded value as encoded in the Base Certificate,
• whose type does not appear in the Base Certificate, or
• which is of the DCD extension type (recursive Delta Certificates are not permitted).

Additionally, the Base Certificate SHALL NOT include any extensions which are not included in the Delta Certificate, with the exception of the DCD extension itself. Likewise, there is no mechanism to remove extensions from the Delta Certificate that are present in the Base Certificate. Therefore, it is not possible to add or remove extensions using the DCD extension. The ordering of extensions in this field MUST be relative to the ordering of the extensions as they are encoded in the Delta Certificate. Maintaining this relative ordering ensures that the Delta Certificate's extensions can be constructed with a single pass. The signatureValue field contains the value of the signature field of the Delta Certificate. It MUST be present.

Issuing a Base Certificate The signature of the Delta Certificate must be known so that its value can be included in the signatureValue field of the delta certificate descriptor extension. Given this, Delta Certificate will necessarily need to be issued prior to the issuance of the Base Certificate. To simplify reconstruction of the Delta Certificate, the signatures for Base and Delta Certificates MUST be calculated over the DER encoding of the TBSCertificate structure. After the Delta Certificate is issued, the certification authority compares the signature, issuer, validity, subject, subjectPublicKeyInfo, and extensions fields of the Delta Certificate and the to-be-signed certificate which will contain the DCD extension. The certification authority then populates the DCD extension with the values of the fields which differ from the Base Certificate. The CA MUST encode extensions in the Base Certificate in the same order used for the Delta Certificate, with the exception of the DCD extension itself. The certification authority then adds the computed DCD extension to the to-be-signed Base Certificate and signs the Base Certificate.

Reconstructing a Delta Certificate from a Base Certificate The following procedure describes how to reconstruct a Delta Certificate from a Base Certificate:

1. Create an initial Delta Certificate template by copying the Base Certificate excluding the DCD extension.
2. Replace the value of the serialNumber field of the Delta Certificate template with the value of the DCD extension's serialNumber field.
3. If the DCD extension contains a value for the signature field, then replace the value of the signature field and the signatureAlgorithm field of the Delta Certificate template with the value of the DCD extension's signature field.
4. If the DCD extension contains a value for the issuer field, then replace the value of the issuer field of the Delta Certificate template with the value of the DCD extension's issuer field.
5. If the DCD extension contains a value for the validity field, then replace the value of the validity field of the Delta Certificate template with the value of the DCD extension's validity field.
6. Replace the value of the subjectPublicKeyInfo field of the Delta Certificate template with the value of the DCD extension's subjectPublicKeyInfo field.
7. If the DCD extension contains a value for the subject field, then replace the value of the subject field of the Delta Certificate template with the value of the DCD extension's subject field.
8. If the DCD extension contains a value for the extensions field, then iterate over the DCD extension's "extensions" field, replacing the criticality and/or extension value of each identified extension in the Delta Certificate template. If any extension is present in the field that does not appear in the Delta Certificate template, then this reconstruction process MUST fail.
9. Replace the value of the signature field of the Delta Certificate template with the value of the DCD extension's signatureValue field.

As part of testing implementations of this specification, implementers are encouraged to verify the signature of the reconstructed Delta Certificate using the issuing Certification Authority's public key to ensure that the Delta Certificate was reconstructed correctly.

Delta certificate request content and semantics Using the two attributes that are defined below, it is possible to create Certificate Signing Requests for both Base and Delta Certificates within a single PKCS #10 Certificate Signing Request. The mechanism presented in this section need not be used exclusively by requestors for the issuance of Paired Certificates; other mechanisms (such as the submission of two Certificate Signing Requests, etc.) are also acceptable. Additionally, this document does not place any restriction on the amount of time that may elapse between the issuance of a Delta Certificate and the request of a Base Certificate; such restrictions should be defined by the policy of a particular public key infrastructure. The delta certificate request attribute is used to convey the requested differences between the request for issuance of the Base Certificate and the requested Delta Certificate. Similar to the semantics of Certificate Signing Requests in general, the Certification Authority MAY add, modify, or selectively ignore information conveyed in the attribute when issuing the corresponding Delta Certificate. The attribute is identified with the following object identifier: (TODO: replace this temporary OID) The ASN.1 syntax of the attribute is as follows: The delta certificate request signature attribute is used to convey the signature that is calculated over the CertificationRequestInfo using the signature algorithm and key that is specified in the delta certificate request attribute. describes in detail how to determine the value of this attribute. This attribute is identified with the following object identifier: (TODO: replace this temporary OID) The ASN.1 syntax of the attribute is as follows:

Creating a Certificate Signing Request for Paired Certificates The following procedure is used by a certificate requestor to create a combined Certificate Signing Request for Paired Certificates.

1. Create a CertificationRequestInfo containing the subject, subjectPKInfo, and attributes for the Base Certificate.
2. Create a delta certificate request attribute that specifies the requested differences between the to-be-issued Base Certificate and Delta Certificate requests.
3. Add the delta certificate request attribute that was created by step 2 to the list of attributes in the CertificationRequestInfo.
4. Sign the CertificationRequestInfo using the private key of the delta certificate request subject.
5. Create a delta certificate request signature attribute that contains the signature value calculated by step 4.
6. Add the delta certificate request signature attribute that was created by step 5 to the list of attributes.
7. Sign the CertificationRequestInfo using the private key of the base certificate request subject.

Verifying a Certificate Signing Request for Paired Certificates The following procedure is used by a Certification Authority to verify a Certificate Signing Request for Paired Certificates that was created using the process outlined in .

1. Create a CertificationRequest template by copying the CertificationRequest submitted by the certificate requestor.
2. Verify the signature of the base certificate request using the public key associated with the base certificate request subject and the signature algorithm specified in the signatureAlgorithm field of the CertificationRequest template. If signature verification fails, then the Certification Authority MUST treat the Certificate Signing Request as invalid.
3. Remove the delta certificate request signature attribute from the CertificationRequest template.
4. Replace the value of the signature field of the CertificationRequest template with the value of the delta certificate request attribute that was removed in step 3.
5. Verify the signature of the delta certificate request using the public key associated with the delta certificate request subject. If the signatureAlgorithm field of the delta certificate request attribute is present, then the Certification Authority MUST perform signature verification using the algorithm specified in this field. Otherwise, the Certification Authority MUST perform signature verification using the algorithm specified in the signatureAlgorithm field of the CertificationRequest template. If signature verification fails, then the Certification Authority MUST treat the Certificate Signing Request as invalid.

Security Considerations The validation of Base Certificates and Delta Certificates follows the certification path validation algorithm defined in . In particular, the certification path validation algorithm defined in MUST be performed prior to using a Base or Delta Certificate; it is not sufficient to reconstruct a Delta Certificate and use it for any purpose without performing certification path validation. If a use case requires it, a Delta Certificate can be reconstructed specifically for the purposes of validation to ensure that the Delta Certificate is valid for its intended purpose on final reconstruction. That being said, some form of validation such as revocation checking, and signature verification MUST always be assured at the point the certificate is used. There are some additional considerations for the software to handle the Base Certificate and Delta Certificate. The Base Certificate and Delta Certificate may have different security properties such as different signing algorithms, different key types or the same key types with different key sizes or signing algorithms. The preference on which certificate to be used or using both when available is deferred to the server or client software. The software is expected to make choices depending on the certificate's security properties or a policy set for the particular PKI. One example of handling two certificates is "fallback" where if the validation of the first certificate fails, it attempts to validate the second certificate. Another example to handle two certificate is "upgrade", where the validation of the first certificate succeeds but still attempts the validation of the second certificate. While this document provides a vehicle to convey information of two certificates in one, it does not address the rules that are expected to be set by the policy of a PKI on how to issue Paired Certificates and how to handle them. The algorithms that are used for the Base Certificate and Delta Certificate respectively should be carefully set by the policy of each PKI reflecting the best current practices in usage of cryptography. The behavior of the server or client software is expected to be well-defined in accordance with the policy in order to avoid downgrade attacks or substitution attacks.

IANA Considerations For the Delta Certificate descriptor extension as defined in , IANA is requested to assign an object identifier (OID) for the certificate extension. The OID for the certificate extension should be allocated in the "SMI Security for PKIX Certificate Extension" registry (1.3.6.1.5.5.7.1). For the Delta Certificate Request and Delta Certificate Request Signature attributes as defined in , IANA is requested to create a new registry under SMI Security Codes and assign two object identifiers (OID). For the ASN.1 Module for the extension and attributes defined in , IANA is requested to assign an object identifier (OID). The OID for the module should be allocated in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0).

Normative References ITU-T 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] 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.

ASN.1 Module The following ASN.1 module provides the complete definition of the extensions, attributes, and associated identifiers specified in this document.

Examples This appendix includes some example certificates which demonstrate the use of the mechanism specified in this document. Two use cases of this mechanism are demonstrated: algorithm migration and dual use. The PEM text and dumpasn1 output for each certificate is provided.

Root certificates The two certificates in this section represent the two root Certification Authorities which issue the end-entity certificates in the following section.

EC P-521 root certificate This is the EC root certificate.

Dilithium root certificate This is the Dilithium root certificate. It contains a Delta Certificate Descriptor extension which includes sufficient information to recreate the ECDSA P-521 root.

Algorithm migration example

Dilithium signing end-entity certificate This is an end-entity signing certificate which certifies a Dilithium key.

EC signing end-entity certificate with encoded Delta Certificate This is an end-entity signing certificate which certifies an EC key. It contains a Delta Certificate Descriptor extension which includes sufficient information to recreate the Dilithium signing end-entity certificate.

Dual use example

EC signing end-entity certificate This is an end-entity signing certificate which certifies an EC key.

EC dual use end-entity certificate with encoded Delta Certificate This is an end-entity key exchange certificate which certifies an EC key. It contains a Delta Certificate Descriptor extension which includes sufficient information to the recreate the EC signing end-entity certificate.

Acknowledgments TODO acknowledge.