rfc9763v1.txt | rfc9763.txt | |||
---|---|---|---|---|
Internet Engineering Task Force (IETF) A. Becker | Internet Engineering Task Force (IETF) A. Becker | |||
Request for Comments: 9763 R. Guthrie | Request for Comments: 9763 R. Guthrie | |||
Category: Standards Track M. Jenkins | Category: Standards Track M. Jenkins | |||
ISSN: 2070-1721 NSA | ISSN: 2070-1721 NSA | |||
March 2025 | April 2025 | |||
Related Certificates for Use in Multiple Authentications within a | Related Certificates for Use in Multiple Authentications within a | |||
Protocol | Protocol | |||
Abstract | Abstract | |||
This document defines a new Certificate Signing Request (CSR) | This document defines a new Certificate Signing Request (CSR) | |||
attribute, relatedCertRequest, and a new X.509 certificate extension, | attribute, relatedCertRequest, and a new X.509 certificate extension, | |||
RelatedCertificate. The use of the relatedCertRequest attribute in a | RelatedCertificate. The use of the relatedCertRequest attribute in a | |||
CSR and the inclusion of the RelatedCertificate extension in the | CSR and the inclusion of the RelatedCertificate extension in the | |||
skipping to change at line 106 ¶ | skipping to change at line 106 ¶ | |||
an extension may want assurance from a registration authority (RA) | an extension may want assurance from a registration authority (RA) | |||
that the private keys (corresponding to, for example, two public | that the private keys (corresponding to, for example, two public | |||
keys: one in an extant certificate and one in a current request) | keys: one in an extant certificate and one in a current request) | |||
belong to the same entity. To facilitate this, a CSR attribute, | belong to the same entity. To facilitate this, a CSR attribute, | |||
called relatedCertRequest, is defined to permit an RA to make such an | called relatedCertRequest, is defined to permit an RA to make such an | |||
assertion. | assertion. | |||
1.1. Overview | 1.1. Overview | |||
The general roadmap of this design is best illustrated via an entity | The general roadmap of this design is best illustrated via an entity | |||
(a device, service, user token, etc.) that has an existing | (e.g., a device, service, user token) that has an existing | |||
certificate (Cert A) and requests a new certificate (Cert B), perhaps | certificate (Cert A) and requests a new certificate (Cert B), perhaps | |||
as part of an organization's transition strategy to migrate their PKI | as part of an organization's transition strategy to migrate their PKI | |||
from traditional cryptography to post-quantum cryptography (PQC). | from traditional cryptography to post-quantum cryptography (PQC). | |||
* For protocols where authentication is not negotiated and is rather | * For protocols where authentication is not negotiated but instead | |||
limited by what the signer offers, such as in Cryptographic | is limited by what the signer offers, such as in Cryptographic | |||
Message Syntax (CMS) and S/MIME, either Cert A's signing key, Cert | Message Syntax (CMS) and S/MIME, either Cert A's signing key, Cert | |||
B's signing key, or both signing keys may be invoked, according to | B's signing key, or both signing keys may be invoked, according to | |||
which validators the signer anticipates. | which verifiers the signer anticipates. | |||
* For protocols where authentication is negotiated in-protocol, such | * For protocols where authentication is negotiated in-protocol, such | |||
as TLS and Internet Key Exchange Protocol Version 2 (IKEv2), | as TLS and Internet Key Exchange Protocol Version 2 (IKEv2), | |||
either Cert A or Cert B's signing key may be invoked, according to | either Cert A or Cert B's signing key may be invoked, according to | |||
the preference of the validator. If the protocol is enabled to do | the preference of the verifier. If the protocol is enabled to do | |||
so, peers may request that both Cert A and Cert B are used for | so, peers may request that both Cert A and Cert B are used for | |||
authentication. | authentication. | |||
A validator that prefers multiple authentication types may be | A verifier that prefers multiple authentication types may be assisted | |||
assisted by the inclusion of relevant information in the signer's | by the inclusion of relevant information in one of the signer's | |||
certificate, that is, information that indicates the existence of a | certificates; that is, information that indicates the existence of a | |||
related certificate, and some assurance that those certificates have | related certificate, and some assurance that those certificates have | |||
been issued to the same entity. This document describes a | been issued to the same entity. This document describes a | |||
certificate request attribute and certificate extension that provide | certificate request attribute and certificate extension that provide | |||
such assurance. | such assurance. | |||
To support this concept, this document defines a new CSR attribute, | To support this concept, this document defines a new CSR attribute, | |||
relatedCertRequest, which contains information on how to locate a | relatedCertRequest, which contains information on how to locate a | |||
previously issued certificate (Cert A) and provides evidence that the | previously issued certificate (Cert A) and provides evidence that the | |||
requesting entity owns that certificate. When the RA makes the | requesting entity owns that certificate. When the RA makes the | |||
request to the CA, the CA uses the given information to locate Cert A | request to the CA, the CA uses the given information to locate Cert A | |||
skipping to change at line 162 ¶ | skipping to change at line 162 ¶ | |||
This section defines a new CSR attribute designed to allow the RA to | This section defines a new CSR attribute designed to allow the RA to | |||
attest that the owner of the public key in the CSR also owns the | attest that the owner of the public key in the CSR also owns the | |||
public key associated with the end-entity certificate identified in | public key associated with the end-entity certificate identified in | |||
this attribute. The relatedCertRequest attribute indicates the | this attribute. The relatedCertRequest attribute indicates the | |||
location of a previously issued certificate that the end entity owns | location of a previously issued certificate that the end entity owns | |||
and wants identified in the new certificate requested through the | and wants identified in the new certificate requested through the | |||
CSR. | CSR. | |||
The relatedCertRequest attribute has the following syntax: | The relatedCertRequest attribute has the following syntax: | |||
relatedCertRequest ATTRIBUTE ::= { | id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa 60 } | |||
WITH SYNTAX RequesterCertificate | ||||
ID { 60 } | aa-relatedCertRequest ATTRIBUTE ::= { | |||
} | TYPE RequesterCertificate | |||
IDENTIFIED BY id-aa-relatedCertRequest} | ||||
RequesterCertificate ::= SEQUENCE { | RequesterCertificate ::= SEQUENCE { | |||
certID IssuerAndSerialNumber, | certID IssuerAndSerialNumber, | |||
requestTime BinaryTime, | requestTime BinaryTime, | |||
locationInfo UniformResourceIdentifier, | locationInfo UniformResourceIdentifier, | |||
signature BIT STRING } | signature BIT STRING } | |||
The RequesterCertificate type has four fields: | The RequesterCertificate type has four fields: | |||
* The certID field uses the IssuerAndSerialNumber type [RFC5652] to | * The certID field uses the IssuerAndSerialNumber type [RFC5652] to | |||
skipping to change at line 196 ¶ | skipping to change at line 197 ¶ | |||
* The requestTime field uses the BinaryTime type [RFC6019] in order | * The requestTime field uses the BinaryTime type [RFC6019] in order | |||
to ensure freshness, such that the signed data can only be used at | to ensure freshness, such that the signed data can only be used at | |||
the time of the initial CSR. The means by which the CA and RA | the time of the initial CSR. The means by which the CA and RA | |||
synchronize time is outside the scope of this document. | synchronize time is outside the scope of this document. | |||
BinaryTime is repeated here for convenience: | BinaryTime is repeated here for convenience: | |||
BinaryTime ::= INTEGER (0..MAX) | BinaryTime ::= INTEGER (0..MAX) | |||
* The locationInfo field uses UniformResourceIdentifier to provide | * The locationInfo field uses UniformResourceIdentifier to provide | |||
information on the location of the other certificate the | information on the location of the other certificate the | |||
requesting entity owns. We define UniformResourceIdentifier as: | requesting entity owns. UniformResourceIdentifier is defined as: | |||
UniformResourceIdentifier ::= IA5String | UniformResourceIdentifier ::= IA5String | |||
The UniformResourceIdentifier is a pointer to a location via HTTP/ | The UniformResourceIdentifier is a pointer to a location via | |||
HTTPS or a dataURI. This field can contain one of two acceptable | HTTP(S) or a dataURI. This field can contain one of two | |||
values: | acceptable values: | |||
- If the request for (new) Cert B is to the same CA | - If the request for (new) Cert B is to the CA organization that | |||
organization as issued (existing) Cert A, then the | also issued (existing) Cert A, then the | |||
UniformResourceIdentifier value SHOULD be a URL that points to | UniformResourceIdentifier value SHOULD be a URL that points to | |||
a file containing a certificate or certificate chain that the | a file containing a certificate or certificate chain that the | |||
requesting entity owns, as detailed in [RFC5280]; the URL is | requesting entity owns, as detailed in [RFC5280]; the URL is | |||
made available via HTTP or HTTPS. The file must permit access | made available via HTTP or HTTPS. The file must permit access | |||
to a CMS 'certs-only' message containing the end-entity X.509 | to a CMS 'certs-only' message containing the end-entity | |||
certificate or the entire certificate chain. In this case, | certificate or the entire certificate chain. This option uses | |||
preference for a URL keeps the data limit smaller than using a | less data than a dataURI. All certificates contained must be | |||
dataURI. All certificates contained must be DER encoded. | DER encoded. | |||
- If the request for (new) Cert B is to a CA organization | - If the request for (new) Cert B is to a CA organization | |||
different to the CA organization that issued the certificate | different than the CA organization that issued the certificate | |||
(existing) Cert A referenced in the CSR, then the | (existing) Cert A referenced in the CSR, then the | |||
UniformResourceIdentifier value SHOULD be a dataURI [RFC2397] | UniformResourceIdentifier value SHOULD be a dataURI [RFC2397] | |||
containing inline degenerate PKCS#7 (see Sections 3.2.1 and 3.8 | containing inline degenerate PKCS#7 (see Sections 3.2.1 and 3.8 | |||
of [RFC8551]) consisting of all the certificates and CRLs | of [RFC8551]) consisting of all the certificates and CRLs | |||
required to validate Cert A. This allows validation without | required to validate Cert A. This allows the CA to perform | |||
the CA having to retrieve certificates/CRLs from another CA. | validation (as described in Section 3.2) without having to | |||
Further discussion of requirements for this scenario is in | retrieve certificates/CRLs from another CA. Further discussion | |||
Section 5. | of requirements for this scenario is in Section 5. | |||
* The signature field provides evidence that the requesting entity | * The signature field provides evidence that the requesting entity | |||
owns the certificate indicated by the certID. Specifically, the | owns the certificate indicated by the certID field. Specifically, | |||
signature field contains a digital signature over the | the signature field contains a digital signature over the | |||
concatenation of DER-encoded requestTime and | concatenation of DER-encoded IssuerAndSerialNumber and BinaryTime. | |||
IssuerAndSerialNumber. The concatenated value is signed using the | The concatenated value is signed using the signature algorithm and | |||
signature algorithm and private key associated with the | private key associated with the certificate identified by the | |||
certificate identified by the certID field. | certID field. | |||
- If the related certificate is a key establishment certificate | - If the related certificate is a key establishment certificate | |||
(e.g., using RSA key transport or Elliptic Curve Cryptography | (e.g., using RSA key transport or Elliptic Curve Cryptography | |||
(ECC) key agreement), use the private key to sign one time for | (ECC) key agreement), the private key is used to sign one time | |||
proof of possession (POP) (as detailed in Section 8.1.5.1.1.2 of | for proof of possession (POP) (as detailed in | |||
[NIST-SP-800-57]). | Section 8.1.5.1.1.2 of [NIST-SP-800-57]). | |||
The validation of this signature by the CA ensures that the owner of | The verification of this signature by the CA ensures that the | |||
the CSR also owns the certificate indicated in the relatedCertRequest | owner of the CSR also owns the certificate indicated in the | |||
attribute. | relatedCertRequest attribute. | |||
3.2. CSR Processing | 3.2. CSR Processing | |||
The information provided in the relatedCertRequest attribute allows | The information provided in the relatedCertRequest attribute allows | |||
the CA to locate a previously issued certificate that the requesting | the CA to locate a previously issued certificate that the requesting | |||
entity owns, and verify ownership by using the public key in that | entity owns, and confirm ownership by using the public key in that | |||
certificate to validate the signature in the relatedCertRequest | certificate to verify the signature in the relatedCertRequest | |||
attribute. | attribute. | |||
If a CA receives a CSR that includes the relatedCertRequest attribute | If a CA receives a CSR that includes the relatedCertRequest attribute | |||
and that CA supports the attribute, the CA: | and that CA supports the attribute, the CA: | |||
* MUST retrieve the certificate identified in the relatedCertRequest | * MUST retrieve the certificate identified in the relatedCertRequest | |||
attribute using the information provided in | attribute using the information provided in | |||
UniformResourceIdentifier, and validate it using certificate path | UniformResourceIdentifier, and validate it using certificate path | |||
validation rules defined in [RFC5280]. The CA then extracts the | validation rules defined in [RFC5280]. The CA then extracts the | |||
IssuerAndSerialNumber from the indicated certificate and compares | IssuerAndSerialNumber from the indicated certificate and compares | |||
this value against the IssuerAndSerialNumber provided in the | this value against the IssuerAndSerialNumber provided in the | |||
certID field of relatedCertRequest. | certID field of relatedCertRequest. | |||
* MUST check that the BinaryTime indicated in the requestTime field | * MUST check that the BinaryTime indicated in the requestTime field | |||
is sufficiently fresh. Note that sufficient freshness is defined | is sufficiently fresh. Note that sufficient freshness is defined | |||
by local policy and is out of the scope of this document. | by local policy and is out of the scope of this document. | |||
* MUST verify the signature field of the relatedCertRequest | * MUST verify the signature field of the relatedCertRequest | |||
attribute. The CA validates the signature using the public key | attribute. The CA verifies the signature using the public key | |||
associated with the certificate it located via the info provided | associated with the certificate identified by the | |||
in the UniformResourceIdentifier field. The details of the | relatedCertRequest attribute. The details of the verification | |||
validation process are outside the scope of this document. | process are outside the scope of this document. | |||
* SHOULD issue the new certificate containing the RelatedCertificate | * SHOULD issue the new certificate containing the RelatedCertificate | |||
extension as specified in Section 4, which references the | extension as specified in Section 4, which references the | |||
certificate indicated in the attribute's IssuerAndSerialNumber | certificate indicated in the attribute's IssuerAndSerialNumber | |||
field. The CA may apply local policy regarding the suitability of | field. The CA may also apply local policy regarding the | |||
the related certificate, such as validity period remaining. | suitability of the related certificate, such as validity period | |||
remaining. | ||||
The RA MUST only allow a previously issued certificate to be | The RA MUST only allow a previously issued certificate to be | |||
indicated in the relatedCertRequest attribute in order to enable the | indicated in the relatedCertRequest attribute in order to enable the | |||
CA to perform the required signature verification. | CA to perform the required signature verification. | |||
The RA MAY send the CA a CSR containing a relatedCertRequest | The RA MAY send the CA a CSR containing a relatedCertRequest | |||
attribute that includes the IssuerAndSerialNumber of a certificate | attribute that includes the IssuerAndSerialNumber of a certificate | |||
that was issued by a different CA. | that was issued by a different CA. | |||
4. Related Certificate | 4. Related Certificate | |||
4.1. The RelatedCertificate Extension | 4.1. The RelatedCertificate Extension | |||
This section profiles a new X.509v3 certificate extension, | This section specifies a new X.509 certificate extension, | |||
RelatedCertificate. RelatedCertificate creates an association | RelatedCertificate. RelatedCertificate creates an association | |||
between the certificate containing the RelatedCertificate extension | between the certificate containing the RelatedCertificate extension | |||
(Cert B) and the certificate referenced within the extension (Cert | (Cert B) and the certificate referenced within the extension (Cert | |||
A). When two end-entity certificates are used in a protocol, where | A). When two end-entity certificates are used in a protocol, where | |||
one of the certificates contains a RelatedCertificate extension that | one of the certificates contains a RelatedCertificate extension that | |||
references another certificate, the authenticating entity is provided | references the other certificate, the authenticating entity is | |||
with additional assurance that all certificates belong to the same | provided with additional assurance that both certificates belong to | |||
entity. | the same entity. | |||
The RelatedCertificate extension is an octet string that contains the | The RelatedCertificate extension contains the hash of a single end- | |||
hash of a single end-entity certificate. | entity certificate. | |||
The RelatedCertificate extension has the following syntax: | The RelatedCertificate extension has the following syntax: | |||
-- Object Identifiers for certificate extension | -- Object Identifier for certificate extension | |||
id-relatedCert OBJECT IDENTIFIER ::= { 36 } | id-relatedCert OBJECT IDENTIFIER ::= { 36 } | |||
-- X.509 Certificate extension | -- X.509 Certificate extension | |||
RelatedCertificate ::= OCTET STRING | RelatedCertificate ::= SEQUENCE { | |||
-- hash of entire related certificate } | hashAlgorithm AlgorithmIdentifier, | |||
hashValue OCTET STRING } | ||||
The extension is comprised of an octet string, which is the digest | The extension is a SEQUENCE of two fields. The hashAlgorithm field | |||
value obtained from hashing the entire related certificate identified | identifies the hash algorithm used to compute hashValue, which is the | |||
in the relatedCertRequest CSR attribute defined above. The algorithm | digest value obtained from hashing the entire related certificate | |||
used to hash the certificate in the RelatedCertificate extension MUST | identified in the relatedCertRequest CSR attribute defined above. If | |||
match the hash algorithm used to sign the certificate that contains | there is a hash algorithm explicitly indicated by the related | |||
the extension. | certificate's signature OID (e.g., ecdsa-with-SHA512), that hash | |||
algorithm SHOULD be also used for this extension. | ||||
This extension SHOULD NOT be marked critical. Marking this extension | This extension SHOULD NOT be marked critical. Marking this extension | |||
critical would severely impact interoperability. | critical would severely impact interoperability. | |||
For certificate chains, this extension MUST only be included in the | For certificate chains, this extension MUST only be included in the | |||
end-entity certificate. | end-entity certificate. | |||
For the RelatedCertificate extension to be meaningful, a CA that | For the RelatedCertificate extension to be meaningful, a CA that | |||
issues a certificate with this extension: | issues a certificate with this extension: | |||
* MUST only include a certificate in the extension that is listed | * MUST only include a certificate in the extension that is listed in | |||
and validated in the relatedCertRequest attribute of the CSR | the relatedCertRequest attribute of the CSR submitted by the | |||
submitted by the requesting entity. | requesting entity. | |||
* MUST ensure that the related certificate at least contains the key | * MUST ensure that the related certificate contains the key usage | |||
usage (KU) bits and extended key usage (EKU) OIDs [RFC5280] being | (KU) bits and extended key usage (EKU) OIDs [RFC5280] being | |||
asserted in the certificate being issued. | asserted in the certificate being issued. | |||
* SHOULD determine that all certificates are valid at the time of | * SHOULD determine that the related certificate is valid at the time | |||
issuance. The usable overlap of validity periods is a Subscriber | of issuance. The usable overlap with the validity period of the | |||
concern. | newly issued certificate is a Subscriber concern. | |||
4.2. Endpoint Protocol Multiple Authentication Processing | 4.2. Endpoint Protocol Multiple Authentication Processing | |||
When the preference to use a non-composite hybrid authentication mode | When the preference to use a non-composite hybrid authentication mode | |||
is expressed by an endpoint through the protocol itself (e.g., during | is expressed by an endpoint through the protocol itself (e.g., during | |||
negotiation), the use of the RelatedCertificate extension and its | negotiation), the use of the RelatedCertificate extension and its | |||
enforcement are left to the protocol's native authorization mechanism | enforcement are left to the protocol's existing authorization | |||
(along with other decisions endpoints make about whether to complete | mechanism (along with other decisions endpoints make about whether to | |||
or drop a connection). | complete or drop a connection). | |||
If an endpoint has indicated that it is willing to do non-composite | If an endpoint has indicated that it supports non-composite hybrid | |||
hybrid authentication and receives the appropriate authentication | authentication and receives the appropriate authentication data, it | |||
data, it should check end-entity certificates (Cert A and Cert B) for | should check end-entity certificates (Cert A and Cert B) for the | |||
the RelatedCertificate extension. If present in one certificate, for | RelatedCertificate extension. If present in one certificate (e.g., | |||
example Cert B, it should: | Cert B), it should: | |||
* Compute the appropriate hash of Cert A, the other end-entity | * Compute the appropriate hash of Cert A, the other end-entity | |||
certificate received. The hash algorithm is the same as the one | certificate received. | |||
used to sign the certificate containing the extension. | ||||
* Verify that the hash value matches the hash entry in the | * Confirm that the hash value matches the hash entry in the | |||
RelatedCertificate extension of Cert B. | RelatedCertificate extension of Cert B. | |||
How to proceed with authentication based on the outcome of this | How to proceed with authentication based on the outcome of this | |||
verification process is outside the scope of this document. | process is outside the scope of this document. Different | |||
Different determinations may be made depending on each peer's policy | determinations may be made depending on each peer's policy regarding | |||
regarding whether both or at least one authentication needs to | whether both or at least one authentication needs to succeed. | |||
succeed. | ||||
5. Use Case | 5. Use Case | |||
The general design of this method is best illustrated through | The general design of this method is best illustrated through | |||
specific use within a migration strategy to PQC via a non-composite | specific use within a migration strategy to PQC via a non-composite | |||
hybrid authentication mechanism. The intent is for a CA issuing a | hybrid authentication mechanism. The intent is for a CA issuing a | |||
new, post-quantum (PQ) certificate to add an X.509 extension that | new, post-quantum (PQ) certificate to add an X.509 extension that | |||
provides information about a previously issued, traditional | provides information about a previously issued, traditional | |||
certificate in which the private key is controlled by the same end | certificate in which the private key is controlled by the same end | |||
entity as the PQ certificate. | entity as the PQ certificate. | |||
In the following scenario, an entity currently has a traditional | In the following scenario, an entity currently has a traditional | |||
certificate and is requesting a new, PQ certificate be issued with | certificate and requests that a new, PQ certificate be issued | |||
the RelatedCertificate extension included that references the | containing a RelatedCertificate extension, which references the | |||
entity's traditional certificate. | entity's traditional certificate. | |||
The RA receives a CSR for a PQ certificate, where the CSR includes | The RA receives a CSR for a PQ certificate, where the CSR includes | |||
the relatedCertRequest attribute detailed in this document. The | the relatedCertRequest attribute detailed in this document. The | |||
relatedCertRequest attribute includes a certID field that identifies | relatedCertRequest attribute includes a certID field that identifies | |||
the entity's previously issued traditional certificate and a | the entity's previously issued traditional certificate and a | |||
signature field in which the requesting entity produces a digital | signature field in which the requesting entity produces a digital | |||
signature over the certID and a timestamp, using the private key of | signature over the concatenation of the IssuerAndSerialNumber and | |||
the certificate identified by the certID. | BinaryTime, using the private key of the certificate identified by | |||
the IssuerAndSerialNumber. | ||||
The purpose of the relatedCertRequest attribute is to serve as a tool | The purpose of the relatedCertRequest attribute is to serve as a tool | |||
for the RA to provide assurance to the CA organization that the | for the RA to provide assurance to the CA organization that the | |||
entity that controls the private key of the PQ certificate being | entity that controls the private key of the PQ certificate being | |||
requested also controls the private key of the referenced, previously | requested also controls the private key of the referenced, previously | |||
issued traditional certificate. | issued traditional certificate. | |||
Upon receipt of the CSR, the CA issues a PQ certificate to the | Upon receipt and validation of the CSR, the CA issues a PQ | |||
requesting entity that includes the RelatedCertificate extension | certificate to the requesting entity that includes the | |||
detailed in this document; the extension includes a hash of the | RelatedCertificate extension detailed in this document; the extension | |||
entire traditional certificate identified in the CSR. The X.509 | includes a hash of the entire traditional certificate identified in | |||
extension creates an association between the PQ certificate and the | the CSR. The X.509 extension creates an association between the PQ | |||
traditional certificate via end-entity ownership. | certificate and the traditional certificate via an assertion of end- | |||
entity ownership. | ||||
The attribute and subsequent extension together provide assurance | The attribute and subsequent extension together provide assurance | |||
from the CA organization that the same end entity controls the | from the CA organization that the same end entity controls the | |||
private keys of both certificates. It is neither a requirement nor a | private keys of both certificates. It is neither a requirement nor a | |||
mandate that either certificate be used with the other; it is simply | mandate that either certificate be used with the other; it is simply | |||
an assurance that they can be used together, as they are under the | an assurance that they can be used together, as they are under the | |||
control of the same entity. | control of the same entity. | |||
6. CA Organization Considerations | 6. CA Organization Considerations | |||
The relatedCertRequest CSR attribute provides assertion to the CA | The relatedCertRequest CSR attribute asserts end-entity control of | |||
organization issuing Cert B of end entity control of the private key | the private key associated with a related certificate (Cert A) to the | |||
of a related certificate, Cert A. Scenarios may arise where a | CA organization issuing a new certificate (Cert B). A public-facing | |||
public-facing CA organization is not configured to validate | CA organization may not be configured to validate certificates that | |||
signatures associated with certificates that have been issued by a | have been issued by different CA organizations. In this case, | |||
different CA organization. In this case, recognition of the contents | recognition of the contents in the relatedCertRequest attribute may | |||
in the relatedCertRequest attribute may be contingent upon a pre- | necessitate pre-arrangement, e.g., a contract with pre-configured | |||
arranged contract with pre-configured trust anchors from the other CA | trust anchors from another CA organization and agreements regarding | |||
organization and include agreements on certificate policy with | policies concerning certificate application, issuance, and | |||
regards to certificate application, issuance, and acceptance. | acceptance. | |||
Further, matching policies between CA organizations on protection of | ||||
the private key may be necessary in order for the whole assurance | ||||
level from the other CA organization to be accepted. | ||||
Similarly, if the CA organization issuing the PQ certificate can | Continuing with this scenario, in order for the CA organization to | |||
recognize the relatedCertRequest attribute in the CSR and wishes to | ensure that Cert B is issued under security parameters comparable to | |||
issue the certificate with the RelatedCerts extension, it may be the | Cert A, the issuing CA organization should match the issued | |||
case that a different CA organization issued the related certificate | certification policies to the related ones. The issuing CA | |||
referenced in the CSR. In order to ensure that the certificates have | organization, as part of its validation of Cert A, ascertains what | |||
been issued under homogeneous sets of security parameters, the | policies are asserted in Cert A’s certification path and determines | |||
certificate policies should be the same with regard to common | which of their own certification policies will best ensure that the | |||
security requirements. The issuing CA, as part of related | protection of the private key associated with Cert B is comparable to | |||
certificate public key validation, determines what policies are | that of Cert A. The relatedCertRequest attribute and subsequent | |||
acceptable for the certification path of the related certificate. | RelatedCertificate certificate extension are solely intended to | |||
The issuing CA determines what is acceptable to them in terms of | provide assurance that both private keys are controlled by the same | |||
certificate policy, to ensure that the policies for protection of the | end entity. | |||
private key are sufficient. The relatedCertRequest attribute and | ||||
subsequent RelatedCertificate certificate extension are solely | ||||
intended to provide assurance that both private keys are controlled | ||||
by the same end entity. | ||||
7. Security Considerations | 7. Security Considerations | |||
This document inherits security considerations identified in | This document inherits security considerations identified in | |||
[RFC5280]. | [RFC5280]. | |||
The mechanisms described in this document provide only a means to | The mechanisms described in this document provide only a means to | |||
express that multiple certificates are related. They are intended | express that multiple certificates are related. They are intended | |||
for the interpretation of the recipient of the data in which they are | for the interpretation of the recipient of the data in which they are | |||
embedded (i.e., a CSR or certificate). They do not by themselves | embedded (i.e., a CSR or certificate). They do not by themselves | |||
effect any security function. | effect any security function. | |||
Authentication, unlike key establishment, is necessarily a one-way | Authentication, unlike key establishment, is necessarily a one-way | |||
arrangement. That is, authentication is an assertion made by a | arrangement. That is, authentication is an assertion made by a | |||
claimant to a verifier. The means and strength of mechanism for | claimant to a verifier. The means and strength of the authentication | |||
authentication have to be to the satisfaction of the verifier. A | mechanism have to be satisfactory to the verifier. A system security | |||
system security designer needs to be aware of what authentication | designer needs to be aware of what authentication assurances are | |||
assurances are needed in various parts of the system and how to | needed in various parts of the system and how to achieve that | |||
achieve that assurance. In a closed system (e.g., Company X | assurance. In a closed system (e.g., Company X distributing firmware | |||
distributing firmware to its own devices), the approach may be | to its own devices), the approach may be implicit. In an online | |||
implicit. In an online protocol like IPsec where the peers are | protocol like IPsec where the peers are generally known, any | |||
generally known, any mechanism selected from a pre-established set | mechanism selected from a pre-established set may be sufficient. For | |||
may be sufficient. For more promiscuous online protocols, like TLS, | more promiscuous online protocols like TLS, the ability for the | |||
the ability for the verifier to express what is possible and what is | verifier to express what is possible and what is preferred -- and to | |||
preferred - and to assess that it got what it needed - is important. | assess that its requirements were met -- is important. | |||
A certificate is an assertion of binding between an identity and a | A certificate is an assertion of binding between an identity and a | |||
public key. However, that assertion is based on several other | public key. However, that assertion is based on several other | |||
assurances, specifically, that the identity belongs to a particular | assurances, especially that the identity belongs to a particular | |||
physical entity and that the physical entity has control over the | physical entity and that the physical entity has control over the | |||
private key corresponding to the public. For any hybrid approach, it | private key corresponding to the public key. For any hybrid | |||
is important that there be evidence that the same entity controls all | approach, it is important that there be evidence that the same entity | |||
private keys at time of use (to the verifier) and at time of | controls all private keys at time of use (to the verifier) and at | |||
registration (to the CA). | time of registration (to the CA). | |||
All hybrid implementations are vulnerable to a downgrade attack in | All hybrid implementations are vulnerable to a downgrade attack in | |||
which a malicious peer does not express support for the stronger | which a malicious peer does not express support for the stronger | |||
algorithm, resulting in an exchange that can only rely upon a weaker | algorithm, resulting in an exchange that can only rely upon a weaker | |||
algorithm for security. | algorithm for security. | |||
Implementors should be aware of risks that arise from the retrieval | Implementors should be aware of risks that arise from the retrieval | |||
of a related certificate via the UniformResourceIdentifier provided | of a related certificate via the UniformResourceIdentifier provided | |||
in the relatedCertRequest CSR attribute, if the URI points to | in the relatedCertRequest CSR attribute, as a URL can point to | |||
malicious code. Implementors should ensure the data is properly | malicious code. Implementors should ensure the data is properly | |||
formed and validate the retrieved data fully. | formed and validate the retrieved data fully. | |||
CAs should be aware that retrieval of existing certificates may be | CAs should be aware that retrieval of existing certificates may be | |||
subject to observation; if this is a concern, it may be advisable to | subject to observation; if this is a concern, it is advisable to use | |||
use the dataURI option described in Section 3.1. | the dataURI option described in Section 3.1. | |||
8. IANA Considerations | 8. IANA Considerations | |||
This document defines an extension for use with X.509 certificates. | This document defines an extension for use with X.509 certificates. | |||
IANA has registered the following OID in the "SMI Security for PKIX | IANA has registered the following OID in the "SMI Security for PKIX | |||
Certificate Extension" registry (1.3.6.1.5.5.7.1): | Certificate Extension" registry (1.3.6.1.5.5.7.1): | |||
+=========+===================+============+ | +=========+===================+============+ | |||
| Decimal | Description | References | | | Decimal | Description | References | | |||
+=========+===================+============+ | +=========+===================+============+ | |||
skipping to change at line 601 ¶ | skipping to change at line 598 ¶ | |||
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ | [RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ | |||
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 | Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 | |||
Message Specification", RFC 8551, DOI 10.17487/RFC8551, | Message Specification", RFC 8551, DOI 10.17487/RFC8551, | |||
April 2019, <https://www.rfc-editor.org/info/rfc8551>. | April 2019, <https://www.rfc-editor.org/info/rfc8551>. | |||
Appendix A. ASN.1 Module | Appendix A. ASN.1 Module | |||
The following RelatedCertificate ASN.1 module describes the | The following RelatedCertificate ASN.1 module describes the | |||
RequesterCertificate type found in the relatedCertAttribute. It | RequesterCertificate type found in the relatedCertAttribute. It | |||
pulls definitions from modules defined in [RFC5912], and [RFC6268], | pulls definitions from modules defined in [RFC5912] and [RFC6268] for | |||
and [RFC6019] for the IssuerAndSerialNumber type, and BinaryTime | the IssuerAndSerialNumber type and in [RFC6019] for the BinaryTime | |||
type, respectively. | type. | |||
RelatedCertificate { iso(1) identified-organization(3) dod(6) | RelatedCertificate { iso(1) identified-organization(3) dod(6) | |||
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) | internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) | |||
id-mod-related-cert-2023(115)} | id-mod-related-cert-2023(115)} | |||
DEFINITIONS IMPLICIT TAGS ::= | DEFINITIONS IMPLICIT TAGS ::= | |||
BEGIN | BEGIN | |||
IMPORTS | IMPORTS | |||
skipping to change at line 644 ¶ | skipping to change at line 641 ¶ | |||
id-pe OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) | id-pe OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) | |||
dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1 } | dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1 } | |||
id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) usa(840) | id-aa OBJECT IDENTIFIER ::= { iso(1) member-body(2) usa(840) | |||
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2) } | rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2) } | |||
-- relatedCertificate Extension | -- relatedCertificate Extension | |||
id-pe-relatedCert OBJECT IDENTIFIER ::= { id-pe 36 } | id-pe-relatedCert OBJECT IDENTIFIER ::= { id-pe 36 } | |||
RelatedCertificate ::= OCTET STRING | RelatedCertificate ::= SEQUENCE { | |||
hashAlgorithm AlgorithmIdentifier, | ||||
hashValue OCTET STRING } | ||||
ext-relatedCertificate EXTENSION ::= { | ext-relatedCertificate EXTENSION ::= { | |||
SYNTAX RelatedCertificate | SYNTAX RelatedCertificate | |||
IDENTIFIED BY id-pe-relatedCert } | IDENTIFIED BY id-pe-relatedCert } | |||
-- relatedCertRequest Attribute | -- relatedCertRequest Attribute | |||
id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa 60 } | id-aa-relatedCertRequest OBJECT IDENTIFIER ::= { id-aa 60 } | |||
RequesterCertificate ::= SEQUENCE { | RequesterCertificate ::= SEQUENCE { | |||
End of changes. 45 change blocks. | ||||
151 lines changed or deleted | 150 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |