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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
