On Mon, Sep 23, 2019 at 9:31 AM Dimitris Zacharopoulos via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote:
> On 20/9/2019 11:00 μ.μ., Wayne Thayer wrote: > > On Fri, Sep 20, 2019 at 4:56 AM Dimitris Zacharopoulos > > <ji...@it.auth.gr <mailto:ji...@it.auth.gr>> wrote: > > > > <snip> > > > > Using the following practice as described in RFC 6960 should not > > be a violation of the BRs. That is, answering revoked where a > > pre-certificate has been issued but not the final certificate > > should be OK as long as the response contains the Extended Revoked > > extension and the revocationReason is |certificateHold|. With this > > practice, it is very clear that the final certificate has > > not been issued, so would this be considered a violation of the > > Mozilla policy? > > > > Yes, I think it would be a violation of Mozilla policy for a CA's OCSP > > responder to return a certificateHold reason in a response for a > > precertificate. As you noted, the BRs forbid certificate suspension. > > Mozilla assumes that a certificate corresponding to every > > precertificate exists, so the OCSP response would be interpreted as > > applying to a certificate and thus violating the BRs. > > > > In practice, I also think that Ryan has raised a good point about OCSP > > response caching. If a revoked response for a precertificate were > > supplied by a CA, would the Subscriber need to wait until that > > response expires before using the certificate, or else risk that some > > user agent has cached the revoked response? > > Dear Wayne, > > This list has discussed about compatibility issues several times in the > past, so we must consider how Mozilla supports the majority of clients. > RFC 6960 does not just mandate that the revocationReason is > |certificateHold|. It requires a certain revocation date AND a specific > extension that unambiguously point to a "non-issued" Certificate, not a > "Suspended" Certificate in general. This means that there is technical > language to distinguish the case of a Certificate being "suspended" and > a Certificate being "non-issued". > > OCSP response caching is equally problematic for "unknown" responses > which are also cached. The behavior of clients in sight of an "unknown" > or "revoked"-with-additional-info response, should be more or less the > same (i.e. don't trust the certificate). > > Neither the Mozilla policy language nor the ||BRs support the assumption > that whenever we have an OCSP response of "certificateHold", this means > the certificate is "Suspended". My interpretation is that if a response > provides all of the following information: > - status --> revoked > - revocation reason --> certificateHold > - revocationTime --> January 1, 1970 > - MUST NOT include a CRL references extension or any CRL entry extensions > - includes the extended revoke extension > > then this is the consistent semantics for a "non-issued" certificate, > not about a Certificate that was "issued" and then "suspended". > > Is this a reasonable interpretation? I do not believe this is a reasonable interpretation, precisely because 6960 uses this status so that the revocation is temporary, and attackers can not use this to cause responders to mark serials they have not yet used as revoked. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
