1 / 11

Issuing delegate certs to Customer AF using Cross-Certification Feb 19, 2019

This solution leverages cross-certification to delegate authority, allowing STI-CA to issue TN-PoP certificates to Customer AF, ensuring standard X.509 compliance with backward compatibility for signature validation.

desrosiers
Download Presentation

Issuing delegate certs to Customer AF using Cross-Certification Feb 19, 2019

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Current "proxy" model for issuing TN-PoP Certs to Customer AF STI-CA Procedures and performed each time a new TN-PoP cert issued CA root certificate CA intermediate certificate STI-CA issues TN-level end-entity cert to ACME Proxy Acting as interworking function and firewall, ACME Proxy relays cert order to STI-CA. 2 1 2 3 3 4 1 4 ACME Certificate path TN Provider ACME Proxy Customer AF downloads cert (or cert URL) from ACME Proxy • Customer AF orders TN-level cert from ACME-Proxy • (ACME account pre-authorized with external account binding) ACME End-entity cert chains directly to STI-CA intermediate cert TN-PoP certificate 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. Issuing STI certs to Customer AF using Delegate CA model • STI-CA Root Certificate • Issuer: STI-CA • Subject: STI-CA • STI-CA public key • Signature STI-CA CA intermediate/root cert Issue cross-certificate with constraints (ACME) Certificate path 1 2 TN Provider • Cross-certificate • Issuer: STI-CA • Subject: TN Provider • TNAuthList constraints • TN Provider public key • Signature Delegate CA cross-certificate (with constraints) 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. The complete Customer AF certificate management flow STI-CA STI-PA CA intermediate/root cert Get SPC Token with constraints Order cross-certify cert with constraints (via ACME) 1 3 5 4 2 TN Provider Store issued STI certificate Delegate CA cross-certificate with constraints STI-CR Order STI certificate STI certificate Download cert STI-CR URL Customer AF

More Related