I don't think Mozilla can tolerate having certs that successfully chain to a root contained in its trust store that are not BR compliant. The end user trusts Mozilla products to provide a certain level of assurance in the cert chains that it allows. Having a cert chain successfully validated with a (perhaps?) hidden caveat of "by the way, we don't actually trust this cert because it doesn't comply with accepted policies" doesn't make much sense. 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.
... What should our policy be regarding BR compliance for certificates issued by a root requesting inclusion, which were issued before the date of their request? Do we: A) Require all certs be BR-compliant going forward, but grandfather in the old ones; or B) Require that any non-BR-compliant old certs be revoked; or C) Require that any seriously (TBD) non-BR-compliant old certs be revoked; or D) something else? |
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy