On 26/10/16 02:30, Ryan Sleevi wrote: > So we certainly know that Mozilla's policies are, in some ways, > designed to minimize the number of errors that users are presented > with, by allowing a gradual fade out of insecure or undesirable > practices. A change in the BRs is, in theory, supposed to be fully > reflected in all valid certificates within 39 months of the effective > date, after which time, application software vendors can remove > support.
I certainly agree that this is the goal. And, insofar as the BRs are only meaningful to CAs because root program policy requires it, we need to make sure that Mozilla's application of the BRs is correctly scoped. Perhaps it would be worth revisiting the reasons why technically constrained sub-CAs were excluded from Mozilla policy. As I remember, this was a privacy requirement - CAs wanted to be able to have some sub-CAs which were not publicly disclosed, as Mozilla policy was set to require. The compromise reached was that public disclosure was not necessary if the sub-CA were name-constrained. Am I correct in this, or were there other reasons? Are there parts of Mozilla's policy and/or the BRs that it would be reasonable for such sub-CAs to be exempt from? If privacy was the extent of the issue, would it solve the problem to change bullet 8 of the inclusion policy as follows? 8. All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to a certificate included in Mozilla’s CA Certificate Program, MUST be operated in accordance with Mozilla’s CA Certificate Policy and MUST either be technically constrained or be publicly disclosed and audited. -> 8. All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to a certificate included in Mozilla’s CA Certificate Program, MUST be operated in accordance with Mozilla’s CA Certificate Policy (including being included in audits) and MUST either be technically constrained or be publicly disclosed. Gerv _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
