DigiCert OCSP services returns 1 byte

2260 views
Skip to first unread message

Curt Spann

unread,
Aug 27, 2019, 4:08:33 PM8/27/19
to mozilla-dev-s...@lists.mozilla.org
Hello,

I created the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1577014

Peter Gutmann

unread,
Aug 27, 2019, 9:27:10 PM8/27/19
to mozilla-dev-s...@lists.mozilla.org, Curt Spann
Curt Spann via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

Maybe it's an implementation of OCSP SuperDietLite, 1 = revoked, 0 = not
revoked.

In terms of it being unsigned, you can get the same effect by setting
respStatus = TRYLATER, no signature required.

Peter.

Jeremy Rowley

unread,
Aug 27, 2019, 9:54:06 PM8/27/19
to Peter Gutmann, mozilla-dev-s...@lists.mozilla.org, Curt Spann
Our super unpublished RFC.

Sadly no. We're still investigating, but it looks like it has to do with pre-certs and the way the system responds if when the actual cert never issued. We're working on an incident report. Funny enough (and not in the ha-ha way), the system works if the pre-cert was revoked but not if the pre-cert issued but something terrible happened between pre-cert issuance and real cert issuance.
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Jeremy Rowley

unread,
Aug 29, 2019, 1:15:30 PM8/29/19
to Curt Spann, mozilla-dev-s...@lists.mozilla.org
Thanks for posting this Curt. We investigated and posted an incident report on Bugzilla. The root cause was related to pre-certs and an error in generating certificates for them. We're fixing the issue (should be done shortly). I figured it'd be good to document here why pre-certs fall under the requirement so there's no confusion for other CAs.

It can get confusing because the BRs section 7.1.2.7 a pre-cert is "not considered a certificate subject to the requirements of RFC 5280". The scope of the BRs is also questionable since it's still only applicable to "certificates intended to bused for authenticating servers" (BRs 1.1) . By virtue of the poison extension, precerts can never be applicable to authenticating servers. Initially, it's easy to think that pre-certs may not require OCSP or the same strict compliance

I reviewed the CT log policy and, unless I missed something, the policy there is silent on pre-certs and OCSP.

I think the requirement for pre-certs comes from two places. The requirements around revocation information originates from Mozilla policy 5.2 "CAs MUST NOT issue certificates that have:.... cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists." Then in Section 6 "For end-entity certificates, if the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service:"

What this means that a CA including a crl distribution point or OCSP service in the pre-cert must provide the OCPS/CRL service for the pre-cert, even if there's no possible way the pre-cert can be used by Mozilla on a server. The idea we had is simply drop the revocation information from the precert. Unfortunately, this doesn't work either because the pre-cert must be identical to the certificate plus the poison extension. This was probably obvious to anyone following CT over the years, but the discussion comes up every once in a while internally so I thought I'd document it externally so others can also chime in.

Feel free to substitute SCT for pre-cert if you want to use correct terminology.

Jeremy

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Curt Spann via dev-security-policy
Sent: Tuesday, August 27, 2019 2:05 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: DigiCert OCSP services returns 1 byte

Hello,

Ryan Sleevi

unread,
Aug 29, 2019, 1:38:12 PM8/29/19
to Jeremy Rowley, Curt Spann, mozilla-dev-s...@lists.mozilla.org
On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Thanks for posting this Curt. We investigated and posted an incident
> report on Bugzilla. The root cause was related to pre-certs and an error in
> generating certificates for them. We're fixing the issue (should be done
> shortly). I figured it'd be good to document here why pre-certs fall under
> the requirement so there's no confusion for other CAs.
>

Oh, Jeremy, you were going so well on the bug, but now you've activated my
trap card (since you love the memes :) )

It's been repeatedly documented every time a CA tries to make this
argument.

Would you suggest we remove that from the BRs? I'm wholly supportive of
this, since it's known I was not a fan of adding it to the BRs for
precisely this sort of creative interpretation. I believe you're now the
... fourth... CA that's tried to skate on this?

Multiple root programs have clarified: The existence of a pre-certificate
is seen as a binding committment, for purposes of policy, by that CA, that
it will or has issued an equivalent certificate.

1) Has DigiCert reviewed the existing incident reports from other CAs?
2) What process does DigiCert have to review all compliance issues,
regardless of the CA, so that it can examine its own systems for similar
issues or be aware of relevant discussions and/or ambiguities?

(And, yes, it's a trap)

Peter Bowen

unread,
Aug 29, 2019, 1:44:28 PM8/29/19
to Ryan Sleevi, Jeremy Rowley, Curt Spann, mozilla-dev-s...@lists.mozilla.org
On Thu, Aug 29, 2019 at 10:38 AM Ryan Sleevi via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
> > Thanks for posting this Curt. We investigated and posted an incident
> > report on Bugzilla. The root cause was related to pre-certs and an error
> in
> > generating certificates for them. We're fixing the issue (should be done
> > shortly). I figured it'd be good to document here why pre-certs fall
> under
> > the requirement so there's no confusion for other CAs.
> >
>
> Oh, Jeremy, you were going so well on the bug, but now you've activated my
> trap card (since you love the memes :) )
>
> It's been repeatedly documented every time a CA tries to make this
> argument.
>
> Would you suggest we remove that from the BRs? I'm wholly supportive of
> this, since it's known I was not a fan of adding it to the BRs for
> precisely this sort of creative interpretation. I believe you're now the
> ... fourth... CA that's tried to skate on this?
>
> Multiple root programs have clarified: The existence of a pre-certificate
> is seen as a binding committment, for purposes of policy, by that CA, that
> it will or has issued an equivalent certificate.


Is there a requirement that a CA return a valid OCSP response for a
pre-cert if they have not yet issued the equivalent certificate?

Is there a requirement that a CA return a valid OCSP response for a serial
number that has never been assigned? I know of several OCSP responders
that return a HTTP error in this case.

Thanks,
Peter

Jeremy Rowley

unread,
Aug 29, 2019, 1:50:21 PM8/29/19
to ry...@sleevi.com, Curt Spann, mozilla-dev-s...@lists.mozilla.org
Oh, I wasnt arguing that this isnt an issue. The opposite in fact. I was documenting why it is an issue ie, that a ca can't argue this isnt a compliance concern. It comes up a lot but I dont remember seeing it here.

From: Ryan Sleevi
Sent: Thursday, August 29, 11:38 AM
Subject: Re: DigiCert OCSP services returns 1 byte
To: Jeremy Rowley
Cc: Curt Spann, mozilla-dev-s...@lists.mozilla.org




On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>> wrote:
Thanks for posting this Curt. We investigated and posted an incident report on Bugzilla. The root cause was related to pre-certs and an error in generating certificates for them. We're fixing the issue (should be done shortly). I figured it'd be good to document here why pre-certs fall under the requirement so there's no confusion for other CAs.

Oh, Jeremy, you were going so well on the bug, but now you've activated my trap card (since you love the memes :) )

It's been repeatedly documented every time a CA tries to make this argument.

Would you suggest we remove that from the BRs? I'm wholly supportive of this, since it's known I was not a fan of adding it to the BRs for precisely this sort of creative interpretation. I believe you're now the ... fourth... CA that's tried to skate on this?

Multiple root programs have clarified: The existence of a pre-certificate is seen as a binding committment, for purposes of policy, by that CA, that it will or has issued an equivalent certificate.

Jeremy Rowley

unread,
Aug 29, 2019, 1:55:40 PM8/29/19
to Peter Bowen, Ryan Sleevi, Curt Spann, mozilla-dev-s...@lists.mozilla.org
Yes. That was the point of my post. There is a requirement fo return an ocsp repsonse for a pre cert where the cert hasn't issued because of the Mozilla policy. Hence our failure was a Mozilla policy violation even if no practical system can use the response because no actual cert (without a posion extension) exists.
________________________________
From: Peter Bowen <pzb...@gmail.com>
Sent: Thursday, August 29, 2019 11:44:11 AM
To: Ryan Sleevi <ry...@sleevi.com>
Cc: Jeremy Rowley <jeremy...@digicert.com>; Curt Spann <csp...@apple.com>; mozilla-dev-s...@lists.mozilla.org <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: DigiCert OCSP services returns 1 byte



On Thu, Aug 29, 2019 at 10:38 AM Ryan Sleevi via dev-security-policy <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>> wrote:
On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy <
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>> wrote:

> Thanks for posting this Curt. We investigated and posted an incident
> report on Bugzilla. The root cause was related to pre-certs and an error in
> generating certificates for them. We're fixing the issue (should be done
> shortly). I figured it'd be good to document here why pre-certs fall under
> the requirement so there's no confusion for other CAs.
>

Oh, Jeremy, you were going so well on the bug, but now you've activated my
trap card (since you love the memes :) )

It's been repeatedly documented every time a CA tries to make this
argument.

Would you suggest we remove that from the BRs? I'm wholly supportive of
this, since it's known I was not a fan of adding it to the BRs for
precisely this sort of creative interpretation. I believe you're now the
... fourth... CA that's tried to skate on this?

Multiple root programs have clarified: The existence of a pre-certificate
is seen as a binding committment, for purposes of policy, by that CA, that
it will or has issued an equivalent certificate.

Jeremy Rowley

unread,
Aug 29, 2019, 3:53:45 PM8/29/19
to Jeremy Rowley, Peter Bowen, Ryan Sleevi, Curt Spann, mozilla-dev-s...@lists.mozilla.org
Let me try that again since I didn't explain my original post very well. Totally worth it since I got a sweet Yu-gi-oh reference out of fit.

What happened at DigiCert is that the OCSP service failed to return a signed response for a certificate where a pre-certificate existed by a certificate had not issued for whatever reason. The question asked was what type of OCSP services are required for a pre-cert if there is no other certificate. The answer we came up with is it should respond "GOOD" based on the Mozilla policy, not Unknown or any other response. Note that this was a bug in the DigiCert system but it lead to a fun internal discussion. What I'm sharing is the outcome of the internal discussion - it's only tangentially related to the bug, not the cause or remediation of it.

Summary: Pre-certs require a standard OCSP response as if the pre-cert was a normal cert. In fact, it's a mistake to ever think of pre-certs as anything other than TLS certs, even if the poison extension exists.

The question comes up because the BRs don't cover pre-certs. However, as Ryan points out, the browsers sort-of cover this as does the Mozilla policy. The browser say this is a promise to issue the cert and mis-issuance of a pre-cert is the same as mis-issuance of a cert. Although this isn't mis-issuance in the traditional profile sense, the lack of OCSP services for the pre-cert is a violation of the Mozilla policy. I couldn't figure out if it's a violation of the Chrome policy since Chrome says it's a promise to issue a cert. If the cert hasn't issued, then I'm not sure where that puts the OCSP service for Chrome. Regardless, according to Mozilla's policy, the requirement is that regardless of how long the cert takes to issue, the CA must provide OCSP services for the pre-cert. The reason is Mozilla requires an OCSP for each end-entity certificate listing an AIA in the certificate. Pre-certs are end-entity certificates.

Jeremy

Wayne Thayer

