[+dev-tech-crypto; Please discuss technical details of mozilla::pkix on dev-tech-crypto and save dev-security-policy for discussion about Mozilla's CA inclusion policies. There has been and will be a lot of technical discussion on the behavior differences and rationale for those differences--e.g. why policy mapping isn't supported and why policy constraints are ignored--on the dev-tech-crypto mailing list. You can subscribe at https://lists.mozilla.org/listinfo/dev-tech-crypto]
Responses inline. On Mon, Apr 28, 2014 at 4:52 PM, Brown, Wendy (10421) < wendy.br...@protiviti.com> wrote: > Kathleen - > > In looking at this Draft CA Communications, I looked at the description of > Behavior change and #5 doesn't look like the change is the right > interpretation: > > 5. If the inhibitAnyPolicy extension is present in an intermediate > certificate or trust anchor and children certificates have a certificate > policy extension the verification will fail. bug 989051 > I believe the above description of the behavior is wrong in a small but important way. A better description would be "A certificate will not be considered an EV certificate if mozilla::pkix cannot build a path to a trusted root that does not contain any certificates with the inhibitAnyPolicy extension. However, such certificates will still validate as non-EV as long as there are no non-policy-related issues." Please check out the bug: bug https://bugzilla.mozilla.org/show_bug.cgi?id=989051. We know the current behavior is wrong (at least, non-optimal). At the same time, it is a low-priority issue because we only care about certificate policies for determining whether or not to show the green site identity block for EV certificates, and we suspect that no EV CAs in Mozilla's program use inhibitAnyPolicy. Some background: The original implementation of mozilla::pkix forced inhibitAnyPolicy=true; i.e. we did not support anyPolicy at all. My hope was that, when we define the WebPKI profile of X.509, that we would not have anyPolicy in the profile. However, we found that some CAs in our CA program depend on anyPolicy support for the EV certificates they issued, so we had to add anyPolicy support after the fact, and we did it in the simplest way possible because we were eager to work on higher-priority issues. If somebody contributes better inhibitAnyPolicy support (with tests) then that patch would be accepted. (Compare that to policy mapping, where I probably wouldn't accept a patch even if one was contributed for free.) Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
