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?

Dimitris.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to