unread,
Sep 11, 2019, 9:08:12 PM9/11/19
to mozilla-dev-s...@lists.mozilla.org
Mozilla has, to-date, not published policies related to Certificate
Transparency, but this is a case where a clarification would be helpful. I
propose adding the following language to our "Required Practices" wiki page
[1]:

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 state “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 [2]. Mozilla recognizes a precertificate as proof that a
> corresponding certificate has been issued.
>
> This means, for example, that the requirements for OCSP for end-entity
> certificates apply even when a CA has issued a precertificate without
> issuing a corresponding certificate.
>

I plan to add this to the wiki next week. I also plan to include this in in
a future update to our Root Store Policy.

I will greatly appreciate your constructive feedback on this proposal.

- Wayne

[1] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
[2] https://cabforum.org/pipermail/public/2014-January/002694.html

Jeremy Rowley

unread,
Sep 11, 2019, 9:19:16 PM9/11/19
to Wayne Thayer, mozilla-dev-s...@lists.mozilla.org
Hey Wayne - I take it that this "Mozilla recognizes a precertificate as proof that a corresponding certificate has been issued" means a CA issuing a precert without the final cert must respond "good" unless the pre-cert is revoked? Responding unknown means the CA wouldn't know that they issued the cert, which means they disagree with the proof that a corresponding cert has been issued.

Wayne Thayer

unread,
Sep 11, 2019, 9:22:53 PM9/11/19
to Jeremy Rowley, mozilla-dev-s...@lists.mozilla.org
Correct. That's what I intended to convey with the last sentence:

This means, for example, that the requirements for OCSP for end-entity
> certificates apply even when a CA has issued a precertificate without
> issuing a corresponding certificate.
>

Do you have any suggestions for how I can improve/clarify?

On Wed, Sep 11, 2019 at 6:19 PM Jeremy Rowley <jeremy...@digicert.com>
wrote:

Jeremy Rowley

unread,
Sep 11, 2019, 11:09:42 PM9/11/19
to Wayne Thayer, mozilla-dev-s...@lists.mozilla.org
I think that's perfectly clear but I wanted to double check in case "perfectly clear" was me misreading it. One thing that does come up a lot is whether a CA has to revoke a pre-certificate if the certificate doesn't actually issue. I think this has been adequately answered on the bug lists but would be good to codify.

For the language maybe:

This means, for example, that (i) a CA must provide OCSP services and responses in accordance with the Mozilla policy for all pre-certificates as if corresponding certificate exists and (ii) a CA must be able to revoke a pre-certificate if revocation of the certificate is required under the Mozilla policy and the corresponding certificate doesn't actually exist and therefore cannot be revoked.


________________________________
From: Wayne Thayer <wth...@mozilla.com>
Sent: Wednesday, September 11, 2019 7:22:29 PM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: mozilla-dev-s...@lists.mozilla.org <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: DigiCert OCSP services returns 1 byte

Correct. That's what I intended to convey with the last sentence:

This means, for example, that the requirements for OCSP for end-entity certificates apply even when a CA has issued a precertificate without issuing a corresponding certificate.


Do you have any suggestions for how I can improve/clarify?


On Wed, Sep 11, 2019 at 6:19 PM Jeremy Rowley <jeremy...@digicert.com<mailto:jeremy...@digicert.com>> wrote:
Hey Wayne - I take it that this "Mozilla recognizes a precertificate as proof that a corresponding certificate has been issued" means a CA issuing a precert without the final cert must respond "good" unless the pre-cert is revoked? Responding unknown means the CA wouldn't know that they issued the cert, which means they disagree with the proof that a corresponding cert has been issued.

Jeremy

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org<mailto:dev-security-...@lists.mozilla.org>> On Behalf Of Wayne Thayer via dev-security-policy
Sent: Wednesday, September 11, 2019 7:08 PM
To: mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org>
Subject: Re: DigiCert OCSP services returns 1 byte

Mozilla has, to-date, not published policies related to Certificate Transparency, but this is a case where a clarification would be helpful. I propose adding the following language to our "Required Practices" wiki page
[1]:

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 state "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 [2]. Mozilla recognizes a precertificate as
> proof that a corresponding certificate has been issued.
>
> This means, for example, that the requirements for OCSP for end-entity
> certificates apply even when a CA has issued a precertificate without
> issuing a corresponding certificate.
>

I plan to add this to the wiki next week. I also plan to include this in in a future update to our Root Store Policy.

I will greatly appreciate your constructive feedback on this proposal.

- Wayne

[1] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices
[2] https://cabforum.org/pipermail/public/2014-January/002694.html

> From: Peter Bowen <pzb...@gmail.com<mailto:pzb...@gmail.com>>
> Sent: Thursday, August 29, 2019 11:44:11 AM
> To: Ryan Sleevi <ry...@sleevi.com<mailto:ry...@sleevi.com>>
> Cc: Jeremy Rowley <jeremy...@digicert.com<mailto:jeremy...@digicert.com>>; Curt Spann <
> csp...@apple.com<mailto:csp...@apple.com>>; mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org> <
> mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org>>
> Subject: Re: DigiCert OCSP services returns 1 byte
>
>
>
> On Thu, Aug 29, 2019 at 10:38 AM Ryan Sleevi via dev-security-policy <
> dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org><mailto:
> dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>>> wrote:
> On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy
> <
> dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org><mailto:
> dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy
>
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

Alex Cohn

unread,
Sep 12, 2019, 11:25:47 AM9/12/19
to Jeremy Rowley, Wayne Thayer, mozilla-dev-s...@lists.mozilla.org
On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> This means, for example, that (i) a CA must provide OCSP services and
> responses in accordance with the Mozilla policy for all pre-certificates as
> if corresponding certificate exists and (ii) a CA must be able to revoke a
> pre-certificate if revocation of the certificate is required under the
> Mozilla policy and the corresponding certificate doesn't actually exist and
> therefore cannot be revoked.
>

Should a CA using a precertificate signing certificate be required to
provide OCSP services for their precertificates? Or is it on the relying
party to calculate the proper OCSP request for the final certificate and
send that instead? In other words, should we expect a CT-naïve OCSP checker
to work normally when presented, e.g., with https://crt.sh/?id=1868433277?

Alex

Jeremy Rowley

unread,
Sep 12, 2019, 1:46:43 PM9/12/19
to Alex Cohn, Wayne Thayer, mozilla-dev-s...@lists.mozilla.org
The language says you have to provide the response for the cert as if it exists, but the reality is that sending a response for the precert is the same as calculating the result for the certificate as if it exists and sending that. They are the same thing because the precert is treated the same as the final cert if the final cert doesn’t exist.

I believe the intent is that a CT-naïve OCSP checker would work normally when presented with a precert or a certificate. Afterall, a precert is really just a certificate with a special extension.

From: Alex Cohn <al...@alexcohn.com>
Sent: Thursday, September 12, 2019 9:25 AM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: Wayne Thayer <wth...@mozilla.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: DigiCert OCSP services returns 1 byte

Neil Dunbar

unread,
Sep 12, 2019, 1:58:24 PM9/12/19
to mozilla-dev-s...@lists.mozilla.org


> On 12 Sep 2019, at 18:46, Jeremy Rowley via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> The language says you have to provide the response for the cert as if it exists, but the reality is that sending a response for the precert is the same as calculating the result for the certificate as if it exists and sending that. They are the same thing because the precert is treated the same as the final cert if the final cert doesn’t exist.

I could be horribly mistaken, but I think Alex was asking is: in the event that precertificates are not signed by the issuing CA’s private key, but rather by a separate signing key/certificate dedicated to that purpose (per RFC 6962, Section 3.1) - is there then an obligation to provide OCSP services for that, given that the (name-hash, key-hash) on the OCSP request would not be the same as that which would normally obtain for the final certificate, which is signed directly by the issuing CA key?

It would _seem_ right that it should, since a pre-certificate could reasonably be revoked prior to issuing the final certificate, for several reasons. Yet it’s a reasonable follow-up question: would CAs who have such dedicated certificates make them available such that RPs could construct those OCSP requests?

> I believe the intent is that a CT-naïve OCSP checker would work normally when presented with a precert or a certificate. Afterall, a precert is really just a certificate with a special extension.

Would an OCSP server even be able to tell the difference? After all, it simply gets presented with a CA identifier (name-hash, key-hash) and a serial number. If it knows about that combination, it provides a response, but it’s got no way of knowing, absent extra information in its database whether the request pertains to a pre-cert or cert - in general. But see above for the case of dedicated precertificate signing certificates.

Regards,

Neil


Tim Hollebeek

unread,
Sep 12, 2019, 3:49:02 PM9/12/19
to Jeremy Rowley, Alex Cohn, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer
So, this is something that would be helpfully clarified via either an IETF draft, or clarifications in the BRs. There are various things in the OCSP RFCs and even the BRs that can be read as precluding good OCSP responses for pre-certificates, although the situation is unclear since the relevant sections are blissfully ignorant of CT, and the correct behavior here was unfortunately left out of RFC 6962, which should have clarified this.

Happy to help draft something. There are some interesting complexities once you dig deeper.

-Tim

> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org> On
> Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Thursday, September 12, 2019 1:46 PM
> To: Alex Cohn <al...@alexcohn.com>
> Cc: mozilla-dev-s...@lists.mozilla.org; Wayne Thayer
> <wth...@mozilla.com>
> Subject: RE: DigiCert OCSP services returns 1 byte
>
> The language says you have to provide the response for the cert as if it exists,
> but the reality is that sending a response for the precert is the same as
> calculating the result for the certificate as if it exists and sending that. They are
> the same thing because the precert is treated the same as the final cert if the
> final cert doesn’t exist.
>
> I believe the intent is that a CT-naïve OCSP checker would work normally when
> presented with a precert or a certificate. Afterall, a precert is really just a
> certificate with a special extension.
>
> From: Alex Cohn <al...@alexcohn.com>
> Sent: Thursday, September 12, 2019 9:25 AM
> To: Jeremy Rowley <jeremy...@digicert.com>
> Cc: Wayne Thayer <wth...@mozilla.com>; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: Re: DigiCert OCSP services returns 1 byte
>
> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy
> <dev-secur...@lists.mozilla.org<mailto:dev-security-
> pol...@lists.mozilla.org>> wrote:
> This means, for example, that (i) a CA must provide OCSP services and
> responses in accordance with the Mozilla policy for all pre-certificates as if
> corresponding certificate exists and (ii) a CA must be able to revoke a pre-
> certificate if revocation of the certificate is required under the Mozilla policy
> and the corresponding certificate doesn't actually exist and therefore cannot
> be revoked.
>
> Should a CA using a precertificate signing certificate be required to provide
> OCSP services for their precertificates? Or is it on the relying party to calculate
> the proper OCSP request for the final certificate and send that instead? In
> other words, should we expect a CT-naïve OCSP checker to work normally
> when presented, e.g., with https://crt.sh/?id=1868433277?
>
> Alex
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

Tim Shirley

unread,
Sep 12, 2019, 5:17:23 PM9/12/19
to Neil Dunbar, mozilla-dev-s...@lists.mozilla.org
Certainly we (as a CA who uses such precertificate-signing CAs) never interpreted RFC 6962 or the other requirements as mandating or even suggesting that, for either of the possible interpretations of Alex's question. As soon as you hit the precertificate-signing CA in the validation path you've encountered a signed entity that is unusable in the public PKI, as it fails validation on a couple of fronts: it has the critical poison extension in the EKU and it has Basic Constraints set and yet was issued from a CA with path-length 0. If we did need to provide OCSP responses for that hierarchy, that would mean generating and distributing twice as many OCSP responses, so if that became a requirement that would likely cause us to reconsider this implementation approach.

More generally speaking to the entirety of this thread though I'm wondering a couple of things:

1) Is there an actual goal or problem we're trying to solve by having a rule at all on whether an OCSP responder should respond UNKNOWN or GOOD on a precertificate where there is no certificate? I understand the rationale for requiring that a CA be able to revoke a precertificate, since there's no way for a CA to prove that a corresponding certificate doesn't exist. So if you can satisfy any of the criteria for which the BRs require revocation of a certificate today, an OCSP response of REVOKED on that serial number gives assurance that if any corresponding certificate DOES exist, it's now revoked. But what is the practical difference between an OCSP responder returning GOOD and it returning UNKNOWN unless a corresponding certificate exists?

2) How does the statement from RFC 6962 lead to the conclusion that a precertificate is "proof that a corresponding certificate has been issued". Of course for a certain period of time (typically very short) that statement can't possibly be true because you need to create a precertificate before you can request SCTs and you need SCTs to create the certificate. But ignoring that technicality, I read "This intent is considered binding (i.e., misissuance of the Precertificate is considered equal to misissuance of the final certificate)" as saying essentially "you'll be found guilty in a court of law if you commit a crime in your precertificate, whether or not you go through with it in a real certificate. You signaled your intent, and we'll find you guilty based on that intent, if your intent was unlawful." I could see where it might be ambiguous without the i.e. parenthetical between that interpretation and the interpretation that "binding intent" means a promise to issue a corresponding certificate. But the i.e. parenthetical seems to have been added specifically to clear up that potential ambiguity.

Regards,
Tim

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Neil Dunbar via dev-security-policy
Sent: Thursday, September 12, 2019 1:58 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: DigiCert OCSP services returns 1 byte



> On 12 Sep 2019, at 18:46, Jeremy Rowley via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> The language says you have to provide the response for the cert as if it exists, but the reality is that sending a response for the precert is the same as calculating the result for the certificate as if it exists and sending that. They are the same thing because the precert is treated the same as the final cert if the final cert doesn't exist.

I could be horribly mistaken, but I think Alex was asking is: in the event that precertificates are not signed by the issuing CA's private key, but rather by a separate signing key/certificate dedicated to that purpose (per RFC 6962, Section 3.1) - is there then an obligation to provide OCSP services for that, given that the (name-hash, key-hash) on the OCSP request would not be the same as that which would normally obtain for the final certificate, which is signed directly by the issuing CA key?

It would _seem_ right that it should, since a pre-certificate could reasonably be revoked prior to issuing the final certificate, for several reasons. Yet it's a reasonable follow-up question: would CAs who have such dedicated certificates make them available such that RPs could construct those OCSP requests?

> I believe the intent is that a CT-naïve OCSP checker would work normally when presented with a precert or a certificate. Afterall, a precert is really just a certificate with a special extension.

Would an OCSP server even be able to tell the difference? After all, it simply gets presented with a CA identifier (name-hash, key-hash) and a serial number. If it knows about that combination, it provides a response, but it's got no way of knowing, absent extra information in its database whether the request pertains to a pre-cert or cert - in general. But see above for the case of dedicated precertificate signing certificates.

Regards,

Neil


_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://scanmail.trustwave.com/?c=4062&d=vYf63SFHw3OMTLs5z_XBTWHEejkpuh1h5FY8k9MvsA&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy

Ryan Sleevi

unread,
Sep 12, 2019, 6:40:10 PM9/12/19
to Alex Cohn, Jeremy Rowley, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer
On Thu, Sep 12, 2019 at 11:25 AM Alex Cohn via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
> > This means, for example, that (i) a CA must provide OCSP services and
> > responses in accordance with the Mozilla policy for all pre-certificates
> as
> > if corresponding certificate exists and (ii) a CA must be able to revoke
> a
> > pre-certificate if revocation of the certificate is required under the
> > Mozilla policy and the corresponding certificate doesn't actually exist
> and
> > therefore cannot be revoked.
> >
>
> Should a CA using a precertificate signing certificate be required to
> provide OCSP services for their precertificates? Or is it on the relying
> party to calculate the proper OCSP request for the final certificate and
> send that instead? In other words, should we expect a CT-naïve OCSP checker
> to work normally when presented, e.g., with https://crt.sh/?id=1868433277?
>

I think this may be the wrong framing. The issue is not about ensuring "a
CT-naïve OCSP checker" can get responses for pre-certs. It's about ensuring
that, from the point of view of a user agent that views a pre-certificate
as evidence that an equivalent certificate exists, even if it's not known
(or even if it was not actually issued), can they verify that OCSP services
exist and are configured for that equivalent certificate?

In this scenario, because RFC 6962 establishes that, even when using a
Precertificate Signing Certificate, it will have been directly issued by
the CA Certificate that will ultimately issue the "final" certificate (...
or would be treated as if it had), then we have the (name-hash, key-hash)
that Neil was referring to, and we can easily verify using that, for the
serial number indicated in the pre-certificate, that the OCSP response can
be verified using the issuer of the Precertificate Signing Certificate.

Have I overlooked some ambiguity?

Ryan Sleevi

unread,
Sep 12, 2019, 6:44:40 PM9/12/19
to Tim Hollebeek, Jeremy Rowley, Alex Cohn, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer
Without wanting to be antagonistic, I've come to learn I can count on you
to suggest that X deserves clarification because it's ambiguous, but I've
also learned I have trouble learning where the ambiguity exists or why.
Recall that part of this confusion, regrettably, came from an earnest
attempt to try and helpfully clarify the BRs with respect to
precertificates, so I've come to view clarifications as just as much, if
not more, risky than the original language.

The question about whether and how a pre-certificate is viewed is
definitely a matter for policy, and so I'm definitely opposed to attempting
to address it in IETF drafts, and somewhat opposed to clarifying it in the
BRs, since really, it's a matter of policy.

Could you perhaps highlight which "various things in the OCSP RFCs" that
might be read to conflict or preclude a good response? I think that's
probably the best way to figure out what, where, is to understand how the
interpretation came to be. It could be simply that the interpretation
overlooked other sections, as we've seen in the past (e.g. with IP
addresses in dNSName or with underscores), and so that seems like the best
starting point.

On Thu, Sep 12, 2019 at 3:49 PM Tim Hollebeek via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> So, this is something that would be helpfully clarified via either an IETF
> draft, or clarifications in the BRs. There are various things in the OCSP
> RFCs and even the BRs that can be read as precluding good OCSP responses
> for pre-certificates, although the situation is unclear since the relevant
> sections are blissfully ignorant of CT, and the correct behavior here was
> unfortunately left out of RFC 6962, which should have clarified this.
>
> Happy to help draft something. There are some interesting complexities
> once you dig deeper.
>
> -Tim
>
> > -----Original Message-----
> > From: dev-security-policy <dev-security-...@lists.mozilla.org>
> On
> > Behalf Of Jeremy Rowley via dev-security-policy
> > Sent: Thursday, September 12, 2019 1:46 PM
> > To: Alex Cohn <al...@alexcohn.com>
> > Cc: mozilla-dev-s...@lists.mozilla.org; Wayne Thayer
> > <wth...@mozilla.com>
> > Subject: RE: DigiCert OCSP services returns 1 byte
> >
> > The language says you have to provide the response for the cert as if it
> exists,
> > but the reality is that sending a response for the precert is the same as
> > calculating the result for the certificate as if it exists and sending
> that. They are
> > the same thing because the precert is treated the same as the final cert
> if the
> > final cert doesn’t exist.
> >
> > I believe the intent is that a CT-naïve OCSP checker would work normally
> when
> > presented with a precert or a certificate. Afterall, a precert is really
> just a
> > certificate with a special extension.
> >
> > From: Alex Cohn <al...@alexcohn.com>
> > Sent: Thursday, September 12, 2019 9:25 AM
> > To: Jeremy Rowley <jeremy...@digicert.com>
> > Cc: Wayne Thayer <wth...@mozilla.com>; mozilla-dev-security-
> > pol...@lists.mozilla.org
> > Subject: Re: DigiCert OCSP services returns 1 byte
> >
> > On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy
> > <dev-secur...@lists.mozilla.org<mailto:dev-security-
> > pol...@lists.mozilla.org>> wrote:
> > This means, for example, that (i) a CA must provide OCSP services and
> > responses in accordance with the Mozilla policy for all pre-certificates
> as if
> > corresponding certificate exists and (ii) a CA must be able to revoke a
> pre-
> > certificate if revocation of the certificate is required under the
> Mozilla policy
> > and the corresponding certificate doesn't actually exist and therefore
> cannot
> > be revoked.
> >
> > Should a CA using a precertificate signing certificate be required to
> provide
> > OCSP services for their precertificates? Or is it on the relying party
> to calculate
> > the proper OCSP request for the final certificate and send that instead?
> In
> > other words, should we expect a CT-naïve OCSP checker to work normally
> > when presented, e.g., with https://crt.sh/?id=1868433277?
> >
> > Alex
> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

Alex Cohn

unread,
Sep 12, 2019, 7:15:53 PM9/12/19
to ry...@sleevi.com, Jeremy Rowley, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer
Neil's interpretation of my poorly-worded question was correct - thank you
and apologies for the confusion.

On Thu, Sep 12, 2019 at 5:39 PM Ryan Sleevi <ry...@sleevi.com> wrote:

>
> On Thu, Sep 12, 2019 at 11:25 AM Alex Cohn via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> Should a CA using a precertificate signing certificate be required to
>> provide OCSP services for their precertificates? Or is it on the relying
>> party to calculate the proper OCSP request for the final certificate and
>> send that instead? In other words, should we expect a CT-naïve OCSP
>> checker
>> to work normally when presented, e.g., with https://crt.sh/?id=1868433277
>> ?
>>
>
> I think this may be the wrong framing. The issue is not about ensuring "a
> CT-naïve OCSP checker" can get responses for pre-certs. It's about ensuring
> that, from the point of view of a user agent that views a pre-certificate
> as evidence that an equivalent certificate exists, even if it's not known
> (or even if it was not actually issued), can they verify that OCSP services
> exist and are configured for that equivalent certificate?
>

Fair point. The only relying parties likely to come across
precertificates in practice are CT log clients, and it's reasonable to
assume those will be prepared to handle edge cases like this. (How many
actually handle this correctly? crt.sh doesn't, as far as I can tell - OCSP
checks for the precert I posted earlier return "unauthorized", despite the
final certificate being good)


