Delegated Credentials in TLS
engineering.fb.com
Delegated Credentials in TLS
1–10 of 16 posts
Re: Delegated Credentials in TLS
#2While the proposal is nice, it's a bit sad that the RFC invents its own serialization scheme instead of just using ASN.1, like everything else that touches X.509:
> The signature of the DelegatedCredential is computed over the concatenation of:
> 1. A string that consists of octet 32 (0x20) repeated 64 times.
> 2. The context string "TLS, server delegated credentials" for servers and "TLS, client delegated credentials" for clients.
> 3. A single 0 byte, which serves as the separator.
> 4. The DER-encoded X.509 end-entity certificate used to sign the DelegatedCredential.
> 5. DelegatedCredential.cred.
https://tools.ietf.org/html/draft-ietf-tls-subcerts-04#secti...
Re: Delegated Credentials in TLS
#3While the proposal is nice, it's a bit sad that the RFC invents its own serialization scheme instead of just using ASN.1, like everything else that touches X.509: > The signature of the DelegatedCredential is computed over the concatenation of: > 1. A string that consists of octet 32 (0x20) repeated 64 times. > 2. The context string "TLS, server delegated credentials" for servers and "TLS, client delegated credential…
DER encoded ASN.1 is used for the X.509 end-entity certificate, however generally this follows how CertificateVerify works in TLS 1.3 https://tools.ietf.org/html/rfc8446#section-4.4.3
Re: Delegated Credentials in TLS
#4While the proposal is nice, it's a bit sad that the RFC invents its own serialization scheme instead of just using ASN.1, like everything else that touches X.509: > The signature of the DelegatedCredential is computed over the concatenation of: > 1. A string that consists of octet 32 (0x20) repeated 64 times. > 2. The context string "TLS, server delegated credentials" for servers and "TLS, client delegated credential…
DER encoded ASN.1 is used for the X.509 end-entity certificate, however generally this follows how CertificateVerify works in TLS 1.3 https://tools.ietf.org/html/rfc8446#section-4.4.3
Hmm fair enough. Case rested then.
Re: Delegated Credentials in TLS
#5Earlier quoted context omitted.
DER encoded ASN.1 is used for the X.509 end-entity certificate, however generally this follows how CertificateVerify works in TLS 1.3 https://tools.ietf.org/html/rfc8446#section-4.4.3
Hmm fair enough. Case rested then.
generalized asn1 parsing can be super tricky and the industry is generally avoiding asn1 for new protocols. There has been some really interesting work from microsoft on verified parsers for asn1 https://www.usenix.org/system/files/sec19-ramananandro_0.pdf
Re: Delegated Credentials in TLS
#6Why would not they run their own CA for short term certs?
Few CDNs have this exact problem and they sign their short term certs with their master cert.
Re: Delegated Credentials in TLS
#7Why would not they run their own CA for short term certs? Few CDNs have this exact problem and they sign their short term certs with their master cert.
It's not feasible for everyone to become a public CA, and benefits of this solution will be available to anyone, I guess.
Re: Delegated Credentials in TLS
#8Why would not they run their own CA for short term certs? Few CDNs have this exact problem and they sign their short term certs with their master cert.
As a CA you can issue certificates for other domains as well which might be undesirable. There are existing mechanisms such as Name constrained CAs and proxy certificates to reduce this scope. While they were originally considered there are issues with them. There is no widespread support for either and there is no way to know whether both sides support them. DCs allow for a extremely minimal subset of what you might need to issue credentials with your own lifetime and it only affects you. DCs are cryptographically bound to the leaf certificate as well. A bunch of this is documented in the draft.
Re: Delegated Credentials in TLS
#9What is preventing this from turning into another "Turktrust fiasco?" Is the delegated signing privilege only valid for explicit DNS names?
https://nakedsecurity.sophos.com/2013/01/08/the-turktrust-ss...
Re: Delegated Credentials in TLS
#10What is preventing this from turning into another "Turktrust fiasco?" Is the delegated signing privilege only valid for explicit DNS names? https://nakedsecurity.sophos.com/2013/01/08/the-turktrust-ss...
All this is doing is allowing the server (or client since the protocol allows client certificates to do the same thing) to use a different key pair with a shorter validity period than the CA signed certificate.
The delegated credential is not another cerificate and doesn't have a DNS name in it at all. The original certificate who's private key was used to create the delegated credential still has that information and the client still gets that. The delegated credential only consists of four pieces of information: validity interval, public key, signature algorithm and signature. I.E. just enough information to provide the public key and verify it is signed by the CA signed certificate.
RFC is here if you want to read the details: https://tools.ietf.org/html/draft-ietf-tls-subcerts-04