Delegated Credentials for TLS

Terminating a TLS connection requires using a certificate’s private key. As a result, the private key needs to be stored at every single server utilized by a service.  The protection of this private key’s secrecy is paramount to the smooth operation of a Public Key Infrastructure scheme. An entity in possession of the private key can perform man-in-the-middle attacks for the remainder of the certificate’s validity. Typically, when an attacker compromises a private key, the certificate associated with this key is revoked, and a new one is issued.  However, for enterprises that use multiple servers, like Facebook or Content Delivery Networks, key compromises, especially in edge servers, are not easy to detect, hence putting at risk the entire network. Delegated Credentials allow servers to perform TLS handshakes, while the private key of the certificate is stored in a secure location. Delegated Credentials are digitally signed data structures comprising of two parts: a validity interval and a public key (along with its associated signature algorithm). They serve as a “power of attorney” for the servers indicating that they are authorized to terminate the TLS connection. The process of issuing delegated credentials is currently under standardization and defined in this IEFT draft. The draft defines the use of Delegated Credentials as follows:

“A limited delegation mechanism that allows a TLS peer to issue its own credentials within the scope of a certificate issued by an external CA. These credentials only enable the recipient of the delegation to speak for names that the CA has authorized.”

Delegated Credentials are designed with the purpose of increasing security. Hence, they possess certain traits, as defined in the IEFT draft.

• The maximum validity period of a delegated credential is seven (7) days to minimize the exposure if the private key is compromised. The short validity period does not mean that delegated credentials security should be taken lightly. Measures taken to protect the private key of the end-entity certificate should also apply to the protection of DCs. These include file system controls, physical security, and hardware security modules, among others. In addition, delegated credentials should only be used between parties that share some trust relationship with each other.
• The delegated credentials are cryptographically bound to the end-entity certificate. Specifically, the private key of the end-entity certificate is used to compute the signature of the DC via an algorithm specified by the credential. The signature effectively binds the DC to the names of the end-entity certificate.
• Delegated credentials are issued by the client, which is much easier than creating a certificate signed by a CA. Client-issued certificates are also helpful in keeping the service working even if the CA has a downtime. Also, organizations can experiment with algorithms not officially supported by the CA without compromising the security of the end-entity certificate. 
• Delegated credentials have short periods of validity by definition. When setting the lifetime of delegated credentials, servers need to take under consideration the client clock skew to avoid the rejection of certificates. Client clock skew is also important for the original certificate but is crucial for the short-lived delegated private key. Client clock skew should be taken into account both at the beginning and end of the validity periods.
• There is no revocation mechanism for delegated credentials. They are rendered invalid once the validity period expires. However, revocation of the private key of the end-entity certificate (which is used to sign the delegated credentials) implicitly revokes the delegated credential. 
• Delegated credentials are designed to be used in TLS 1.3 or later. There is a known vulnerability when TLS 1.2 servers support RSA key exchange, allowing the forging of an RSA signature over an arbitrary message. Suppose an attacker is able to forge a signature. In that case, they can create forged delegated credentials for the entire validity period of the end-entity certificate. This vulnerability is not present in implementations of TLS 1.3 or later. Also, the vulnerability does not affect certificates with elliptic curve cryptography, which SSL.com provides. 
• Organizations can use existing automated issuance APIs like ACME for delivering delegated credentials. In this case, the algorithms used are only those supported by the CA, but this practice reduces the possibility of key compromises. SSL.com endorses this practice. 
• Delegated credentials cannot be re-used in multiple contexts. Issuing parties compute the signature using a context string unique to the intended role (client or server), thus rendering the use of the same delegated credential for client and server authentication impossible. 

SSL.com supports the use of delegated credentials for all clients. Issuance of delegated credentials capable certificates can be done through the use of APIs for automation using the ACME protocol. Since SSL.com utilizes ECDSA to implement the PKI offered to clients, delegated credentials issued by our clients are not vulnerable to signature forgery attacks, as described above.