> In this scenario, because RFC 6962 establishes that, even when using a
> Precertificate Signing Certificate, it will have been directly issued by
> the CA Certificate that will ultimately issue the "final" certificate (...
> or would be treated as if it had), then we have the (name-hash, key-hash)
> that Neil was referring to, and we can easily verify using that, for the
> serial number indicated in the pre-certificate, that the OCSP response can
> be verified using the issuer of the Precertificate Signing Certificate.
>

That technique was what I was attempting to hint at with "on the relying
party to calculate the proper OCSP request for the final certificate".


> Have I overlooked some ambiguity?
>

Not that I can think of on further reflection. Just some
unanticipated-by-me edge cases :)

Alex

Tim Shirley

unread,
Sep 12, 2019, 8:21:37 PM9/12/19
to ry...@sleevi.com, Alex Cohn, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer, Jeremy Rowley
Why would a user agent view a pre-certificate as "evidence that an equivalent certificate exists"? It's evidence that it might exist.. That the CA had the intent to make it exist at the time they signed the precertificate.. But I can't find anything in RFC 6962 that suggests to me that if the CA doesn't follow through on that intent that their systems are required to behave as if it does exist.

And of course Mozilla could add a policy to require exactly that, as the proposed addition does. But I'm struggling to see the practical value in doing so.

Regards,
Tim

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, September 12, 2019 6:40 PM
To: Alex Cohn <al...@alexcohn.com>
Cc: mozilla-dev-s...@lists.mozilla.org; Wayne Thayer <wth...@mozilla.com>; Jeremy Rowley <jeremy...@digicert.com>
Subject: Re: DigiCert OCSP services returns 1 byte

On Thu, Sep 12, 2019 at 11:25 AM Alex Cohn via dev-security-policy < dev-secur...@lists.mozilla.org> wrote:

> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy
> < dev-secur...@lists.mozilla.org> wrote:
>
> > This means, for example, that (i) a CA must provide OCSP services
> > and responses in accordance with the Mozilla policy for all
> > pre-certificates
> as
> > if corresponding certificate exists and (ii) a CA must be able to
> > revoke
> a
> > pre-certificate if revocation of the certificate is required under
> > the Mozilla policy and the corresponding certificate doesn't
> > actually exist
> and
> > therefore cannot be revoked.
> >
>
> Should a CA using a precertificate signing certificate be required to
> provide OCSP services for their precertificates? Or is it on the
> relying party to calculate the proper OCSP request for the final
> certificate and send that instead? In other words, should we expect a
> CT-naïve OCSP checker to work normally when presented, e.g., with
> https://scanmail.trustwave.com/?c=4062&d=ysn63WDApoyhRKbM1KwsYGvdnm11Y
> YNCq-2zZRHKOQ&s=5&u=https%3a%2f%2fcrt%2esh%2f%3fid%3d1868433277%3f
>

I think this may be the wrong framing. The issue is not about ensuring "a CT-naïve OCSP checker" can get responses for pre-certs. It's about ensuring that, from the point of view of a user agent that views a pre-certificate as evidence that an equivalent certificate exists, even if it's not known (or even if it was not actually issued), can they verify that OCSP services exist and are configured for that equivalent certificate?

In this scenario, because RFC 6962 establishes that, even when using a Precertificate Signing Certificate, it will have been directly issued by the CA Certificate that will ultimately issue the "final" certificate (...
or would be treated as if it had), then we have the (name-hash, key-hash) that Neil was referring to, and we can easily verify using that, for the serial number indicated in the pre-certificate, that the OCSP response can be verified using the issuer of the Precertificate Signing Certificate.

Have I overlooked some ambiguity?
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://scanmail.trustwave.com/?c=4062&d=ysn63WDApoyhRKbM1KwsYGvdnm11YYNCq7_hMxDGZg&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy

Jeremy Rowley

unread,
Sep 12, 2019, 8:27:56 PM9/12/19
to Tim Shirley, ry...@sleevi.com, Alex Cohn, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer
But the pre-cert exists and the pre-cert is a cert. I should be able to tell the status of a pre-cert because it really is a certificate.
https://lists.mozilla.org/listinfo/dev-security-policy

Ryan Sleevi

unread,
Sep 12, 2019, 8:53:42 PM9/12/19
to Tim Shirley, ry...@sleevi.com, Alex Cohn, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer, Jeremy Rowley
There's a problem with this framing, and this was the earlier reference to
Jeremy about Yu-gi-oh!

>From that earlier response:
> Multiple root programs have clarified: The existence of a pre-certificate
is seen as a binding committment, for purposes of policy, by that CA, that
it will or has issued an equivalent certificate.

Or, to quote from RFC 6962:
> 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).

I suspect part of the issue is the incorrect view of seeing "misissuance"
as "Issuing a certificate that does not comply with the profile", where
we've seen (most obvious through the many CA incident reports), that
"misissuance" is "Issuing a certificate that does not comply with the
policy" - that is, including services like AIA, OCSP, and, well, all the
many validation requirements.

>From the point of view of browser policy, a pre-certificate is absolutely
evidence that an equivalent certificate exists. Anything less than that,
and a CA would (and CAs have) tried to argue that it's not really
misissuance, as long as they didn't actually issue the equivalent
certificate. The very point of pre-certificates is to indicate a binding
commitment, with cryptographic evidence, that they cannot dispute an
equivalent certificate "could" exist.

On Thu, Sep 12, 2019 at 8:21 PM Tim Shirley <TShi...@securetrust.com>
wrote:

Rob Stradling

unread,
Sep 13, 2019, 4:22:36 AM9/13/19
to Tim Hollebeek, Jeremy Rowley, Alex Cohn, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer
On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
> So, this is something that would be helpfully clarified via either an IETF draft,

There's already a 6962-bis draft [1] in IESG Last Call, which (when we
finally complete it!) will obsolete RFC6962. 6962-bis redefines
precertificates so that they're not actually X.509 certificates.
Therefore, I don't think a "clarify RFC6962" draft is necessary.

