On Thu, Aug 29, 2019 at 10:38 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Thanks for posting this Curt. We investigated and posted an incident > > report on Bugzilla. The root cause was related to pre-certs and an error > in > > generating certificates for them. We're fixing the issue (should be done > > shortly). I figured it'd be good to document here why pre-certs fall > under > > the requirement so there's no confusion for other CAs. > > > > Oh, Jeremy, you were going so well on the bug, but now you've activated my > trap card (since you love the memes :) ) > > It's been repeatedly documented every time a CA tries to make this > argument. > > Would you suggest we remove that from the BRs? I'm wholly supportive of > this, since it's known I was not a fan of adding it to the BRs for > precisely this sort of creative interpretation. I believe you're now the > ... fourth... CA that's tried to skate on this? > > Multiple root programs have clarified: The existence of a pre-certificate > is seen as a binding committment, for purposes of policy, by that CA, that > it will or has issued an equivalent certificate. Is there a requirement that a CA return a valid OCSP response for a pre-cert if they have not yet issued the equivalent certificate? Is there a requirement that a CA return a valid OCSP response for a serial number that has never been assigned? I know of several OCSP responders that return a HTTP error in this case. Thanks, Peter _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
