Navigating Revocation through Eternal Loops and Land Mines Santosh Chokhani (chokhani@orionsec.com)

1. Navigating Revocation through Eternal Loops and Land MinesSantosh Chokhani (chokhani@orionsec.com)

2. Prior Research Motivation Notations Circularities due to Self-Issued Certificates Circularity in Indirect CRL Circularities in OCSP Responder CRL and OCSP Responder Certification Paths Summary Outline of Presentation

3. Examined several research papers and projects Some based on one reviewer’s comment Findings None of them deal with the issues we are dealing with Issues we are dealing with are concrete and deterministic (some of the research deals with heuristics or reasoning under uncertainty) Issues we are dealing with relate to gaps in the standards that can cause security problems Prior Research

4. Find gaps in the PKI related Internet and X.509 standards that can cause security problems Identify solutions that can mitigate (preferably fully) the security flaws Motivation

5. Use (name, key) 2-tuple for issuer and subject An entity can have multiple keys Examples of Notation Certificate (B, B-1)R, R-1 Certificate issued to Subject DN “B” with Subject Public Key “B-1”. Certificate signed by Issuer DN “R” using private key companion to Issuer Public Key “R-1” CRLB, B-1 CRL signed by Issuer DN “B” using private key companion to Issuer Public Key “B-1” OCSPO, O-1 OCSP response signed by Responder with DN “O” using private key companion to Responder Public Key “O-1” Motivation Complete (covers both name and key) Provides for easy chaining of name and signature (as required by X.509 and Internet Standards) Certificate (B, B-1)R, R-1,Certificate (C, C-1)B, B-1 Notations

6. To Maintain Trust Paths When CA re-keys To Have Separate Certificate and CRL Signing Keys Enhances Operational Security Certificate signing could require two-person control at all times CRL signing can be automated operation Why Do PKIs Use Self-Issued Certificates

7. Self-Issued Scenario: CA Re-Keys Problem Signature verification on CRLB, B-2 requires trusting Certificate (B, B-2)B, B-1. But, to trust Certificate (B, B-2)B, B-1 CRLB, B-2is needed. • Solution Alternatives • Obtain a new certificate from parent CA • Sign CRL using all “valid” keys • Use “No-check” extension • Relax CRL checking requirements

8. Solution: Obtain a New Certificate from Parent • In other words, eliminate self-issued certificate. • Parent may not be available when a CA re-keys (minor drawback)

9. Solution: Sign CRL Using All Active Keys • Benefits • Commercial products work well with this approach • Simplest and most secure binding between certificate and CRL signer Need to keep all active keys (minor drawback)

10. Solution: Use No-Check Extension • What to do when Certificate (B, B-2)B, B-1is compromised • Is the approach standard compliant? (not in strict sense) • Do products support this? (not likely)

11. In other words, “no check”, without asserting no-check Issues What to do when Certificate (B, B-2)B, B-1is compromised CA B can request revocation of Certificate (B, B-1)R, R-1 Is the approach standard complaint Not in strict sense Do commercial products support this Probably not Solution: Relax CRL Checking Requirement

12. Issue old with new and new with old notAfter date in Certificate (B, B-1)B, B-2 = latest notAfter in certificates signed using private key companion to B-1 Secure from cryptanalysis viewpoint notAfter date in Certificate (B, B-2)B, B-1 latest notAfter date in certificates signed using private key companion to B-1 Secure from cryptanalysis viewpoint Assumes that subscriber will obtain new root when they get new certificate Other considerations same, except No parent to obtain a certificate from Signing CRL with all keys the best alternative What if the CA is a Trust Anchor

13. Self-Issued Scenario: CA Uses Different Key for CRL Signing Problem Signature verification on CRLB, B-2 requires trusting Certificate (B, B-2)B, B-1. But, to trust Certificate (B, B-2)B, B-1 CRLB, B-2is needed. • Solution Alternatives • Obtain a new certificate from parent CA • Sign CRL using all “valid” keys • Use “No-check” extension • Relax CRL checking requirements

14. Solution: Obtain Certificate from Parent • In other words, eliminate self-issued certificate. • Parent may not be available when a CA re-keys (minor drawback)

15. Solution: Use No-Check Extension • What to do when Certificate (B, B-2)B, B-1is compromised • Is the approach standard compliant? (not in strict sense) • Do products support this? (not likely)

16. In other words, “no check”, without asserting no-check Issues What to do when Certificate (B, B-2)B, B-1is compromised CA B can request revocation of Certificate (B, B-1)R, R-1 Is the approach standard complaint Not in strict sense Do commercial products support this Probably not Solution: Relax CRL Checking Requirement

17. Instead of getting certificate from parent, use two trust anchors (one to verify certification paths and one to verify root issued CRL) Constraint on the CRL signing trust anchor may not be technically enforceable, but the Root can be operationally trusted to not issue certificates using CRL signing key Other considerations remain the same, except Revocation requires out-of-band means to notify relying parties to delete the trust anchor What if the CA is a Trust Anchor

18. Indirect CRL Some differences from above scenarios See paper for details OCSP Circularity due to Responder providing its own status Solution OCSP client check OCSP Responder certificate (does not point to itself as its own OCSP Responder) Circularity in trust path Circularity in Other Revocation Mechanisms

19. Circularity in OCSP Responder Trust Path Solution: Responder should not provide status of CA certificates in the Responder Certification Path This does not mean that a Responder can not provide status of CA certificates in a certification path. For example, if each of the CA issued a certificate to the Responder, then the issuing CA’s subordinate CA status can be securely provided by the Responder Circularity is not a concern for the two major OCSP clients since they require the CA-delegated model or trust anchor model, both of which eliminate circularity

20. CRL Certification Path Problem Problem:Two CAs with name “A” can confuse the relying party in checking a certificate on CRL issued by wrong “A” Commercial products requiring same key to sign certificate and CRL do not have this problem The problem can be real in Bridge – Bridge environment where name constraints are not enforced on shared service providers In Bridge – Bridge environment, the problem is not fixed by the new requirement of terminating the certification paths at the same trust anchor Solution: Name matching at each layer in certification path; also helps with computational complexity

21. Problem akin to CRL certification path Not as acute Major OCSP client vendor ensure security through trust model Responder is either a trust anchor or issued a certificate signed by the same CA and same key as the certificate in question OCSP Certification Path Problem

22. Can lead to circularity Not checking revocation status of self-issued certificates is not the answer There are standards-compliant alternatives to remove circularity Selection of the alternative may depend on your PKI environment Summary: Self Issued Certificates

23. Standards do not provide guidance on CRL certification paths This lack of guidance could lead to insecure results in Bridge — Bridge cross certified environment when name constraints may not always be used Problem only surfaces when CA names collide Solution is to do name matching at each layer of certification path Reduces computational complexity for certification path development while enhancing security Commercial products that require the same key to sign certificate and CRL do not have the security problem Summary: CRL Certification Path

24. Standards do not provide guidance on OCSP Responder certification path This lack of guidance could lead to insecure results in Bridge — Bridge cross certified environment when name constraints may not always be used A solution was developed that can reduce the computational complexity for certification path development while enhancing security Popular commercial products do not have the security problem They require the same key to sign certificate in question and OCSP Responder certificate; or They require OCSP Responder to be a trust anchor Trust anchor solution may not be scalable in cross certified and Bridge environments unless Responders obtain the responses from each other and re-sign the responses Summary: OCSP Responder Certification Path

25. Questions