Dear Wayne,
According to section 2.2 of RFC 6960, an OCSP responder may respond
"revoked" for a "non-issued" Certificate. It even allows this response
for "unknown" Certificates in order to support backwards compatibility
with implementations of RFC 2560.
In addition to that, section 4.4.8 labeled "Extended Revoked Definition"
says:
"This extension MUST be included in the OCSP response when that response
contains a "revoked" status for a non-issued certificate".
Also, from section 2.2 <https://tools.ietf.org/html/rfc6960#section-2.2>
When a responder sends a "revoked" response to a status request for a
non-issued certificate, the responder MUST include the extended revoked
definition response extension (Section 4.4.8) in the response,
indicating that the OCSP responder supports the extended definition of
the "revoked" state to also cover non-issued certificates. In addition,
the SingleResponse related to this non-issued certificate:
1. the responder MUST include the extended revoked definition response
extension
2. In addition, the SingleResponse related to this non-issued certificate:
* MUST specify the revocation reason certificateHold (6),
* MUST specify the revocationTime January 1, 1970, and
* MUST NOT include a CRL references extension (Section 4.4.2) or any
CRL entry extensions (Section 4.4.5).
By reading the BRs (section 6.9.13), it is clear that TLS Certificates
are not allowed to be "suspended". However, if an RFC 6960 compliant
OCSP responder responds with "revoked" for an unknown serial number and
then issues a certificate with the same requested serial number, it will
later return a response "good". This seems to be an allowed practice
therefore it should be OK for a responder to change a "revoked" status
to "good". In addition to that, 6960 demands that for non-issued
Certificates, the responder must use the revocationReason "certificateHold".
To summarize:
* The BRs reference RFC 6960
* The BRs forbid to have Certificates "suspended" (i.e.
revocationReason |certificateHold|)
* revoked-for-unknown must contain the Extended Revoked extension, so
a client knows that this was a response for a non-issued certificate.
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?
I added this as a comment to https://github.com/mozilla/pkipolicy/issues/189
because I know that this mailing list messes up the formatting.
Thanks,
Dimitris.
On 2019-09-19 8:02 μ.μ., Wayne Thayer via dev-security-policy wrote:
I have gone ahead and added a section titled "Precertificates" [1] to the
Required Practices wiki page.
I have also updated a policy issue [2] suggesting that this be moved into
the Root Store policy, and added a new issue [3] suggesting that we clarify
the acceptable use of the "unknown" OCSP response.
I plan to sponsor a CAB Forum ballot to resolve the inconsistency with BR
7.1.2.5.
- Wayne
[1]
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates
[2] https://github.com/mozilla/pkipolicy/issues/138
[3] https://github.com/mozilla/pkipolicy/issues/189
On Tue, Sep 17, 2019 at 6:10 PM Wayne Thayer <wtha...@mozilla.com> wrote:
Version 3 of my proposal replaces Jeremy's suggested examples with Andrew
and Ryan's:
The current implementation of Certificate Transparency does not provide
any way for Relying Parties to determine if a certificate corresponding to
a given precertificate has or has not been issued. It is only safe to
assume that a certificate corresponding to every precertificate exists.
RFC 6962 states “The signature on the TBSCertificate indicates the
certificate authority's intent to issue a certificate. This intent is
considered binding (i.e., misissuance of the Precertificate is considered
equal to misissuance of the final certificate).”
However, BR 7.1.2.5 states “For purposes of clarification, a
Precertificate, as described in RFC 6962 – Certificate Transparency, shall
not be considered to be a “certificate” subject to the requirements of RFC
5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile under these Baseline Requirements.”
Mozilla interprets the BR language as a specific exception allowing CAs
to issue a precertificate containing the same serial number as the
subsequent certificate [1]. Otherwise, Mozilla infers from the existence of
a precertificate that a corresponding certificate has been issued.
This means, for example, that:
* A CA must provide OCSP services and responses in accordance with
Mozilla policy for all certificates presumed to exist based on the presence
of a Precertificate, even if the certificate does not actually exist
* A CA must be able to revoke a certificate presumed to exist, if
revocation of the certificate is required under Mozilla policy, even if the
certificate does not actually exist.
* If any corresponding certificate with the same serial number and issuer
exists, and can not be verified to match the precertificate using the
algorithms in RFC 6962, it will be considered misissued.
* In examining historical issuance, the CA must consider both final
certificates and precertificates, even if the precertificate did not
ultimately result in the issuance of a certificate.
I propose adding this language to our "Required Practices" wiki page [2],
then introducing a CAB Forum ballot that limits the scope of BR 7.1.2.5 to
serial numbers. That still leaves some uncertainty about the use of the
"unknown" response for precertificates (and in general), although Ryan made
some good points about why using this status beyond the very narrow scope
described in RFC 6960 section 2.2 is a bad idea.
Once again, I will greatly appreciate your feedback on this topic. Since
this is a practice and not official policy, I'll go ahead and update the
wiki when I sense that we're in agreement here.
- Wayne
[1] https://cabforum.org/pipermail/public/2014-January/002694.html
[2] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
On Tue, Sep 17, 2019 at 8:28 AM Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 17 Sep 2019, at 16:14, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org <mailto:
dev-security-policy@lists.mozilla.org>> wrote:
On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Hi Kurt. I agree, hence why I proposed:
"- I would also like to see BR 4.9.10 revised to say something
roughly
along these lines:
'If the OCSP responder receives a status request for a serial number
that has not been allocated by the CA, then the responder SHOULD
NOT
respond with a "good" status.’"
I suppose one issue there is for CAs which allocate the serial number
very
early on in the issuance workflow - signing a dummy certificate with an
untrusted key, for instance, but not committing the CA to actually
producing either a pre-certificate or certificate (e.g, because the
applicant has insufficient funds to complete the process). It would not
seem correct to start answering (affirmatively) OCSP requests where no
artefact has been signed by a trusted key.
Why does a CA need to sign something to allocate a serial? Could you
expand
a bit more on that?
Yes - on further consideration, I could have been a lot clearer. I didn’t
mean that a CA _has_ to sign something to allocate a serial in some
internal database; merely that the allocation of a serial number, in
itself, isn’t the trigger (in my opinion, of course) for any OCSP server to
start responding to the (Issuer, Serial Number) request with successful
response codes.
What I meant was that some workflows allocate a serial number, sign a
dummy certificate containing that serial number (with an untrusted key),
which then flows through with linting checks, and so on. But the decision
to sign the said certificate with a trusted key has not yet been made
(officially). But when any object (precertificate, certificate) containing
that allocated serial number gets signed with a trusted key, it is a
reasonable expectation for relying parties to be able to query OCSP
services and not get a “Never heard of it” answer (whether that’s a RFC
6960 4.4.8 response, or an “unauthorized”, or whatever).
In other words, Rob’s original language which refers purely to the
(CA-internal) allocation of the serial number as the triggering event seems
not to cover all relevant cases. Not that I’ve been able to come up with
any better language, I should add.
Regards,
Neil
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
