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

From: "Paul Yang" <[email-masked]>
Date: Tue, 03 Mar 2020 15:10:25 +0800

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

---

From: "J.C. Jones" <[email-masked]>
Date: Tue, 3 Mar 2020 09:46:23 -0700

Paul,

Without getting into the details about the issues for trusting such
certificates on the Web PKI, which would be its own large and contentious
conversation and pull in a lot of actors from outside the  TLSWG, I would
think specifically for this use case that the SubName field should use the
types developed for the SubjectAlternateName extension for precision, as
the Common Name field is long deprecated for being typeless and difficult
to validate.

J.C.

On Tue, Mar 3, 2020 at 12:11 AM Paul Yang <kaishen.yy=
[email-masked]> wrote:

> 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:
>
> 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:
>         • 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
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Watson Ladd <[email-masked]>
Date: Tue, 3 Mar 2020 11:12:28 -0800

> Hi there,
<chop>
> 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 spec…

MUST NOT use arbitrary value, but MAY use any specification invites
https://xkcd.com/927/. In practice this MUST NOT is unenforceable and
there must be some way for the client to signal what SubName it
expects, lest a SubName in one format be a valid SubName in another
that was not what was intended.

Part of the need for delegated credentials comes from wanting to have
the freedom to use more signature schemes without interacting with the
PKI validation libraries which in some cases are provided by entirely
different organizations then the TLS layer. For this scheme to work
you're assuming a closed world where at most one form of SubName is
expected and which one is expected is known by everyone. In that case
nothing stops the use of SPIFFE solution via name-constrained CAs as
seems to be specified in the documents they have produced: what is the
limitation there that makes delegated credentials a better solution?

To implement this scheme the PKI validation library needs to
understand exactly how SubName is derived from the CommonName
(assuming of course that this is how things are set up and not via a
DNSName: some PKI libraries no longer examine CommonName). Otherwise
you have a big security problem, akin to the ones that happen if you
don't understand Name Constraints. Therefore the certificate needs to
have a critical extension, to ensure the PKI library understands the
semantics of the delegated credential. This gets really messy.

Of course you could try to pass in the name extracted from the Subname
to the PKI layer and verify, but that has its own issues and
considerations.

>         • spiffe://alipay.com/billing/payments

The other challenge here is any certificate for alipay.com can now
pretend to be any service. You probably don't want the easy lateral
from the webservers this enables. There are some tough problems as JC
writes in another reply, and if you are using a private PKI then the
solutions the SPIFFE people have written up to use X509 will just
work.

Sincerely,
Watson Ladd

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 04 Mar 2020 09:51:02 +1100

On Tue, Mar 3, 2020, at 18:10, Paul Yang wrote:
> 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:

Hi Paul,

As the delegated credential chains to an EE certificate, why is the information in that certificate not usable by the relying party?

---

From: "Paul Yang" <[email-masked]>
Date: Wed, 04 Mar 2020 16:36:28 +0800

> On Mar 4, 2020, at 12:46 AM, J.C. Jones <[email-masked]> wrote:
> 
> Paul,
> 
> Without getting into the details about the issues for trusting such certificates on the Web PKI, which would be its own large and contentious conversation and pull in a lot of actors from outside the  TLSWG, I would think specifically for this use case that the SubName field should use the types developed for the SubjectAlternateName extension for precision, as the Common Name field is long deprecated for being typeless and difficult to validate.

Hi J.C.,

Thanks for the SAN types suggestion and I find it’s a really good idea.

> 
> J.C.
> 
> 
> On Tue, Mar 3, 2020 at 12:11 AM Paul Yang <kaishen.yy=[email-masked] <mailto:[email-masked]>> wrote:
> Hi there,
> 
> 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 <http://a.com/>'. So we'd like to propose to add an extra field in the 'Credential' sturcture to resolve this issue as follows:
> 
> 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 <https://spiffe.io/>) and other identity specifications.
> 
> For instance, we have CN=alipay.com <http://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 <http://alipay.com/billing/payments>
> 
> Other explanation:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

