>From what I can tell, the new Mozilla policy covers both SSL and client cert issuing intermediates. There are some interesting complications with client certs that some CAs may experience since client certs are often used only for access control and not easily discoverable. Plus, many enterprises use the intermediate solely with private networks, making even the SSL certs issued from the intermediate fairly non-discoverable. A policy to publicly disclose this info will result in more ambiguous names and, possibly, a lot of hurried key ceremonies to try and mask the name of the networks protected by intermediates.
May 30th is an awfully short date to review this information, make the necessary changes to intermediate names (to avoid potentially violating confidentiality clauses), and report back to Mozilla. I assume that is the purpose of the legacy system exemption. Can any CA claim "legacy system" to freely buy themselves more time to rename intermediates? What if the legacy system needs to be private for another 15 years? Should a timeline be given about when the phase-out should occur? Or is that subject to private negotiations between Mozilla and the CA? Finally, if a CA were to, hypothetically, implement a rolling intermediate plan where the number of orgs using a particular intermediate was limited, the number of intermediates required for disclosure could become very large. This configuration would alleviate the oft cited "too big to fail" scenario, but requiring constant disclosure would discourage its implementation. Would the CA need to re-disclose its list whenever it hit its new limit (say 100 orgs per intermediate)? I'm not against the disclosure policy (and advocated it in the CAB Forum). However, I think the change may require some CAs to do more work than the simple question implies and may impact several large networks. This is why the CAB Forum's BRs limited the disclosure to Cross Certificates and not all intermediate certificates. >> "For instance, if all intermediate certs are either technically constrained (via EKU and name constraints) or publicly disclosed and audited, then someone could create a database representing the publicly disclosed intermediate certs. Then if an SSL cert chains to an intermediate that is not technically constrained, the database can be checked, and if the intermediate is not there, then an error can be generated." This would never be the case unless a CA was in clear violation of the Mozilla policy. Thanks for the answers! Jeremy -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Kathleen Wilson Sent: Monday, May 12, 2014 5:39 PM To: [email protected] Subject: Re: DRAFT: May CA Communication On 5/12/14, 4:07 PM, Jeremy Rowley wrote: > Won't this policy encourage bad naming practices in intermediate > certificates? If a CA creates an intermediate certificate for Company > ABC, I'd name it "Intermediate Cert 1" to conceal which customer is > using the certificate. I think if someone was truly concerned about others knowing that a particular CA issued an intermediate certificate to Company ABC, then they would name it "Intermediate Cert 1" regardless of this policy. If Company ABC's intermediate certificate signs SSL certs for public websites, then that information will become public knowledge soon enough already. > Simply requiring disclosure of the cross-certs existence accomplishes > little unless it is accompanied by disclosure of the Subordinate CA > since the real value is knowing whether the certificates are > controlled by the audited CA or an audited third party. I think it depends on what you want to do with the information. For instance, if all intermediate certs are either technically constrained (via EKU and name constraints) or publicly disclosed and audited, then someone could create a database representing the publicly disclosed intermediate certs. Then if an SSL cert chains to an intermediate that is not technically constrained, the database can be checked, and if the intermediate is not there, then an error can be generated. > > Also, I don't see how "for each subordinate CA who needs to operate in > their legacy design a little longer, the attached document explains > the reason that continued operation is needed and their target date for resolution. > <attach document(s) to response>" fits with the requirement that > either the intermediate be disclosed or technically constrained. Why > is this an option? Can't you disclose they exist without affected the > certificate's continued operation? What constitutes a "Legacy Design" in this case? > Something that can't be audited or constrained? It doesn't meet the requirement. It just gives them a little more time to meet the requirement. For some CAs' customers, there may be situations that occurred that prevented them from meeting the target date, as happens for many software projects. For instance, they could have begun the rollover to a new hierarchy, but discovered a problem that required further design and delay. And, for whatever reason, the customer may not want their legacy system to be publicly disclosed. Kathleen _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
