> On Mar 4, 2020, at 6:51 AM, Martin Thomson <m...@lowentropy.net> wrote: > > > On Tue, Mar 3, 2020, at 18:10, Paul Yang wrote: >> 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: > > Hi Paul, > > As the delegated credential chains to an EE certificate, why is the > information in that certificate not usable by the relying party?
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. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
