On 2019-09-23 1:37 μ.μ., Ryan Sleevi via dev-security-policy wrote:
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.
Doesn't this break compatibility with older clients? It is older clients
that need to see "revoked" which is equivalent to "not good" for cases
of "non-issued" Certificates. I think this is what 6960 is trying to
accommodate. Older clients will see "revoked" but newer clients will see
"revoked" plus additional information to interpret as "non-issued". Is
there any specific text in the Mozilla Policy or the BRs that strictly
forbids the use of this RFC 6960 practice?
BRs 4.9.13: "The Repository MUST NOT include entries that indicate that
a Certificate is suspended."
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
