[TLS] A proposal for a new field in delegated credentials

[Paul Yang <[e-mail]>]

Hi there,

As mentioned in "Delegated Credentials for TLS" draft, we found this feature is mainly designed for application-to-service scenario - for instance, to replace the so-called 'keyless' solution. By applying delegated credential, external CA could be less depended so that one can issue credentials more easily without losing the security.

We found this feature is also very useful in other scenarios like service-to-service communication. Currently cloud-native is a very popluar topic, which introduces a new solution called service mesh for Internet business to manage their services more efficiently. In a service mesh architecture, all services are containerized and the communication among the services are authenticated and encrypted via mutual authenticated TLS (mTLS). The oridinary practice of this mTLS usage is to utilize X.509 certificate as how mTLS is originally designed. For security considerations, it also requires a short-term credential instead of a long-term one. So the problem comes up, we need to find a way to issue very short-term X.509 certificates within the traditional CA architecture, which leads to the same issue the application-to-service scenario faces.

In such a case, it's possible to utilize delegated credentials to subsititue X.509 certificate in the 'inner' service mesh communication, but we found something is missing in current structure of the definition of the 'Credential'. In service mesh case, all the services share one same domain name, but with different sub-identifiers, for instance, one would like to issue a credential for 'inner-service-A-at-a.com' and 'inner-service-B-at-a.com' by using the X.509 certificate with CommonName 'a.com'. So we'd like to propose to add an extra field in the 'Credential' sturcture to resolve this issue as follows:

Current design in the draft:

    struct {
            uint32 valid_time;
            SignatureScheme expected_cert_verify_algorithm;
            opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
    } Credential;

What we propose:

    struct {
            uint32 valid_time;
            SignatureScheme expected_cert_verify_algorithm;
            opaque SubName<1..2^11-1>;
            opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;
    } Credential;

A new extra field is added as:

    opaque SubName<1..2^11-1>;

SubName is derived from the signer X.509 certificate’s CommonName field and MUST NOT use arbitrary value. The SubName MAY conform to what SPIFFE requires (https://spiffe.io) and other identity specifications.

The SubName field doesn't aim to change the original identity, it's additional information to the CommonName.

For instance, we have CN=alipay.com in the singer’s X.509 certificate then we could use that certificate to sign a DC with the following SubName:
	• spiffe://alipay.com/billing/payments

Other explanation:
	• SubName’s max length is 2048 bytes defining in SPIFFE spec, hence we limit this field in TLS DC to a range of <1..2^11-1>





Regards,

Paul Yang