On 20/9/2019 11:00 μ.μ., Wayne Thayer wrote:
On Fri, Sep 20, 2019 at 4:56 AM Dimitris Zacharopoulos
<[email protected] <mailto:[email protected]>> 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
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