Thinking aloud...
Does anything need to be clarified in 6962-bis though?
A (non-X.509) 6962-bis precertificate contains the serial number that
will appear in the certificate (if or when that certificate is issued),
so: Should the CA be forbidden, permitted or required to operate
revocation services for that serial number once the 6962-bis
precertificate has been produced but before the certificate has been
issued? (And is this a technical matter for 6962-bis to address, or a
policy matter that's out of scope for the 6962-bis document?)


[1] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/

> or clarifications in the BRs. There are various things in the OCSP RFCs and even the BRs that can be read as precluding good OCSP responses for pre-certificates, although the situation is unclear since the relevant sections are blissfully ignorant of CT, and the correct behavior here was unfortunately left out of RFC 6962, which should have clarified this.
>
> Happy to help draft something. There are some interesting complexities once you dig deeper.
>
> -Tim
>
>> -----Original Message-----
>> From: dev-security-policy <dev-security-...@lists.mozilla.org> On
>> Behalf Of Jeremy Rowley via dev-security-policy
>> Sent: Thursday, September 12, 2019 1:46 PM
>> To: Alex Cohn <al...@alexcohn.com>
>> Cc: mozilla-dev-s...@lists.mozilla.org; Wayne Thayer
>> <wth...@mozilla.com>
>> Subject: RE: DigiCert OCSP services returns 1 byte
>>
>> The language says you have to provide the response for the cert as if it exists,
>> but the reality is that sending a response for the precert is the same as
>> calculating the result for the certificate as if it exists and sending that. They are
>> the same thing because the precert is treated the same as the final cert if the
>> final cert doesn’t exist.
>>
>> I believe the intent is that a CT-naïve OCSP checker would work normally when
>> presented with a precert or a certificate. Afterall, a precert is really just a
>> certificate with a special extension.
>>
>> From: Alex Cohn <al...@alexcohn.com>
>> Sent: Thursday, September 12, 2019 9:25 AM
>> To: Jeremy Rowley <jeremy...@digicert.com>
>> Cc: Wayne Thayer <wth...@mozilla.com>; mozilla-dev-security-
>> pol...@lists.mozilla.org
>> Subject: Re: DigiCert OCSP services returns 1 byte
>>
>> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy
>> <dev-secur...@lists.mozilla.org<mailto:dev-security-
>> pol...@lists.mozilla.org>> wrote:
>> This means, for example, that (i) a CA must provide OCSP services and
>> responses in accordance with the Mozilla policy for all pre-certificates as if
>> corresponding certificate exists and (ii) a CA must be able to revoke a pre-
>> certificate if revocation of the certificate is required under the Mozilla policy
>> and the corresponding certificate doesn't actually exist and therefore cannot
>> be revoked.
>>
>> Should a CA using a precertificate signing certificate be required to provide
>> OCSP services for their precertificates? Or is it on the relying party to calculate
>> the proper OCSP request for the final certificate and send that instead? In
>> other words, should we expect a CT-naïve OCSP checker to work normally
>> when presented, e.g., with https://crt.sh/?id=1868433277?
>>
>> Alex
>> _______________________________________________
>> dev-security-policy mailing list
>> dev-secur...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>> _______________________________________________
>> dev-security-policy mailing list
>> dev-secur...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy

--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally
privileged, confidential, or proprietary information. If you are not the
intended recipient, you are not permitted to use, copy, or forward it,
in whole or in part without the express consent of the sender. Please
notify the sender by reply email, disregard the foregoing messages, and
delete it immediately.

Tim Hollebeek

unread,
Sep 13, 2019, 2:24:25 PM9/13/19
to ry...@sleevi.com, Jeremy Rowley, Alex Cohn, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer
Tim Shirley did a good job of pointing it out. The relevant OCSP RFCs talk about issued certificates, which pre-certificates aren’t. This isn’t a policy matter, it’s a matter of a plain reading of the relevant RFCs, and trying to align that with what people want them to say as opposed to what they actually say.



Whatever the policy is, and I’m actually supportive of Wayne’s policy goals, the CT and OCSP RFCs actually have requirements that potentially contradict those goals, especially under some interpretations.



I’d like to fix the relevant requirements to allow to the policy that there seems to be a growing consensus for.



-Tim



From: Ryan Sleevi <ry...@sleevi.com>
Sent: Thursday, September 12, 2019 6:44 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: Jeremy Rowley <jeremy...@digicert.com>; Alex Cohn <al...@alexcohn.com>; mozilla-dev-s...@lists.mozilla.org; Wayne Thayer <wth...@mozilla.com>
Subject: Re: DigiCert OCSP services returns 1 byte



Without wanting to be antagonistic, I've come to learn I can count on you to suggest that X deserves clarification because it's ambiguous, but I've also learned I have trouble learning where the ambiguity exists or why. Recall that part of this confusion, regrettably, came from an earnest attempt to try and helpfully clarify the BRs with respect to precertificates, so I've come to view clarifications as just as much, if not more, risky than the original language.



The question about whether and how a pre-certificate is viewed is definitely a matter for policy, and so I'm definitely opposed to attempting to address it in IETF drafts, and somewhat opposed to clarifying it in the BRs, since really, it's a matter of policy.



Could you perhaps highlight which "various things in the OCSP RFCs" that might be read to conflict or preclude a good response? I think that's probably the best way to figure out what, where, is to understand how the interpretation came to be. It could be simply that the interpretation overlooked other sections, as we've seen in the past (e.g. with IP addresses in dNSName or with underscores), and so that seems like the best starting point.



On Thu, Sep 12, 2019 at 3:49 PM Tim Hollebeek via dev-security-policy <dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org> > wrote:

So, this is something that would be helpfully clarified via either an IETF draft, or clarifications in the BRs. There are various things in the OCSP RFCs and even the BRs that can be read as precluding good OCSP responses for pre-certificates, although the situation is unclear since the relevant sections are blissfully ignorant of CT, and the correct behavior here was unfortunately left out of RFC 6962, which should have clarified this.

Happy to help draft something. There are some interesting complexities once you dig deeper.

-Tim

> -----Original Message-----
> From: dev-security-policy <dev-security-...@lists.mozilla.org <mailto:dev-security-...@lists.mozilla.org> > On
> Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Thursday, September 12, 2019 1:46 PM
> To: Alex Cohn <al...@alexcohn.com <mailto:al...@alexcohn.com> >
> Cc: mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org> ; Wayne Thayer
> <wth...@mozilla.com <mailto:wth...@mozilla.com> >
> Subject: RE: DigiCert OCSP services returns 1 byte
>
> The language says you have to provide the response for the cert as if it exists,
> but the reality is that sending a response for the precert is the same as
> calculating the result for the certificate as if it exists and sending that. They are
> the same thing because the precert is treated the same as the final cert if the
> final cert doesn’t exist.
>
> I believe the intent is that a CT-naïve OCSP checker would work normally when
> presented with a precert or a certificate. Afterall, a precert is really just a
> certificate with a special extension.
>
> From: Alex Cohn <al...@alexcohn.com <mailto:al...@alexcohn.com> >
> Sent: Thursday, September 12, 2019 9:25 AM
> To: Jeremy Rowley <jeremy...@digicert.com <mailto:jeremy...@digicert.com> >
> Cc: Wayne Thayer <wth...@mozilla.com <mailto:wth...@mozilla.com> >; mozilla-dev-security-
> pol...@lists.mozilla.org <mailto:pol...@lists.mozilla.org>
> Subject: Re: DigiCert OCSP services returns 1 byte
>
> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy
> <dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org> <mailto:dev-security- <mailto:dev-security->
> pol...@lists.mozilla.org <mailto:pol...@lists.mozilla.org> >> wrote:
> This means, for example, that (i) a CA must provide OCSP services and
> responses in accordance with the Mozilla policy for all pre-certificates as if
> corresponding certificate exists and (ii) a CA must be able to revoke a pre-
> certificate if revocation of the certificate is required under the Mozilla policy
> and the corresponding certificate doesn't actually exist and therefore cannot
> be revoked.
>
> Should a CA using a precertificate signing certificate be required to provide
> OCSP services for their precertificates? Or is it on the relying party to calculate
> the proper OCSP request for the final certificate and send that instead? In
> other words, should we expect a CT-naïve OCSP checker to work normally
> when presented, e.g., with https://crt.sh/?id=1868433277?
>
> Alex
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

Tim Hollebeek

unread,
Sep 13, 2019, 2:25:11 PM9/13/19
to Rob Stradling, Jeremy Rowley, Alex Cohn, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer
Yes, but I think this clarifies things in the wrong direction.

-Tim

> -----Original Message-----
> From: Rob Stradling <r...@sectigo.com>
> Sent: Friday, September 13, 2019 4:22 AM
> To: Tim Hollebeek <tim.ho...@digicert.com>; Jeremy Rowley
> <jeremy...@digicert.com>; Alex Cohn <al...@alexcohn.com>
> Cc: mozilla-dev-s...@lists.mozilla.org; Wayne Thayer
> <wth...@mozilla.com>
> Subject: Re: DigiCert OCSP services returns 1 byte
>
> On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote:
> > So, this is something that would be helpfully clarified via either an
> > IETF draft,
>
> There's already a 6962-bis draft [1] in IESG Last Call, which (when we finally
> complete it!) will obsolete RFC6962. 6962-bis redefines precertificates so that
> they're not actually X.509 certificates.
> Therefore, I don't think a "clarify RFC6962" draft is necessary.
>
> Thinking aloud...
> Does anything need to be clarified in 6962-bis though?
> A (non-X.509) 6962-bis precertificate contains the serial number that will
> appear in the certificate (if or when that certificate is issued),
> so: Should the CA be forbidden, permitted or required to operate revocation
> services for that serial number once the 6962-bis precertificate has been
> produced but before the certificate has been issued? (And is this a technical
> matter for 6962-bis to address, or a policy matter that's out of scope for the
> 6962-bis document?)
>
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/
>
> >> Cc: Wayne Thayer <wth...@mozilla.com>; mozilla-dev-security-
> >> pol...@lists.mozilla.org
> >> Subject: Re: DigiCert OCSP services returns 1 byte
> >>
> >> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via
> >> dev-security-policy
> >> <dev-secur...@lists.mozilla.org<mailto:dev-security-
> >> pol...@lists.mozilla.org>> wrote:
> >> This means, for example, that (i) a CA must provide OCSP services and
> >> responses in accordance with the Mozilla policy for all
> >> pre-certificates as if corresponding certificate exists and (ii) a CA
> >> must be able to revoke a pre- certificate if revocation of the
> >> certificate is required under the Mozilla policy and the
> >> corresponding certificate doesn't actually exist and therefore cannot be
> revoked.
> >>
> >> Should a CA using a precertificate signing certificate be required to
> >> provide OCSP services for their precertificates? Or is it on the
> >> relying party to calculate the proper OCSP request for the final
> >> certificate and send that instead? In other words, should we expect a
> >> CT-naïve OCSP checker to work normally when presented, e.g., with
> https://crt.sh/?id=1868433277?
> >>
> >> Alex
> >> _______________________________________________
> >> dev-security-policy mailing list
> >> dev-secur...@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-security-policy
> >>
> >> _______________________________________________
> >> dev-security-policy mailing list
> >> dev-secur...@lists.mozilla.org

Wayne Thayer

unread,
Sep 13, 2019, 5:19:42 PM9/13/19
to Tim Hollebeek, Rob Stradling, Jeremy Rowley, Alex Cohn, mozilla-dev-s...@lists.mozilla.org
Thanks everyone for your feedback! I'm sensing that the proposed language
is generally helpful. I've made two updates:

* Accepted Jeremy's proposed language for the examples in the last
paragraph.
* attempted to address Tim Shirley's point that a precertificate is not
literally "proof" that a certificate exists by changing that sentence to
"Otherwise, Mozilla infers from the existence of a precertificate that a
corresponding certificate has been issued, even when we have no evidence of
the certificate."

The new statement of "required practice" reads:

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 state “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. Otherwise, Mozilla infers from the existence of a
> Precertificate that a corresponding certificate has been issued, even when
> we have no evidence of the certificate.
>
> This means, for example, that (i) a CA must provide OCSP services and
> responses in accordance with Mozilla policy for all Precertificates as if
> the corresponding certificate exists, and (ii) a CA must be able to revoke
> a Precertificate if revocation of the certificate is required under Mozilla
> policy and the corresponding certificate doesn’t actually exist and
> therefore cannot be revoked.
>

I will again welcome everyone's constructive feedback on this proposal, and
when there are no further comments I'll add this to our wiki.

- Wayne

On Fri, Sep 13, 2019 at 11:24 AM Tim Hollebeek <tim.ho...@digicert.com>
wrote:

Andrew Ayer

unread,
Sep 13, 2019, 7:27:20 PM9/13/19
to Wayne Thayer, mozilla-dev-s...@lists.mozilla.org
Hi Wayne,

> > This means, for example, that (i) a CA must provide OCSP services and
> > responses in accordance with Mozilla policy for all Precertificates as if
> > the corresponding certificate exists, and (ii) a CA must be able to revoke
> > a Precertificate if revocation of the certificate is required under Mozilla
> > policy and the corresponding certificate doesn’t actually exist and
> > therefore cannot be revoked.
> >
>
> I will again welcome everyone's constructive feedback on this proposal, and
> when there are no further comments I'll add this to our wiki.

I'm concerned that the last paragraph could be interpreted as requiring
CAs to operate OCSP services for the literal precertificates issued by
dedicated precert signing CAs, rather than the corresponding
certificates. This is not intended or useful, and as Tim Shirley
notes it would double the OCSP signing load for any CA using precert
signing CAs.

