| Yes, I think it's fair for Mozilla to stake out the position that only those certs which comply with the relevant standards, policies, etc. will be accepted. Indeed, much of the other discussion on this list of late would support such a statement. That said, I suppose situations may arise where the interests of the community and relying parties are better served by granting exceptions or waivers to that position. If a CA has a compelling argument for seeking such a waiver and would like to make their case, I suppose it doesn't hurt to hear them out. Perhaps some guidelines would be in order? * The non-compliant certs must not have the potential to cause harm. For example, maybe a compelling case could be made for allowing certs with faulty SAN data but I'm not sure a compelling case could be made for allowing SHA1 certs. * Mozilla has no obligation to create or maintain special functionality in its software to support non-compliant certs. A CA requesting a waiver would need to accept the risk that some of their non-compliant certs could fail to validate in Mozilla products at some point in the future. * In the spirit of transparency, a CA requesting a waiver should be prepared to provide documentation as to how many certs are to be covered by the waiver. For example: "As of (date) there are (number) certificates that do not comply with (specific requirements/policies) in the Not-before date range of (month/year) to (month/year)." Such documentation should be updated "regularly". * I think a CA should be made to explain why they are unable to bring their certs into compliance. There could be an understandable reason, so let's hear it. ("We don't want to" or "We can't afford it" are not acceptable reasons.) I think the bottom line has to be the trust relationship between Mozilla products and relying parties (end users specifically). If Mozilla says a connection is secure it has to mean that all elements of the connection meet the standards of technical excellence or, failing that, that Mozilla has deemed that the technical elements and special circumstances warrant the continued trust and use of that connection by the user.
On 21/08/17 06:20, Peter Kurrasch wrote: > The CA should decide what makes the most sense for their particular > situation, but I think they should be able to provide assurances that > only BR-compliant certs will ever chain to any roots they submit to the > Mozilla root inclusion program. So you are suggesting that we should state the goal, and let the CA work out how to achieve it? That makes sense. I agree with Nick that transparency is important. Is there room for an assessment of risk, or do we need a blanket statement? If, say, a CA used short serials up until 2 years ago but has since ceased the practice, we might say that's not sufficiently risky for them to have to stand up and migrate to a new cross-signed root. I agree that becomes subjective. Gerv | ||
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
