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님이 작성:
> Introduction > > During the course of bug 1815355 > <https://bugzilla.mozilla.org/show_bug.cgi?id=1815355>, > <https://bugzilla.mozilla.org/show_bug.cgi?id=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 > <https://wiki.mozilla.org/CA/EV_Processing_for_CAs#EV_TLS_Capable>. 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 > <https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#312-required-audits> > ). > > 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 > <https://www.rfc-editor.org/rfc/rfc5280#section-6.1> and process them as > described in section 6.1.3 > <https://www.rfc-editor.org/rfc/rfc5280#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> > > https://crt.sh/?graph=40293204&opt=nometadata (Shows how an Intermediate > CA chains to multiple trust anchors) > <https://crt.sh/?graph=40293204&opt=nometadata> > <https://crt.sh/?graph=40293204&opt=nometadata> > > - 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 > > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/dace011c-0c29-43b7-b80a-61e5170bea33n%40mozilla.org.