I think it's better to frame the language not as operating OCSP
services for precertificates themselves, but for certificates presumed
to exist based on the presence of a precertifiate (even if the
certificate doesn't actually exist).

Here's some suggested wording for the last paragraph:

> This means, for example, that (i) 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, and (ii) 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.

Regards,
Andrew

Rob Stradling

unread,
Sep 16, 2019, 5:28:36 AM9/16/19
to Tim Hollebeek, Jeremy Rowley, Alex Cohn, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer
On 13/09/2019 19:24, Tim Hollebeek wrote:
> Yes, but I think this clarifies things in the wrong direction.

Hi Tim. I'm not clear what you mean.

I was talking specifically and only about what IETF could/should do
regarding this matter. Which part did you disagree with, and why?
>>>> This means, for example, that (i) a CA must provide OCSP services and
>>>> responses in accordance with the Mozilla policy for all
>>>> pre-certificates as if corresponding certificate exists and (ii) a CA
>>>> must be able to revoke a pre- certificate if revocation of the
>>>> certificate is required under the Mozilla policy and the
>>>> corresponding certificate doesn't actually exist and therefore cannot be
>> revoked.
>>>>

Rob Stradling

unread,
Sep 16, 2019, 8:02:36 AM9/16/19
to Andrew Ayer, Wayne Thayer, mozilla-dev-s...@lists.mozilla.org
On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote:
<snip>
> Here's some suggested wording for the last paragraph:
>
>> This means, for example, that (i) 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, and (ii) 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.

[Speaking only for myself]

Wayne, Andrew,

Please treat this message as a sincere attempt both to understand what
the current requirements actually are and to seek to clarify what the
requirements should be.

ISTM that this "certificate presumed to exist" concept doesn't play
nicely with the current wording of BR 4.9.10:
'If the OCSP responder receives a request for status of a certificate
that has not been issued, then the responder SHOULD NOT respond with
a "good" status.'

If a certificate (with embedded SCTs and no CT poison extension) is
"presumed to exist" but the CA has not actually issued it, then to my
mind that's a "certificate that has not been issued"; and therefore, the
OCSP 'responder SHOULD NOT respond with a "good" status'.

However, this is Schrödinger's "certificate that has not been issued",
because a Precertificate has been issued that has the same serial number
(as the "certificate presumed to exist" that doesn't actually exist).

And so at this point ISTM that the OCSP responder is expected to
implement two conflicting requirements for the serial number in question:
(1) MUST respond "good", because an unrevoked/unexpired
precertificate exists (and because BR 4.9.9 mandates a signed OCSP
response).
(2) SHOULD NOT respond "good" (see BR 4.9.10).

Clearly that's impossible, which leads to the question: Which of these
two conflicting requirements should a CA ignore in order to be as
un-non-compliant as possible? Which leads me to BR 7.1.2.5:
'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'

Since the first mention of "certificates" in the OCSP Protocol Overview
(RFC6960 section 2) cross-references RFC5280, I believe that this 'shall
not be considered to be a "certificate"' declaration can be assumed to
extend to the OCSP requirements too. And therefore, the balance tilts
in favour of implementing 'SHOULD NOT respond "good"' and ignoring 'MUST
respond "good"'.

I can't say I like this conclusion, but nonetheless it is the conclusion
that my reading of the BRs forces me to reach. I realize that what the
BRs actually say may not reflect precisely what was intended by
CABForum; nonetheless, CAs are measured by what the BRs actually say.

IDEAS FOR FIXING IT:

Long-term:
- In CT v2 (6962-bis), precertificates are not X.509 certificates,
which removes Schrödinger from the equation. :-)

Short-term:
- I think BR 7.1.2.5, as written, is decidedly unhelpful and should
be revised to have a much smaller scope. Surely only the serial number
uniqueness requirement (RFC5280 section 4.1.2.2) needs to be relaxed,
not the entirety of RFC5280?
- 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.'

P.S. Full disclosure: Sectigo currently provides an (unsigned)
"unauthorized" OCSP response when a precert exists but the corresponding
cert doesn't, but in all honesty I'm not currently persuaded that an
Incident Report is warranted.

Andrew Ayer

unread,
Sep 16, 2019, 1:11:15 PM9/16/19
to Rob Stradling, dev-secur...@lists.mozilla.org
On Fri, 13 Sep 2019 08:22:21 +0000
Rob Stradling via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> Thinking aloud...
> Does anything need to be clarified in 6962-bis though?

Yes, it's long past time that we clarified what this means:

"This signature indicates the CA's intent to issue the certificate. This
intent is considered binding (i.e., misissuance of the precertificate is
considered equivalent to misissuance of the corresponding certificate)."

The goal is that a precertificate signature creates an unrebuttable
presumption that the CA has issued the corresponding certificate. If a
CA issues a precertificate, outside observers will treat the CA as if
it had issued the corresponding certificate - whether or not the CA
really did - so the CA should behave accordingly.

It's worth explicitly mentioning the implications of this:

* The CA needs to operate revocation services for the corresponding
certificate as if the certificate had been issued.

* If the corresponding certificate would be misissued, the CA will be
treated as if it had really issued that certificate.

Are there any other implications that 6962-bis should call out
explicitly?

Regards,
Andrew

Jakob Bohm

unread,
Sep 16, 2019, 3:25:24 PM9/16/19
to mozilla-dev-s...@lists.mozilla.org
How about the following (Mozilla) policy rules:

If a CA submits a preCertificate to CT, then it MUST ensure that one of
the following is true no more than 96 hours after submitting the
preCertificate and no more than 24 hours after signing the corresponding
actual certificate:

- The corresponding actual certificate has been signed and submitted to
CT (regardless if said submission was accepted), and all CA provided
revocation mechanisms and servers report that the actual certificate
is valid and not revoked.

- The corresponding actual certificate has been signed, SHOULD have
been submitted to CT (regardless if said submission was accepted) and
was later revoked. All CA provided revocation mechanisms and servers
MUST report that the actual certificate exists and SHOULD report that
it has been revoked at a time no earlier than 1 second before the
notBefore time in the preCertificate (other policy requirements or BRs
state that they MUST so report before a different deadline).

- The corresponding actual certificate has not been signed and MUST not
be subsequently signed. All CA provided revocation mechanisms and
servers must report that the certificate serial number was revoked at
least 60 seconds before the time specified as "notBefore" in the
preCertificate.

Rationale:
- Requirements explicitly refer to revocation of the corresponding
actual certificate, not the (perhaps differently signed)
preCertificate.

- 96 hours is the existing BR deadline for updating revocation servers.

- 24 hours is reasonable time for rolling out the "certificate good"
status throughout a CA infrastructure, before taking actions such
as submitting the actual certificate to CT. In practice, a CA will
need to do this faster if it wants to provide the actual certificate
to subscribers faster than this.

- If a CA wishes to make an actually/possibly signed certificate never
valid, it can report it as revoked 1 or 0 seconds before the notBefore
time. This is appropriate where a problem report indicates that the
certificate should never have been issued, or if signing the actual
certificate was initiated but the result was not successfully stored.

- Revocation times of 2 to 59 seconds before notBefore are reserved for
use in future policies.

- A CA system can be compliant while having only transaction-level
reliability.

- This caters to fast online CAs that complete the entire process in a
few minutes or seconds.

- This also caters to CAs that keep the private CA key offline and
require human confirmation of signing actions. Such a CA may perform
human confirmation of PreCertificate signing on a Friday, only accept
problem report revocations during the weekend, then manually confirm
signing of actual certificate, CRL and canned OCSP responses on
Monday. Root CAs with signing ceremonies would be a typical case.
Dedicated high security issuing SubCAs would be another case.

- This also caters to the scenario where a usually fast online CA
experiences a technical glitch that prevents completion of issuance,
followed by a few days to detect the situation and revoke the non-
issued certificates.

- It also caters to the scenario of a CT log failing to issue the
expected CT proofs, and the CA timing out the wait for that CT log
after 24 to 72 hours.

- It also caters to the scenario where a CT log fails to accept
submission of the signed actual certificate.

- Issuing a CT logged certificate but keeping it locked up in the CA
building explicitly becomes a policy violation after just a few days,
because it is then explicitly required to be published in CT and/or
revoked.


Practicalities:
- CA systems (in-house of standard) will need to implement error
handling logic to handle the various scenarios that can trigger
the "revoke without issuing" case and the "issued-but-retroactively-
revoked" case. Implementations need to be robustly tested in
simulated environments with simulated failures and timeouts, thus
final testing would probably take weeks or months just triggering
the real timeouts, then requesting a bug fix.

- If a CA revokes a PreCertificate serial with a revocation time
indicating the never-issued case, it is a policy violation incident
for that CA to have actually signed the certificate, even if the
certificate never left the building.

- If a CA revokes a serial with a revocation time indicating the
issued-then-revoked case, it can be expected to have the actual
certificate available in all but a few cases, and to submit that
actual certificate to CT in all but a few of the remaining cases.

- If a CA signs a certificate, but then immediately looses it (perhaps
a disk or server failed when trying to save it), it would be one of
the issued-then-revoked cases that cannot submit the signed actual
certificate to CT.

- In practice the never-signed revocation case can use a larger
time delta (such as 2 hours) while remaining compliant.

- CT log watching systems can distinguish the two revocation cases,
and report them differently.

- The required transactional integrity may or may not use a database
engine as an implementation technique. The important thing is to
securely store the fact (and data) of passing certain crucial moments
in the issuance process such that they are not lost if a consumable
component (such as a COTS disk system or COTS server) fails.

- A system failure during actual certificate signing needs to be
detected and handled within the 24 hour deadline. But such failures
are typically detected within the hour, thus during any business hours
signing ceremony. Also quickly enough for other servers in a fast CA
cluster to automatically do the needed revocations or alert a 24/7
operator team.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

Ryan Sleevi

unread,
Sep 16, 2019, 4:12:03 PM9/16/19
to mozilla-dev-security-policy
On Mon, Sep 16, 2019 at 3:25 PM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 16/09/2019 19:08, Andrew Ayer wrote:
> How about the following (Mozilla) policy rules:
>
> If a CA submits a preCertificate to CT, then it MUST ensure that one of
> the following is true no more than 96 hours after submitting the
> preCertificate and no more than 24 hours after signing the corresponding
> actual certificate:
>

This seems like a significantly worse change than Andrew's proposal,
because we can, do, and should expect better of CAs. A requirement like
this, captured in policy, actively discourages improvements to the status
quo, by explicitly encouraging delays.

It also seems to tie in a number of much broader, more impacting changes
that aren't immediately correlated, and thus would further delay productive
changes and clarifications. For example, magic values are very undesirable,
so we should try to avoid those.

I'm much more supportive of Andrew's change, as originally written. There
are other natural implications that may be worth expanding on, based on
some CAs' failures to think through them:

* 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 6962(-bis), it will be considered misissued.
- This covers duplicate serial numbers, which may result if a CA fails to
mark the serial 'used' or 'issued' in their database
- This logically implies that improperly (DER) encoding the SCT extension
within the final certificate is a BR compliance issue, while /not/ taking a
position on whether those SCTs conform to policy (e.g. number of logs or
diversity of logs), if/when Mozilla should adopt such a policy
- This also covers situations where CAs reordered the extensions between
the issuance of a precertificate and the final certificate, as we saw some
CAs do, by suggesting it's a misissuance to do so; implicitly, it's stating
these are "different final certificates" - two certs with the same serial
with different extensions

* 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
- We've seen multiple CAs "forget" to scan because they signed a precert,
but didn't mark a cert as 'active' or 'didn't issue the final certificate',
despite there still being misissuance.
- However, CAs are also permitted to omit logging of certificates (e.g.
the policy does not /require/ logging of precerts /or/ certs, and both
Apple and Google permit local Enterprises to disable this), so it's not
sufficient to scan only precerts or final certs, but the union of both, to
ensure no omissions

Based on CA's failures, those two logical consequences stand out from
Andrew's proposal, which captures much of the spirit and intent.

Wayne Thayer

unread,
Sep 16, 2019, 6:59:14 PM9/16/19
to Rob Stradling, Andrew Ayer, mozilla-dev-s...@lists.mozilla.org
On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling <r...@sectigo.com> wrote:

> On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote:
> <snip>
>
> If a certificate (with embedded SCTs and no CT poison extension) is
> "presumed to exist" but the CA has not actually issued it, then to my
> mind that's a "certificate that has not been issued"; and therefore, the
> OCSP 'responder SHOULD NOT respond with a "good" status'.
>
> However, this is Schrödinger's "certificate that has not been issued",
> because a Precertificate has been issued that has the same serial number
> (as the "certificate presumed to exist" that doesn't actually exist).
>
> And so at this point ISTM that the OCSP responder is expected to
> implement two conflicting requirements for the serial number in question:
> (1) MUST respond "good", because an unrevoked/unexpired
> precertificate exists (and because BR 4.9.9 mandates a signed OCSP
> response).
> (2) SHOULD NOT respond "good" (see BR 4.9.10).
>
>
If I'm reading BR 4.9.10 correctly, the situation is worse because it goes
on to state "Effective 1 August 2013, OCSP responders for CAs which are not
Technically Constrained in line with Section 7.1.5 MUST NOT respond with a
"good" status for such certificates." (referring to 'certificates that have
not been issued' from the prior paragraph)

If the desired outcome is for CAs to respond "good" to a precertificate
without a corresponding certificate, we could override the BRs in Mozilla
policy, but I'd want to get the BRs updated quickly as Rob suggested to
avoid audit findings.

The other piece of this policy that's still unclear to me relates to the
"unknown" OCSP status. Specifically, Is it currently forbidden for a CA to
provide an "unknown" OCSP response for an issued certificate? If not,
should it be? The implication here would be that CAs responding "unknown"
to precertificates without corresponding certificates are doing the right
thing, despite prior precedent indicating that this is a violation. [1]

- Wayne

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390

Jakob Bohm

unread,
Sep 17, 2019, 2:12:43 AM9/17/19
to mozilla-dev-s...@lists.mozilla.org
In any networked system, delays are inevitable.

If data (in this case replication status data) is to be reliably
replicated, there will be a further delay to ensure that bad data is
not forced onto all mirrors too quickly (Consider earlier incident(s)
where corrupted revocation data was rolled out to all the servers used
by a CA. Also consider the delay in the recent rollout of incident-
initiated revocations by GTS).

Thus it is technically inevitable that some revocation servers will
respond "unknown" for a freshly issued (as in signed) certificate.

So the real question is which of the various steps in a CT-logged
issuance are allowed to happen while the certificate status is
replicated to all the OCSP and CRL servers operated by a CA.

It is of cause possible to pretend that a signed but not yet submitted
certificate and/or preCertificate doesn't exist, creating a strict
serialization of steps:

1. Allocate serial number and other content.
2. Replicate this allocation to survive crashes.
3. Sign the preCertificate, canned "good" OCSP responses and a fresh
CRL (if the CRL contains extensions describing the valid serial
numbers).
4. Replicate the preCertificate and OCSP responses to survive crashes.
(Failure during this step results in having to sign the same
preCertificate again, usually getting the same signature).
5. Wait for all those OCSP responses and CRLs to reach all mirrors.
6. Record the completion of this rollout in the replicated dataset.
7. Submit the preCertificate to CT logs (which unnecessarily check
that the mirrors report "good" instead of "unknown" according to
the strict policy);
8. Wait for all the CT logs to return SCTs.
9. Replicate the SCTs to survive crashes.
(failure during this step will require extracting SCTs from the
CT logs or revoking the preCertificate and starting over).
10. Sign the actual certificate and any further canned OCSP responses
and CRLs that refer to the contents or signature of the actual
certificate.
11. Replicate the actual certificate and any new revocation data to
survive crashes.
(Failure during this step results in having to sign the same
preCertificate again, usually getting the same signature,
alternatively revoke and start over).
12. Wait for any such OCSP responses and CRLs to reach all mirrors.
13. Record the completion of this rollout in the replicated dataset.
(Failure during this step results in having to check the rollout
status again).
14. Submit the actual certificate to CT logs and await acknowledgement.
15. Finally send the actual certificate to the subscriber.

My alternative 4 paragraph proposal (rest was rationale) was to accept
the existence of delays, aim for eventual consistency, maximize overlap
between the operations by allowing the initial CT submission to happen
before all revocation servers respond "good" and the delivery to
subscriber to also happen during the wait for rollout.

As for my alleged use of magic numbers, this was the result of a logical
deduction: When revoking a misissued certificate that may have produced
stored signatures (TLS isn't everything), the revocation data should
state that the certificate was never valid and any such stored
signatures are thus invalid. Within the limitations of existing OCSP
and CRL formats, this is most effectively done by backdating the
revocation time in responses/CRLs to before the certificate would
otherwise have become valid. Cryptographically stating that due to any
number of failure scenarios (see the incidents in this thread) the
actual certificate was never issued, could be similarly stated by
stating an even earlier revocation of the hypothetical certificate.
Trying to think forward, I proposed leaving a reserved margin between
the two revocation timestamp ranges. A more clumsy alternative would
be to insert a special extension in the revocation data, with a
resulting OID allocation etc.

Kurt Roeckx

unread,
Sep 17, 2019, 3:01:56 AM9/17/19
to mozilla-dev-s...@lists.mozilla.org
On 2019-09-16 14:02, Rob Stradling wrote:
>
> ISTM that this "certificate presumed to exist" concept doesn't play
> nicely with the current wording of BR 4.9.10:
> 'If the OCSP responder receives a request for status of a certificate
> that has not been issued, then the responder SHOULD NOT respond with
> a "good" status.'
>
> If a certificate (with embedded SCTs and no CT poison extension) is
> "presumed to exist" but the CA has not actually issued it, then to my
> mind that's a "certificate that has not been issued"; and therefore, the
> OCSP 'responder SHOULD NOT respond with a "good" status'.

The problem of course is that you don't query OCSP about a certificate,
you query it about a serial number. And that serial number has been
issued. So maybe the BRs should say serial number instead of certificate?


Kurt

Ryan Sleevi

unread,
Sep 17, 2019, 9:26:42 AM9/17/19
to Wayne Thayer, Rob Stradling, mozilla-dev-s...@lists.mozilla.org, Andrew Ayer
On Mon, Sep 16, 2019 at 6:59 PM Wayne Thayer via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling <r...@sectigo.com> wrote:
>
> > On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote:
> > <snip>
> >
> > If a certificate (with embedded SCTs and no CT poison extension) is
> > "presumed to exist" but the CA has not actually issued it, then to my
> > mind that's a "certificate that has not been issued"; and therefore, the
> > OCSP 'responder SHOULD NOT respond with a "good" status'.
> >
> > However, this is Schrödinger's "certificate that has not been issued",
> > because a Precertificate has been issued that has the same serial number
> > (as the "certificate presumed to exist" that doesn't actually exist).
> >
> > And so at this point ISTM that the OCSP responder is expected to
> > implement two conflicting requirements for the serial number in question:
> > (1) MUST respond "good", because an unrevoked/unexpired
> > precertificate exists (and because BR 4.9.9 mandates a signed OCSP
> > response).
> > (2) SHOULD NOT respond "good" (see BR 4.9.10).
> >
> >
> If I'm reading BR 4.9.10 correctly, the situation is worse because it goes
> on to state "Effective 1 August 2013, OCSP responders for CAs which are not
> Technically Constrained in line with Section 7.1.5 MUST NOT respond with a
> "good" status for such certificates." (referring to 'certificates that have
> not been issued' from the prior paragraph)
>
> If the desired outcome is for CAs to respond "good" to a precertificate
> without a corresponding certificate, we could override the BRs in Mozilla
> policy, but I'd want to get the BRs updated quickly as Rob suggested to
> avoid audit findings.
>

We've had CAs argue, for better or worse, that they've "revoked" a
certificate by setting a revoked flag within their database, which then
will eventually result in the production of CRLs and signed OCSP responses
to reflect that status, and then distribute those responses to their CDNs
for the distribution points. In this model, the CA is arguing "revoked" is
on the basis of a change within their database, rather than the artifacts
produced from such a change. Some have even had online services (via HTML
forms) where you could check specific serial numbers, with CAPTCHAs, to
compare the database vs the produced/signed artifacts.

Similarly, we've had CAs argue that they've had certificates that were
issued, but were not active, based on a status change in their database,
where 'active' meant that they signed the certificate. This again suggests
a flow where "issued" is the status of committing to the database, rather
than producing the signed artifact.

For better or worse, if we accept that definition, which admittedly opens a
new set of issues to work through, the act of assigning the serial number
and TBSCertificate is the act of issuance, rather than the production of
the signed artifact. For better or worse, the BRs support as much with the
discussion of revocation, because the CAs that argued this highlighted that
the act of distributing OCSP/CRL responses is "publishing" the revocation
(hence the language in 4.9.5 regarding timeframes, and the language in
4.9.7 about publishing CRLs).

Recall that these issues highlighted here were not new or unexpected. If
you dig through the discussion of Ballot 134, you'll find Brian Smith
rightfully flagged these issues, which were the result of somewhat rushed
attempts to get language in the BRs. Much like Qualified Auditors within
Policy, it may be worth treating this as an exception and being deliberate
in how any matters of note or qualifications are treated, while better
language is proposed?

You can find the past discussion at
https://cabforum.org/pipermail/public/2014-September/003930.html . Brian
Smith, formerly of Mozilla, highlighted issues with the attempts to carve
out just duplicate serials, perhaps best in
https://cabforum.org/pipermail/public/2014-September/004006.html

If you look at that past discussion, you can also see debates about the
ASN.1 / SignedData approach being used, and how Precerts-are-not-Certs in
the same way that OCSPResponses-are-not-certs, even if all three used the
SignedData construct, is another interpretation, at which point, this issue
also washes out. You can also find discussions of alternative approaches,
which specified the exact encoding conditions in which a duplicate serial
would be permitted (treating precerts-as-actually-certs, rather than
precerts-as-committments-of-equivalent-certs)


> The other piece of this policy that's still unclear to me relates to the
> "unknown" OCSP status. Specifically, Is it currently forbidden for a CA to
> provide an "unknown" OCSP response for an issued certificate? If not,
> should it be? The implication here would be that CAs responding "unknown"
> to precertificates without corresponding certificates are doing the right
> thing, despite prior precedent indicating that this is a violation. [1]
>

RFC 2560, Section 2.2, says "The "unknown" state indicates that the
responder doesn't know about the certificate being requested."
RFC 6960, Section 2.2, says "The "unknown" state indicates that the
responder doesn't know about the certificate being requested, usually
because the request indicates an unrecognized issuer that is not served by
this responder." with a rather lengthy NOTE.

This is captured in the algorithm for RFC 5280. The Algorithm in Section
6.3.3, which OCSP is meant to slot into, recognizes a status of
"UNDETERMINED", which is what UNKNOWN would map to. When encountering an
UNDETERMINED response, the idea is to continue processing other sources of
revocation - i.e., the provided revocation source does not actually provide
revocation data for that certificate. This is more relevant with CRLs and
the ability to segment them on reason codes, but was still carried over for
responders, as well as to support local responders which might be used in
preference to the configured/declared responders.

You're right to phrase the question separate from the discussion of
precertificates. If an issued certificate had only a single OCSP responder
configured in the certificates authorityInfoAccess, and that responder
returned UNKNOWN, then has the CA met the obligations of 7.1.2.3 (c) -
namely, to provide the issuer's responder? Based on reading 2560 and 6960,
the Unknown status is meant to indicate it is not the issuer's responder -
so returning Unknown seems to conflict with that, because the responder is
declaring it is not the issuer's responder.

I don't think it's reasonable to argue that 4.9.10 allows for delays in the
initial publication of the OCSP response, and that the update refers to the
time period from revocation by the CA and the publication of that
revocation, in line with 4.9.7. That is, a CA would not be complying with
4.9.9 and 7.1.2.3 (c) in providing services if it responds Unknown, even in
the initial 96 hours (4 days) allowed to delay updating the response. I
highlight this because the other interpretation "Does not know about this",
doesn't seem to fit the BRs definition of providing the service either. Of
course, if folks believe that is what should be permitted, then it's worth
taking up in the CA/B Forum.

Given that Relying Parties will, for example, actively reject Unknown
signatures if stapled in OCSP responses, because why bother stapling a
response in a first place, it seems completely unwise to release a
certificate into the ecosystem which may return Unknown status, especially
for up to 4 days. Ensuring the propagation and replication of those
responses seems to be a requirement of the BRs, and certainly within the
realm of common sense.

Rob Stradling

unread,
Sep 17, 2019, 9:29:07 AM9/17/19
to Wayne Thayer, Andrew Ayer, mozilla-dev-s...@lists.mozilla.org
On 16/09/2019 23:58, Wayne Thayer wrote:
> On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling wrote:
<snip>
> And so at this point ISTM that the OCSP responder is expected to
> implement two conflicting requirements for the serial number in
> question:
>    (1) MUST respond "good", because an unrevoked/unexpired
> precertificate exists (and because BR 4.9.9 mandates a signed OCSP
> response).
>    (2) SHOULD NOT respond "good" (see BR 4.9.10).
>
> If I'm reading BR 4.9.10 correctly, the situation is worse because it
> goes on to state "Effective 1 August 2013, OCSP responders for CAs which
> are not Technically Constrained in line with Section 7.1.5 MUST NOT
> respond with a "good" status for such certificates." (referring to
> 'certificates that have not been issued' from the prior paragraph)

Thanks Wayne. You're right.

(I read the "SHOULD NOT" requirement, forgot it had been superseded, and
didn't read further. I wonder if it would be reasonable to remove the
superseded requirement from the BRs now, given that it was superseded
over 6 years ago?)

> If the desired outcome is for CAs to respond "good" to a precertificate
> without a corresponding certificate, we could override the BRs in
> Mozilla policy, but I'd want to get the BRs updated quickly as Rob
> suggested to avoid audit findings.

+1

> The other piece of this policy that's still unclear to me relates to the
> "unknown" OCSP status. Specifically, Is it currently forbidden for a CA
> to provide an "unknown" OCSP response for an issued certificate? If not,
> should it be? The implication here would be that CAs responding
> "unknown" to precertificates without corresponding certificates are
> doing the right thing, despite prior precedent indicating that this is a
> violation. [1]

This is making my brain hurt.

> - Wayne
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390
>
> Clearly that's impossible, which leads to the question: Which of these
> two conflicting requirements should a CA ignore in order to be as
> un-non-compliant as possible?  Which leads me to BR 7.1.2.5
> <http://7.1.2.5>:
>     that has not been allocated by the CA, then the responder
> SHOULD NOT
>     respond with a "good" status.'
>
> P.S. Full disclosure: Sectigo currently provides an (unsigned)
> "unauthorized" OCSP response when a precert exists but the
> corresponding
> cert doesn't, but in all honesty I'm not currently persuaded that an
> Incident Report is warranted.
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@sectigo.com <mailto:r...@sectigo.com>
>

--
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com

Rob Stradling

unread,
Sep 17, 2019, 9:34:46 AM9/17/19
to Kurt Roeckx, mozilla-dev-s...@lists.mozilla.org
On 17/09/2019 08:01, Kurt Roeckx via dev-security-policy wrote:
> On 2019-09-16 14:02, Rob Stradling wrote:
>>
>> ISTM that this "certificate presumed to exist" concept doesn't play
>> nicely with the current wording of BR 4.9.10:
>>     'If the OCSP responder receives a request for status of a certificate
>>      that has not been issued, then the responder SHOULD NOT respond with
>>      a "good" status.'
>>
>> If a certificate (with embedded SCTs and no CT poison extension) is
>> "presumed to exist" but the CA has not actually issued it, then to my
>> mind that's a "certificate that has not been issued"; and therefore, the
>> OCSP 'responder SHOULD NOT respond with a "good" status'.
>
> The problem of course is that you don't query OCSP about a certificate,
> you query it about a serial number. And that serial number has been
> issued. So maybe the BRs should say serial number instead of certificate?

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

Neil Dunbar

unread,
Sep 17, 2019, 10:00:49 AM9/17/19
to mozilla-dev-s...@lists.mozilla.org


> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <dev-secur...@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.

It seems to me that the trigger point to start answering OCSP requests for a (Issuer, Serial Number) request would be when the serial number has been allocated AND an artefact has been signed by an issuer private key.

In other words, a CA might well allocate a serial number, which, if all goes well, will find its way into a certificate; but until a publicly trusted signature has been made on a TBSCertificate containing that serial number, an OCSP responder is behaving properly were it to answer “Never heard of that serial number for that Issuer”.

Regards,

Neil

Ryan Sleevi

unread,
Sep 17, 2019, 11:14:41 AM9/17/19
to Neil Dunbar, mozilla-dev-s...@lists.mozilla.org
On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
>
> > On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
> dev-secur...@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?


> It seems to me that the trigger point to start answering OCSP requests for
> a (Issuer, Serial Number) request would be when the serial number has been
> allocated AND an artefact has been signed by an issuer private key.
>
> In other words, a CA might well allocate a serial number, which, if all
> goes well, will find its way into a certificate; but until a publicly
> trusted signature has been made on a TBSCertificate containing that serial
> number, an OCSP responder is behaving properly were it to answer “Never
> heard of that serial number for that Issuer”.
>

I'm not sure I follow why that seems to be?

Neil Dunbar

unread,
Sep 17, 2019, 11:29:00 AM9/17/19
to mozilla-dev-s...@lists.mozilla.org


> On 17 Sep 2019, at 16:14, Ryan Sleevi via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
> dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>> wrote:
>
>>
>>
>>> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
>> dev-secur...@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

Wayne Thayer

unread,
Sep 17, 2019, 9:10:40 PM9/17/19
to Neil Dunbar, mozilla-dev-s...@lists.mozilla.org
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-secur...@lists.mozilla.org> wrote:

>
>
> > On 17 Sep 2019, at 16:14, Ryan Sleevi via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
> >
> > On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
> > dev-secur...@lists.mozilla.org <mailto:
> dev-secur...@lists.mozilla.org>> wrote:
> >
> >>
> >>
> >>> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy <
> >> dev-secur...@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

Curt Spann

unread,
Sep 18, 2019, 6:48:11 PM9/18/19
to mozilla-dev-s...@lists.mozilla.org
My interpretation is once a precertificate has been signed with the issuing CA key the corresponding OCSP service should only respond with "good" or "revoked". In this case an "unknown" response indicates the specific serial number for the issuing CA has not been assigned which isn’t the case. Since the serial number has been assigned the OCSP responder should know about the status of that serial number for the issuing CA. If there are no issues with the precertificate that would require its revocation the OCSP responder should respond with “good”. If the precertificate is classified as a misissuance (or any other reason that would require revocation) the OCSP responder should respond with “revoked”.

- Curt

Wayne Thayer

unread,
Sep 18, 2019, 8:18:43 PM9/18/19
to Curt Spann, mozilla-dev-security-policy
Thanks Curt. Reading between the lines of Ryan's and your response, I'm
thinking that we should specifically ban or limit the scope of "unknown"
responses somewhere - perhaps in the BRs. Otherwise I think RFC 6960 leaves
some room for a CA to argue that they are permitted to use that response in
situations such as the one you described.

Wayne Thayer

unread,
Sep 19, 2019, 1:04:16 PM9/19/19
to mozilla-dev-s...@lists.mozilla.org
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 <wth...@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.
>> >>> "- 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

Tim Hollebeek

unread,
Sep 19, 2019, 1:52:45 PM9/19/19
to Rob Stradling, Jeremy Rowley, Alex Cohn, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer
Sorry for being unclear.

If the IETF goes the direction of "pre-certificates are not certificates", then we find ourselves in a world where the RFCs say that they should not get OCSP services, but Mozilla policy (and potentially the BRs) says that they should.

I think that's fine as Mozilla and/or the CABF can and should override RFCs when it makes sense to do so, but I think it would also be helpful in the long term to fix the discrepancy, especially as CT is likely to be used in more certificate ecosystems in the future.

Note that this doesn't mean that CT-bis has to state that pre-certificates are certificates, but it (or something later, or another draft ...) should at mention that OCSP responses for pre-certificates are allowed.
> >> Thinking aloud...
> >> Does anything need to be clarified in 6962-bis though?
> >>>> _______________________________________________
> >>>> dev-security-policy mailing list
> >>>> dev-secur...@lists.mozilla.org
> >>>> https://lists.mozilla.org/listinfo/dev-security-policy
> >>>>
> >>>> _______________________________________________
> >>>> dev-security-policy mailing list
> >>>> dev-secur...@lists.mozilla.org
> >>>> https://lists.mozilla.org/listinfo/dev-security-policy
> >>
> >> --
> >> Rob Stradling
> >> Senior Research & Development Scientist
> >> Email: r...@sectigo.com
> >> Bradford, UK
> >> Office: +441274024707
> >> Sectigo Limited
> >>
> >> This message and any files associated with it may contain legally
> >> privileged, confidential, or proprietary information. If you are not
> >> the intended recipient, you are not permitted to use, copy, or
> >> forward it, in whole or in part without the express consent of the
> >> sender. Please notify the sender by reply email, disregard the foregoing
> messages, and delete it immediately.
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> Email: r...@sectigo.com

Tim Hollebeek

unread,
Sep 19, 2019, 1:56:48 PM9/19/19
to Rob Stradling, Wayne Thayer, mozilla-dev-s...@lists.mozilla.org, Andrew Ayer
> Thanks Wayne. You're right.
>
> (I read the "SHOULD NOT" requirement, forgot it had been superseded, and
> didn't read further. I wonder if it would be reasonable to remove the
> superseded requirement from the BRs now, given that it was superseded over
> 6 years ago?)

Removing out of date requirements was one of the things I did in my spring
cleanup branch, but I don't know if I caught this one. There's some even
older, more obsolete text in there.

-Tim

Ryan Sleevi

unread,
Sep 19, 2019, 2:17:15 PM9/19/19
to Tim Hollebeek, Rob Stradling, Alex Cohn, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer, Jeremy Rowley
On Thu, Sep 19, 2019 at 1:52 PM Tim Hollebeek via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I think that's fine as Mozilla and/or the CABF can and should override
> RFCs when it makes sense to do so, but I think it would also be helpful in
> the long term to fix the discrepancy, especially as CT is likely to be used
> in more certificate ecosystems in the future.


Isn't the core tenet that the IETF does not define policy? This seems very
well rooted in policy, as you note.

The question does not seem to be about whether or not
precertificates-are-certificates (and, in a -bis world, they're clearly a
SignedData-thing-that-isn't), but what constitutes the act of issuance: is
it signing a thing (whether a TBSCertificate or something other, like a
precertificate under 6962 or 6962-bis)? Is it reserving the serial number
and assigning it in the system?

In any event, if/when CT is used in other systems, they'll be using
different CT logs, so they'll really be entirely different ecosystems. It
seems that the policy management authority (i.e. the equivalent to
browsers, in the Web PKI) for those ecosystems can provide clarity, and it
further emphasizes why a single CA certificate should not participate in
multiple PMAs, to reduce the risk of and avoid conflicts and/or
misunderstandings.

Tim Hollebeek

unread,
Sep 19, 2019, 2:57:05 PM9/19/19