On Mon, Sep 23, 2019 at 12:50 PM Dimitris Zacharopoulos <ji...@it.auth.gr>
wrote:

>
>
> 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.


No.

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."


You just quoted it.

6960 is trying to say “not revoked, suspended for now, but this may be used
to issue a legitimate certificate at some point in the future”
Read Section 5. Read the related contemporary mailing list discussions.

It would be useful to identify whether there’s an objective to the
questions, since that might help us cut down things quicker:
- Are you running a 5019 responder or a 6960 responder?
- Do you agree that the definition in 6960, Section 2.2, applies to
pre-certificates?

If you are running a 6960 responder, and you don’t believe it applies to
pre-certificates, we should work that out first.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to