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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