---

From: "Paul Yang" <[email-masked]>
Date: Wed, 04 Mar 2020 17:29:52 +0800

> On Mar 4, 2020, at 3:12 AM, Watson Ladd <watson=[email-masked]> wrote:
> 

Hi Watson,

Thanks for reply! I agree with the concept you brought up and in fact we realized this ‘MUST NOT’ issue but have not conclusion yet so I’d like to hear more opinions from the working group.

> limitation there that makes delegated credentials a better solution?

Well, the problem is caused by the scale of the organization who wants to apply X.509 based SPIFFE. Considering an enterprise with more than 100K staffs and 1 million containers serving online, there are probably several issues:

1. The size of the credentials in the network. Typical RSA X.509 EE certificate, say with 2048-bit key, usually has a size around 1KB, but it only costs delegated credentials around 500B to hold the same public key and the signature (along with other fields like valid_time and sigalg). It reduces the X.509 EE certificate’s size in half, which is a tremendous saving of bandwidth, especially for a giant enterprise who locates its datacenter globally. And the use case we intend to is that we’d like to dispatch the EE certificate who signs the delegated credentials to end-points/servers in advance, so the EE certificate is not needed to be transmitted in the network as well - only the delegated credentials are on-air. This is important if there are 1 million containers communicating each other in the network, but it may not be essential for small scale services.

2. The security considerations of X.509. There are many extensions in the X.509 specification and most then are not needed for most intranet uses. This increases the chance that a CA operator mis-issues an EE certificate with unnecessary extensions and leads to misuse of the EE certificate. Delegated credentials can only be used for authentication so this mitigates the risks and eventually leads to a cut-down of the operating cost inside a company.

3. An internal CA in a large organization still costs no less than a real external CA. If one enterprise has more than 100K employees and several hundreds divisions inside, it would be very hard to co-ordinate with the one trusted CA root to issue short-term certificates. A practical way would be introducing more intermediate CAs into different divisions of the enterprise but that results a new management problem of how to make sure all the intermediate CAs are behaving correctly. We can introduce NameConstraints (as you mentioned) into intermediate CAs, but the operating cost of those CAs still exists.

So if we could figure out a way of adding additional identity information into delegated credentials, we can decouple the relation between an identity-consumer (the business groups/divisions) and the issuer (the enterprise trust root). The enterprise CA as a trust root can issue EE certificates for the divisions/teams with the identity of this division and then, inside the division, it just uses the EE certificate to ‘delegate’ the identity for its belonged services, with some optional/additional identity information.

So I wonder perhaps the name ’SubName’ is not accurate to depict this field, it could be changed to something like ‘additional_info’ or ‘optional_id’...

> to the PKI layer and verify, but that has its own issues and

This is why I am trying to figure out a way of limiting the SubName content.

---

From: "Paul Yang" <[email-masked]>
Date: Wed, 04 Mar 2020 17:45:00 +0800

> On Mar 4, 2020, at 6:51 AM, Martin Thomson <[email-masked]> wrote:
> 
> 

Hi Martin,

The problem is the information (or identity more precisely) in the EE certificate may not be fine-grained in our use case. The identity in the EE certificate is usually a domain name, like ‘a.com’ which represents a bundle of micro services inside. When dealing with an enormous micro services (such as 1000 different services running across 1 million container instances) communicating and authenticating to each other, we found there are problems by issuing too many X.509 certificates holding identities of every micro service (As explained in the email replying to Watson). So we encountered with delegated credential in last Novembers IETF 106 ;-)

Other than the original use case, delegated is small and agile enough for using in such micro-services case if it can carry additional information. Of course the prerequisite of this is we can figure out a way of not letting the EE certificate become another level of CA which will harm the security.