1. Issuing delegate certs to Customer AF using Cross-Certification
Feb 19, 2019
David Hancock, Chris Wendt (Comcast)

2. CA intermediate certificate
Current "proxy" model for issuing TN-PoP Certs to Customer AF
Procedures and performed each time a new TN-PoP cert issued 1 2 3 4
STI-CA
CA root certificate
CA intermediate certificate
Acting as interworking function and firewall, ACME Proxy relays cert order to STI-CA.
STI-CA issues TN-level end-entity cert to ACME Proxy 2 3
ACME
Certificate path
TN Provider
ACME Proxy
Customer AF orders TN-level cert from ACME-Proxy
(ACME account pre-authorized with external account binding) 4
Customer AF downloads cert (or cert URL) from ACME Proxy 1
ACME
TN-PoP certificate
End-entity cert chains directly to STI-CA intermediate cert
Customer AF

3. New TN-POP SHAKEN 2.0 Solution
Use Cross-Certification to delegate STI-CA authority,
as specified in RFC 5280
Goal: Standard X.509 with backward compatibility for signature validation on STI-VS

4. RFC 5280 defines two classes of certs
CA certificates
MUST contain a Basic Constraints object with cA boolean set to TRUE
Certificate’s private key can be used to sign another certificate in cert path
End-entity certificates
MUST either omit the Basic Constraints object, or contain Basic Constraints with cA set to FALSE
Certificate private key cannot be used to sign another certificate

5. RFC 5280 also defines three sub-classes of CA certs
Self-issued certificate
CA cert where the issuer and subject are the same entity
Self-signed certificate (aka root cert)
CA self-issued certificate where signature can be verified using cert’s public key
Cross-certificate
CA cert where the subject and issuer are different entities

6. Using cross-certs to delegate CA authority
CA-1 can delegate its authority to another "delegate" CA-2 by issuing a cross-certificate to CA-2
The delegate CA-2 can then issue end-entity certs, chained to the cross-certificate
For domain certs, CA-1 can include a Name Constraints object in the cross-certificate to limit the Subject name-space of the end-entity certs issued by the delegate CA-2

7. Domain CA delegation example
STI-CA Intermediate/Root Certificate
Issuer: nationalCA1.com
Subject: nationalCA1.com
Basic Constraints: cA = true
CA1 public key
Signature
National CA 1
CA intermediate/root cert
Cross-certificate
Issuer: nationalCA1.com
Subject: delegateCA2.com
Basic Constraints: cA = true
Name Constraints: *.delegateCA2.com
CA2 public key
Signature
Certificate path
Delegate CA 2
cross-certificate
(with constraints)
Constraints
End-entity certificate
Issuer: delegateCA2.com
Subject: subdomain.delegateCA2.com
CA2 public key
Signature
Endpoint
end-entity cert

8. Leveraging cross-certificates for SHAKEN Customer AF case
STI-CA delegates CA responsibilities to TN Provider
STI-CA issues a cross-certificate to TN Provider
TN Provider then uses the cross-certificate to issue STI end-entity certs to its multiple Customer AFs
STI-CA includes constraints in the cross-certificate that limit the scope of end-entity certificates issued by the TN Provider (i.e., place limits on contents of TNAuthList (SPC and TNBlock))

9. CA intermediate/root cert
Issuing STI certs to Customer AF using Delegate CA model
STI-CA
STI-CA Root Certificate
Issuer: STI-CA
Subject: STI-CA
STI-CA public key
Signature
CA intermediate/root cert 1
Issue cross-certificate with constraints (ACME)
Certificate path
TN Provider
Cross-certificate
Issuer: STI-CA
Subject: TN Provider
TNAuthList constraints
TN Provider public key
Signature
Delegate CA
cross-certificate
(with constraints) 2
Issue STI end-entity certificates (ACME)
Constraints
STI end-entity Certificate
Issuer: TN Provider
Subject: CAF-3
TNAuthList
SPC value
Customer AF TNs
Customer AF public key
Signature
Customer AF 1
Customer AF 2
Customer AF 3
STI cert 1
STI cert 2
STI cert 3

10. How are constraints established and enforced?
The STI-PA authorizes constraints per TN Provider; constraints conveyed to STI-CA in SPC Token
STI-CA issues cross-certificate with constraints authorized by STI-PA to TN Provider
TN Provider issues STI end-entity certificates to Customer AFs within scope of constraints
Verification services verify that STI end-entity certificates honor constraints

11. CA intermediate/root cert
The complete Customer AF certificate management flow
STI-PA
STI-CA
CA intermediate/root cert 1
Get SPC Token with constraints 2
Order cross-certify cert
with constraints (via ACME)
TN Provider
Delegate CA 4
Store issued STI certificate
cross-certificate
with constraints
STI-CR 3
Order STI certificate
STI certificate 5
Download cert STI-CR URL
Customer AF