Lessons Learned for Audit Scope when Cross - Certified

[Thomas Zermeno]

Introduction 

During the course of bug 1815355, the community had the opportunity to analyze a CA audit scope issue that involved a cross-certified Root CA. Asseco Data Systems and SSL.com prepared this write-up to share their experience with the larger community, hoping to improve the knowledge of CA audit scopes and help other CAs avoid similar situations. 

The parameters of this use case are as follows:  

• Root CA1 was designed to create Issuing CAs that would issue only non-EV Certificates. It was included in Root Store Programs without EV treatment being requested by CA1. 
• Root CA1 issued several TLS Issuing CAs, all of which were issuing non-EV TLS Certificates (i.e. end-entity certificates that did not assert any policy OID that would enable “EV treatment”). 
• Root CA1 and TLS Issuing CAs were audited according to “WebTrust for CA SSL Baseline with Network Security”. 
• Root CA2 was designed to create Issuing CAs that would issue both EV and non-EV Certificates. It was included in Root Store Programs with EV treatment being requested by CA2. 
• CA2 made a cross-signing agreement with CA1 so that Root CA2 would cross-sign Root CA1 and had a contractual requirement that Root CA1 would not be allowed to issue EV TLS Certificates. 
• CA2 created a Cross-Certificate that contained the public key of Root CA1, signed by the private key of Root CA2. 
• CA2 did not include policy OID restrictions in the Cross-Certificate's certificatePolicies extension. 
• Based on the above information, CA2 did not include the “WebTrust for CA Extended Validation SSL” audit criteria in the scope of the Cross-Certificate, and neither did CA1 include these audit criteria in the scope of Root CA1 and its TLS Issuing CAs. 

The problem 

Each CA should have considered the alternative trust paths and adjust the audit scope accordingly. Even if Root CA1 and its Issuing CAs were not intended to be used to issue EV TLS Certificates and Root CA1 was included to Root Stores without “EV treatment”, the fact that there was an alternative path (through Root CA2) made Root CA 1 and its Issuing CAs technically capable of issuing EV TLS Certificates. Based on the policies of root store programs, an audit showing conformance with the EV policy is required for any technically capable CA (for example, see Mozilla’s RSP). 

The solution 

An important lesson learned from this use case is that when a CA considers the audit scope for each CA Certificate, it must consider ALL possible certification paths that can assert (per RFC 5280) an EV-enabling policy OID, chaining to an EV-enabled Root and if there is even one such path, the affected CAs need to be added to the EV audit scope regardless of other certification paths or whether this technical capability is being used to issue EV Certificates or not. 

In our example, a mitigation that could have prevented the technical capability of Root CA1 issuing EV Certificates would be to include specific policy OIDs in the certificatePolicies extension of the Cross-Certificate, none of which would enable “EV treatment” to issued certificates chaining to that Cross-Certificate. RFC 5280 conforming implementations need to build a valid policy tree according to the Basic Path Validation algorithm described in section 6.1 and process them as described in section 6.1.3 of RFC 5280. The lack of an EV-enabling policy OID in the Cross-Certificate should block the assertion of an EV-enabling policy OID in an end-entity certificate chaining to that Cross-Certificate. We were able to confirm that at least Firefox and Chromium properly validate the policy tree. 

Tools to use 

In addition to the above guidance, we would like to suggest some tools that present graphs of possible available certification paths to a given CA Certificate (once again, we would like to thank Sectigo for developing and making these tools publicly available): 

https://crt.sh/?graph=40293204&opt=nometadata (Shows how an Intermediate CA chains to multiple trust anchors) 

• https://crt.sh/?caid=30737 (Shows that this CA is trusted for EV TLS treatment) 

Note how SSL.com is EV SSL enabled if the Certum EV policy OID is used. 

Epilogue 

This write-up explains a gap which may arise due to the complexity of the cross-certification and the audit scope which affects two different CAs/organizations, especially considering the evolution of root store policies and expectations. It also attempts to provide guidance and useful tools for other CAs to avoid such pitfalls. We hope this information is useful to the community. 

 

Sincerely, 

Asseco Data Systems and SSL.com 

[passerby184]

looks like google group ate the pictures. although they must be table in the link

2023년 6월 1일 목요일 오전 1시 34분 49초 UTC+9에 Thomas Zermeno님이 작성: