https://www.rfc-editor.org/rfc/rfc9345.html describes Delegated Credentials for TLS and DTLS while https://www.rfc-editor.org/rfc/rfc9060.html describes Secure Telephone Identity Revisited (STIR) Certificate Delegation
They sound almost identical, and I insert the abstracts for further thought:
Abstract (RFC9345)
The organizational separation between operators of TLS and DTLS endpoints and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the Certification Authority (CA). This document describes a mechanism to overcome some of these limitations by enabling operators to delegate their own credentials for use in TLS and DTLS without breaking compatibility with peers that do not support this specification.
Abstract (RFC9060)
The Secure Telephone Identity Revisited (STIR) certificate profile provides a way to attest authority over telephone numbers and related identifiers for the purpose of preventing telephone number spoofing. This specification details how that authority can be delegated from a parent certificate to a subordinate certificate. This supports a number of use cases, including those where service providers grant credentials to enterprises or other customers capable of signing calls with STIR.
Discussion
While RFC9060 tries to restrict its applicability to telephony systems with the Telephony Number (TN) Authorization List. Fundamentally, other ecosystems could use this. RFC9060 essentially allows an End-Entity that has a certificate with the cA = true Key Usage bit set to delegate an identical Subject (and SubjectAltName) to another entity. No change may be made the Subject. In secure telephon as described by STIR, this allows use cases such as allowing a doctor’s smartphone to initiate a (voice) call using the doctor’s office telephone number.
RFC9345 specifies a (D)TLS specific mechanism that is primarily focused on difficulties within Content Distribution Networks that try to keep all nodes serving content up to date in the face of (very) short-lived certificates. It internalizes the problem of keeping all servers up to date, removing what has proven to be a brittle dependancy upon external CAs. This is accute for very short-lived certificates which might be shorter and need to be reliably renewed over a long-weekend. Longer certificates (even the proposed 100 day lifetime) can more easily tolerate an operational or network outage that lasts for a few days.
RFC9345 assumes the client will indicate support for the delegated credential. If it does not then the server in question will need to use a different mechanism such as live network access to signatures as described (dammit: where is that reference).
The RFC9345 is a non-ASN.1 certificate delegation: it’s a signed TLS-format object. It requires new code in the client, while RFC9060 might only require some subtle relaxation of constraints in client PKIX certificate evaluation code. Some client libraries might need no change at all.
As both mechanism ultimately transmit the End-Entity Certificate to the client, the client can look at the properties of all certificates in the chain. In the case of RFC9060 (Certificate Delegation), the entire subordinate certificate would contain all relevant extensions as the parent. In the case of RFC9345, the original End-Entity certificate is transmitted along with a statement from that EE that the signature found in the TLS exchange is to be trusted.