DigiCert OCSP services returns 1 byte

[Curt Spann]

Hello,

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

[Peter Gutmann]

Curt Spann via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

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

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]

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]

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,

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

[Ryan Sleevi]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

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]

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

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]

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]

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]

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]

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]

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

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]

I think “IETF does not define policy” is about as true as “individuals represent themselves at IETF.” But that’s a longer rathole.



I also don’t think it’s helpful to try to redefine long-standing and well-understood terminology like what it means to issue a certificate. In fact, I just checked, and using a definition like “reserving a serial number” causes many of the issuance requirements in RFC 5280 to be non-sensical.



It would be helpful for one of the relevant documents, or another document, or even an errata, to clarify that OCSP services can be offered for pre-certificates. It’s merely a question of clarifying the technical requirements about how an OCSP service should operate, as those requirements currently can be read to not allow OCSP responses for non-certificates.



Not sure what reason there would be to oppose such a simple clarification that aligns the relevant requirements with the desired policy, especially since it is backwards compatible.

-Tim



From: Ryan Sleevi <ry...@sleevi.com>

Sent: Thursday, September 19, 2019 2:17 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: Rob Stradling <r...@sectigo.com>; Alex Cohn <al...@alexcohn.com>; mozilla-dev-s...@lists.mozilla.org; Wayne Thayer <wth...@mozilla.com>; Jeremy Rowley <jeremy...@digicert.com>
Subject: Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi]

On Thu, Sep 19, 2019 at 2:55 PM Tim Hollebeek <tim.ho...@digicert.com>
wrote:

> I also don’t think it’s helpful to try to redefine long-standing and
> well-understood terminology like what it means to issue a certificate. In
> fact, I just checked, and using a definition like “reserving a serial
> number” causes many of the issuance requirements in RFC 5280 to be
> non-sensical.
>

It was DigiCert that introduced me to this way of thinking, when they
similarly argued that revocation is the process of marking a serial number
revoked within an internal database, rather than the publication of a CRL
or OCSP response.
https://groups.google.com/d/msg/mozilla.dev.security.policy/eV89JXcsBC0/7hkz9iJDAQAJ

> It would be helpful for one of the relevant documents, or another
> document, or even an errata, to clarify that OCSP services can be offered
> for pre-certificates. It’s merely a question of clarifying the technical
> requirements about how an OCSP service should operate, as those
> requirements currently can be read to not allow OCSP responses for
> non-certificates.
>

I'm still not sure I agree with the conflict, which is the key. In either
event, we're arguably discussing a profile / the operational constraints
specific to a given CA, and not something general with the protocol.
Whether or not a pre-certificate is treated as equivalent issuance is,
ultimately, a policy question.

[Dimitris Zacharopoulos]

Dear Wayne,

According to section 2.2 of RFC 6960, an OCSP responder may respond
"revoked" for a "non-issued" Certificate. It even allows this response
for "unknown" Certificates in order to support backwards compatibility
with implementations of RFC 2560.

In addition to that, section 4.4.8 labeled "Extended Revoked Definition"
says:

"This extension MUST be included in the OCSP response when that response
contains a "revoked" status for a non-issued certificate".

Also, from section 2.2 <https://tools.ietf.org/html/rfc6960#section-2.2>
When a responder sends a "revoked" response to a status request for a
non-issued certificate, the responder MUST include the extended revoked
definition response extension (Section 4.4.8) in the response,
indicating that the OCSP responder supports the extended definition of
the "revoked" state to also cover non-issued certificates. In addition,
the SingleResponse related to this non-issued certificate:

1. the responder MUST include the extended revoked definition response
extension
2. In addition, the SingleResponse related to this non-issued certificate:

* MUST specify the revocation reason certificateHold (6),
* MUST specify the revocationTime January 1, 1970, and
* MUST NOT include a CRL references extension (Section 4.4.2) or any
CRL entry extensions (Section 4.4.5).

By reading the BRs (section 6.9.13), it is clear that TLS Certificates
are not allowed to be "suspended". However, if an RFC 6960 compliant
OCSP responder responds with "revoked" for an unknown serial number and
then issues a certificate with the same requested serial number, it will
later return a response "good". This seems to be an allowed practice
therefore it should be OK for a responder to change a "revoked" status
to "good". In addition to that, 6960 demands that for non-issued
Certificates, the responder must use the revocationReason "certificateHold".

To summarize:

* The BRs reference RFC 6960
* The BRs forbid to have Certificates "suspended" (i.e.
revocationReason |certificateHold|)
* revoked-for-unknown must contain the Extended Revoked extension, so
a client knows that this was a response for a non-issued certificate.

Using the following practice as described in RFC 6960 should not be a
violation of the BRs. That is, answering revoked where a pre-certificate
has been issued but not the final certificate should be OK as long as
the response contains the Extended Revoked extension and the
revocationReason is |certificateHold|. With this practice, it is very
clear that the final certificate has
not been issued, so would this be considered a violation of the Mozilla
policy?

I added this as a comment to https://github.com/mozilla/pkipolicy/issues/189
because I know that this mailing list messes up the formatting.


Thanks,
Dimitris.

On 2019-09-19 8:02 μ.μ., Wayne Thayer via dev-security-policy wrote:
> I have gone ahead and added a section titled "Precertificates" [1] to the
> Required Practices wiki page.
>
> I have also updated a policy issue [2] suggesting that this be moved into
> the Root Store policy, and added a new issue [3] suggesting that we clarify
> the acceptable use of the "unknown" OCSP response.
>
> I plan to sponsor a CAB Forum ballot to resolve the inconsistency with BR
> 7.1.2.5.
>
> - Wayne
>
> [1]
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates
> [2] https://github.com/mozilla/pkipolicy/issues/138
> [3] https://github.com/mozilla/pkipolicy/issues/189
>
> On Tue, Sep 17, 2019 at 6:10 PM Wayne Thayer <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.

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

[Rob Stradling]

On 16/09/2019 18:08, Andrew Ayer wrote:
> 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:

Thanks Andrew. I'll start a thread on the TRANS list to discuss this.

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

--
Rob Stradling
Senior Research & Development Scientist

Sectigo Limited

[Rob Stradling]

On 19/09/2019 21:01, Ryan Sleevi wrote:
<snip>

> It would be helpful for one of the relevant documents, or another
> document, or even an errata, to clarify that OCSP services can be
> offered for pre-certificates.  It’s merely a question of clarifying
> the technical requirements about how an OCSP service should operate,
> as those requirements currently can be read to not allow OCSP
> responses for non-certificates.
>
>
> I'm still not sure I agree with the conflict, which is the key. In
> either event, we're arguably discussing a profile / the operational
> constraints specific to a given CA, and not something general with the
> protocol. Whether or not a pre-certificate is treated as equivalent
> issuance is, ultimately, a policy question.

Tim, Ryan,

I just started a thread on the TRANS list about this. Please could I
ask you to take this discussion there?

[Ryan Sleevi]

I've replied there as to why I think it belongs here, and is inappropriate
for there.

[Wayne Thayer]

On Fri, Sep 20, 2019 at 4:56 AM Dimitris Zacharopoulos <ji...@it.auth.gr>
wrote:

> <snip>

>
> Using the following practice as described in RFC 6960 should not be a
> violation of the BRs. That is, answering revoked where a pre-certificate
> has been issued but not the final certificate should be OK as long as the
> response contains the Extended Revoked extension and the revocationReason

> is certificateHold. With this practice, it is very clear that the final

> certificate has
> not been issued, so would this be considered a violation of the Mozilla
> policy?
>

Yes, I think it would be a violation of Mozilla policy for a CA's OCSP
responder to return a certificateHold reason in a response for a
precertificate. As you noted, the BRs forbid certificate suspension.
Mozilla assumes that a certificate corresponding to every precertificate
exists, so the OCSP response would be interpreted as applying to a
certificate and thus violating the BRs.

In practice, I also think that Ryan has raised a good point about OCSP
response caching. If a revoked response for a precertificate were supplied
by a CA, would the Subscriber need to wait until that response expires
before using the certificate, or else risk that some user agent has cached
the revoked response?

[Curt Spann]

This is a great discussion and I want to thank everyone for their continued input. Let me try and summarize my interpretation based on the input from this thread and related RFC.

My interpretation is an “unknown” OCSP response should be used in the following conditions:
1. When the OCSP request contains an issuerNameHash and issuerKeyHash for which the OCSP responder is NOT authoritative (wrong issuing CA).
2. When the OCSP request contains an issuerNameHash and issuerKeyHash for which the OCSP responder IS authoritative (correct issuing CA) but for whatever reason the OCSP responder does not know the status of the requested certificates and ONLY if the certificate for which the status is requested contains another OCSP responder URL available in the AIA extension.

My interpretation is a “revoked” OCSP response should be used in the following conditions:
1. When the OCSP request contains an issuerNameHash and issuerKeyHash for which the OCSP responder IS authoritative and the requested certificate has been revoked.
2. When the OCSP request contains an issuerNameHash and issuerKeyHash for which the OCSP responder IS authoritative and the CA corresponding to the issuerNameHash and issuerKeyHash has been revoked.
3. When the OCSP request contains an issuerNameHash and issuerKeyHash for which the OCSP responder IS authoritative and the requested certificate has not been issued. This OCSP response MUST include the extended revoked definition response extension in the response, indicating that the OCSP responder supports the extended definition of the "revoked" state to also cover non-issued certificates. The SingleResponse related to this non-issued certificate MUST specify the revocation reason certificateHold (6), MUST specify the revocationTime January 1, 1970, and MUST NOT include a CRL references extension or any CRL entry extensions. [1]

I agree number 3 above is in conflict with the BRs as pointed out by Wayne.

- Curt

[1] RFC 6960: https://tools.ietf.org/html/rfc6960

[Andy Warner]

Google Trust Services (GTS) reached out to Wayne directly, but I'm also posting here as the conversation seems to be rapidly converging on solutions. GTS still has reservations that the proposed solutions may be problematic to implement and may leave a number of CAs and one very common CA vendor in a bind to get from their current state to whatever the final state is cleanly. While Mozilla's requirements and recommendations are not strictly binding, they carry a great deal of weight and could lead to rapid implementation of a sub-standard solution.

Google Trust Services would like to see the current precertificate 'requirements' moved to the 'recommendations' section with a note explaining that once the formal details are worked out via bylaw changes (preferably) or further discussion on m.d.s.p (if bylaw changes are deemed too slow), they will become requirements.

Sorry to post late in the process like this. Unfortunately, as a globally distributed team within a much larger company, Google Trust Services team cannot always move and post as quickly as we'd like. We will follow-up early next week with more details about our concerns, but there are a number of complex interactions and subtly conflicting requirements that seem best served by taking the time to ensure the final state is settled on in haste. It would be great to achieve consistency sooner than later, so a time bounded window to get there seems best to balance convergence versus a rush to decisions that may adversely affect the ecosystem or be a challenge to live with for years.

--
Andy Warner
Google Trust Services

[Ryan Sleevi]

I'll share this publicly, so that there's no suggestion that personally or
professionally Google Trust Services is treated any differently than any
other CA. As a publicly trusted CA, I personally find this a deeply
disappointing post towards positive engagement. It's disappointing because
it lacks substance and yet makes broad (and negative) claims, and while it
highlights the importance of avoiding a "sub-standard solution", it doesn't
actually offer any meaningful or concrete technical feedback or even
highlight concerns, only an intent to delay discussion.

However, my greatest concern is the misrepresentation about the nature of
requirements and recommendations, which are the /only/ binding thing for a
publicly trusted CA in Mozilla's program. This, coupled with the suggestion
of a "bylaw change" (which is ambiguous as to what is meant here, but might
be presumed to mean a change in a CA/B Forum ballot), is concerning,
because it seems to suggest a movement from a public discussion to a
private discussion, and seems very contrary to the spirit of an open and
productive discussion, and seems to match a tactic used by several
concerning CAs to delay necessary or positive improvements.

Perhaps these aren't intended, and I realize that GTS' involvement in
m.d.s.p. to date has largely been limited to Incident Responses, and so as
a first response, it may still be a learning experience. I know Ryan Hurst
was much more engaged and prolific here, in the past and in an official
capacity, and much more engaged on technical substantive and positive
contributions, and his contributions were often very valuable. I'm glad to
see GTS is, like every other CA in the Mozilla program, following the
conversation, and like some of the CAs in the program, moving to a point
where they actively participate in the discussions. These are good things,
and while some are already required, it's good to see GTS actually step up.
But as a first message, it leaves a lot to be desired, both in terms of
when and in terms of what.

I appreciate the commitment to post and share further details, and look
forward to understanding GTS' concerns. I understand that there can be
challenges in getting approvals, and I can understand and appreciate CAs'
face challenges in public engagement, even though they're publicly trusted.
Yet that should still remain a common expectation of all publicly trusted
CAs. We know that when CAs present it as overly burdensome to engage
publicly, a number of behaviours tend to emerge that are overall harmful to
public trust. I hope you can take this feedback as a positive exhortation
to encourage the good, while highlighting deep concerns with the substance,
approach, and proposals and why it's worked out very poorly over the past
decade+.

If the concern is around extended revoked, I wholly agree there are
concerns there. I'm not sure I'm wholly onboard with Curt's processing
model either, and will respond separately to that, but I think it's a huge
and positive contribution that Curt's made, because it helps provide
something concrete to talk about. However, when there are concerns, it's
better for the discussion to plainly state that, rather than the spectre of
vague concerns. If it's something else, it helps to know what it is, and
I'm not sure a conversation hamstrung by 2-3+ day turnarounds, as currently
seems to be the suggestion, really helps show a CA being agile enough to
lead with good practices.

[Ryan Sleevi]

On Fri, Sep 20, 2019 at 4:20 PM Curt Spann via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> This is a great discussion and I want to thank everyone for their
> continued input. Let me try and summarize my interpretation based on the
> input from this thread and related RFC.
>

I think an important part missing from this, overall, is to highlight that
these clauses only apply with respect to definitive responses. That is,
this only applies to the set of responses for which a pre-certificate
exists (and thus a matching certificate is presumed to exist) or for where
a certificate actually exists.

For situations where neither a pre-certificate nor the actual certificate
exist, a responder isn't required to respond with a definitive response.
This is important to highlight, because the BRs allow for the use of
either/both of the 6960-profile of OCSP, or the 5019 (Lightweight) profile
of OCSP. The latter is important, because it more realistically reflects
what the majority of CAs implement, and we've seen that running online
signing via 6960 is fraught with peril (e.g. Andrew Ayer's excellent
analysis in 2016 -
https://groups.google.com/d/msg/mozilla.dev.security.policy/x3TOIJL7MGw/0fzCI3q3BQAJ
).

In a 5019, the response of "unauthorized" is specifically extended to
account for some of these operational concerns, within Section 2.2.3.

So it was unclear if you were attempting to exhaustively list the statuses
that a CA might generate, or exhaustively list the statuses relevant to the
subset of (pre-cert || cet). For the rest, I'll assume the latter - that
we're only talking about "proof of existence" well, existing.

> My interpretation is an “unknown” OCSP response should be used in the
> following conditions:
> 1. When the OCSP request contains an issuerNameHash and issuerKeyHash for
> which the OCSP responder is NOT authoritative (wrong issuing CA).
>

Presuming the OCSP responder supports the requestor CertID algorithm :)

> 2. When the OCSP request contains an issuerNameHash and issuerKeyHash for
> which the OCSP responder IS authoritative (correct issuing CA) but for
> whatever reason the OCSP responder does not know the status of the
> requested certificates and ONLY if the certificate for which the status is
> requested contains another OCSP responder URL available in the AIA
> extension.
>

I'm not sure I understand where the "ONLY" clause comes from? 6960 and 5280
both presuppose the existence of other sources of revocation, beyond those
enumerated within the AIA. For 6960, Section 2.2 leaves this a bit up in
the air. So I don't think either the policies or text currently require
this "ONLY" clause, but I do think we want to nail down the situations
here. As it relates specifically to the (precert || cert) case, the BRs
treat the responder as a singular "the", so I don't think the ONLY
applies... so I think this whole thing washes out as "not allowed" for the
case of (precert || cert), and is met by "unauthorized", as well as
possible transport-layer options (RFC 5019 is somewhat silent, AFAICT, on
this)

> My interpretation is a “revoked” OCSP response should be used in the
> following conditions:
> 1. When the OCSP request contains an issuerNameHash and issuerKeyHash for
> which the OCSP responder IS authoritative and the requested certificate has
> been revoked.
>

Agreed

> 2. When the OCSP request contains an issuerNameHash and issuerKeyHash for
> which the OCSP responder IS authoritative and the CA corresponding to the
> issuerNameHash and issuerKeyHash has been revoked.
>

Agreed, with a caveat. This is a MAY derived from Section 2.7, and so I
wasn't sure if the suggestion was enumerating it as a MUST ("should be
used") or merely acknowledging it as a valid situation for revoked.

> 3. When the OCSP request contains an issuerNameHash and issuerKeyHash for
> which the OCSP responder IS authoritative and the requested certificate has
> not been issued. This OCSP response MUST include the extended revoked
> definition response extension in the response, indicating that the OCSP
> responder supports the extended definition of the "revoked" state to also
> cover non-issued certificates. The SingleResponse related to this
> non-issued certificate MUST specify the revocation reason certificateHold
> (6), MUST specify the revocationTime January 1, 1970, and MUST NOT include
> a CRL references extension or any CRL entry extensions. [1]
>

This is where we get messy, and what I was trying to untangle above.

If the assumption of policy is that the existence of a pre-certificate is
proof of equivalent issuance, then the only situation this arises is if and
only if the CA is running an online signing service in line with 6960,
rather than the pre-distribution approach of RFC 5019 that the scale of the
Web PKI effectively ensures is necessary, and only in the cases where a
pre-certificate /doesn't/ exist.

This isn't entirely pedantry on "issuance" either - as called out in 6960,
Section 2.2, "non-issuance" is
the associated CA
has no record of ever having issued a certificate with the
certificate serial number in the request, using any current or
previous issuing key

The existence of a pre-certificate is, as noted, proof that the CA has a
record of having issued a certificate with the certificate serial number in
the request.

It's important to realize that Section 5 of RFC 6960 highlights further
discussion here, which notes that this situation is completely avoided by
issuing serials with random entropy - i.e. what the BRs require.

So to recap:
- In RFC 5019, it's clear that one of the core goals of 5019 is to not
require the creation of definitive responses for the entire serial space.
So we're only talking (pre-cert || cert) definitive cases.
- In RFC 6960, it's clear that one of the core goals of the extended
response is to leave it /optional/ (MAY) for CAs to respond Revoked, and
for serial numbers they have no record of having issued. So we're talking
!(pre-cert || cert) cases.

[Curt Spann]

Great feedback. This is exactly the type of input needed to get clarity around operating OCSP responder services for certificates in the WebPKI ecosystem.

> I think an important part missing from this, overall, is to highlight that these clauses only apply with respect to definitive responses. That is, this only applies to the set of responses for which a pre-certificate exists (and thus a matching certificate is presumed to exist) or for where a certificate actually exists.

Agreed, these clauses need to apply to definitive responses (pre-cert || cert).

> Presuming the OCSP responder supports the requestor CertID algorithm :)

Correct.

> I'm not sure I understand where the "ONLY" clause comes from? 6960 and 5280 both presuppose the existence of other sources of revocation, beyond those enumerated within the AIA. For 6960, Section 2.2 leaves this a bit up in the air. So I don't think either the policies or text currently require this "ONLY" clause, but I do think we want to nail down the situations here. As it relates specifically to the (precert || cert) case, the BRs treat the responder as a singular "the", so I don't think the ONLY applies... so I think this whole thing washes out as "not allowed" for the case of (precert || cert), and is met by "unauthorized", as well as possible transport-layer options (RFC 5019 is somewhat silent, AFAICT, on this)

My interpretation incorrectly presumed only OCSP as an option. I was attempting to address the NOTE in RFC 6960 from Section 2.2 but I failed to account for CRLs:

NOTE: The "revoked" status indicates that a certificate with the
requested serial number should be rejected, while the "unknown"
status indicates that the status could not be determined by
this responder, thereby allowing the client to decide whether
it wants to try another source of status information (such as a
CRL).

> Agreed, with a caveat. This is a MAY derived from Section 2.7, and so I wasn't sure if the suggestion was enumerating it as a MUST ("should be used") or merely acknowledging it as a valid situation for revoked.

I was acknowledging it as a valid situation for revoked and did pull from Section 2.7.

> If the assumption of policy is that the existence of a pre-certificate is proof of equivalent issuance, then the only situation this arises is if and only if the CA is running an online signing service in line with 6960, rather than the pre-distribution approach of RFC 5019 that the scale of the Web PKI effectively ensures is necessary, and only in the cases where a pre-certificate /doesn't/ exist.

I must admit I was focused on RFC 6960 and should have been including RFC 5019 in my interpretation.

> So to recap:
> - In RFC 5019, it's clear that one of the core goals of 5019 is to not require the creation of definitive responses for the entire serial space. So we're only talking (pre-cert || cert) definitive cases.
> - In RFC 6960, it's clear that one of the core goals of the extended response is to leave it /optional/ (MAY) for CAs to respond Revoked, and for serial numbers they have no record of having issued. So we're talking !(pre-cert || cert) cases.

Well said.

- Curt

[Dimitris Zacharopoulos]

On 20/9/2019 11:00 μ.μ., Wayne Thayer wrote:
> On Fri, Sep 20, 2019 at 4:56 AM Dimitris Zacharopoulos
> <ji...@it.auth.gr <mailto:ji...@it.auth.gr>> wrote:
>
> <snip>
>
> Using the following practice as described in RFC 6960 should not
> be a violation of the BRs. That is, answering revoked where a
> pre-certificate has been issued but not the final certificate
> should be OK as long as the response contains the Extended Revoked

> extension and the revocationReason is |certificateHold|. With this

> practice, it is very clear that the final certificate has
> not been issued, so would this be considered a violation of the
> Mozilla policy?
>
> Yes, I think it would be a violation of Mozilla policy for a CA's OCSP
> responder to return a certificateHold reason in a response for a
> precertificate. As you noted, the BRs forbid certificate suspension.
> Mozilla assumes that a certificate corresponding to every
> precertificate exists, so the OCSP response would be interpreted as
> applying to a certificate and thus violating the BRs.
>
> In practice, I also think that Ryan has raised a good point about OCSP
> response caching. If a revoked response for a precertificate were
> supplied by a CA, would the Subscriber need to wait until that
> response expires before using the certificate, or else risk that some
> user agent has cached the revoked response?

Dear Wayne,

This list has discussed about compatibility issues several times in the
past, so we must consider how Mozilla supports the majority of clients.
RFC 6960 does not just mandate that the revocationReason is
|certificateHold|. It requires a certain revocation date AND a specific
extension that unambiguously point to a "non-issued" Certificate, not a
"Suspended" Certificate in general. This means that there is technical
language to distinguish the case of a Certificate being "suspended" and
a Certificate being "non-issued".

OCSP response caching is equally problematic for "unknown" responses
which are also cached. The behavior of clients in sight of an "unknown"
or "revoked"-with-additional-info response, should be more or less the
same (i.e. don't trust the certificate).

Neither the Mozilla policy language nor the ||BRs support the assumption
that whenever we have an OCSP response of "certificateHold", this means
the certificate is "Suspended". My interpretation is that if a response
provides all of the following information:
- status --> revoked
- revocation reason --> certificateHold
- revocationTime --> January 1, 1970
- MUST NOT include a CRL references extension or any CRL entry extensions
- includes the extended revoke extension

then this is the consistent semantics for a "non-issued" certificate,
not about a Certificate that was "issued" and then "suspended".

Is this a reasonable interpretation?

Dimitris.

[Ryan Sleevi]

I do not believe this is a reasonable interpretation, precisely because
6960 uses this status so that the revocation is temporary, and attackers
can not use this to cause responders to mark serials they have not yet used
as revoked.

>

[Dimitris Zacharopoulos]

Doesn't this break compatibility with older clients? It is older clients
that need to see "revoked" which is equivalent to "not good" for cases
of "non-issued" Certificates. I think this is what 6960 is trying to
accommodate. Older clients will see "revoked" but newer clients will see
"revoked" plus additional information to interpret as "non-issued". Is
there any specific text in the Mozilla Policy or the BRs that strictly
forbids the use of this RFC 6960 practice?

BRs 4.9.13: "The Repository MUST NOT include entries that indicate that
a Certificate is suspended."

[Ryan Sleevi]

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

No.

Older clients will see "revoked" but newer clients will see
> "revoked" plus additional information to interpret as "non-issued". Is
> there any specific text in the Mozilla Policy or the BRs that strictly
> forbids the use of this RFC 6960 practice?
>
> BRs 4.9.13: "The Repository MUST NOT include entries that indicate that
> a Certificate is suspended."

You just quoted it.

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

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

If you are running a 6960 responder, and you don’t believe it applies to
pre-certificates, we should work that out first.

[Dimitris Zacharopoulos]

On 2019-09-23 3:02 μ.μ., Ryan Sleevi wrote:
>
>
> On Mon, Sep 23, 2019 at 12:50 PM Dimitris Zacharopoulos

> <ji...@it.auth.gr <mailto:ji...@it.auth.gr>> wrote:
>
>
[...]

2.2 applies to pre-certificates but between when the pre-certificate and
the final certificate is issued, there is a gap. As I understand it,
this is the main topic of this discussion, trying to interpret the best
course of action for this gap. If the responder was allowed to respond
with revoked and all the provisions of 6960 related to "non-issued"
certificates, until the final certificate is issued (if it is ever
issued), that seems like a safer option for Relying Parties because they
would not risk seeing a "valid" response for a Certificate that has not
been issued yet.

That was my initial thought which made me post to this thread. I thought
it made sense but I could be wrong.

Dimitris.

[Ryan Sleevi]

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

>
>
> On 2019-09-23 3:02 μ.μ., Ryan Sleevi wrote:
>
> It would be useful to identify whether there’s an objective to the
> questions, since that might help us cut down things quicker:
> - Are you running a 5019 responder or a 6960 responder?
> - Do you agree that the definition in 6960, Section 2.2, applies to
> pre-certificates?
>
> If you are running a 6960 responder, and you don’t believe it applies to
> pre-certificates, we should work that out first.
>
>
> 2.2 applies to pre-certificates but between when the pre-certificate and
> the final certificate is issued, there is a gap.
>

Got it.

The point in trying to communicate is that with 2.2, the issuance of a
precertificate is proof that it is “not non-issued”. This double negative
is hard to parse, but it is essential: The gap comes up if you assume it’s
trying to measure the issuance of C, the certificate, but it isn’t - it’s
measuring when the CA doesn’t know if that serial number has been assigned.
Because it’s measured by non-issuance, and the precertificate is proof of
“not non-issuance”

The only time where 6960 gets tricky is covered in Section 5: if a CA
chooses to use authoritative revoked for non-issued and it uses sequential
serial numbers. 5019 explains why you shouldn’t (and why you cannot,
effectively), and 6960 leaves it optional. However, since no CA uses
sequential serial numbers, there’s no reason to generate definitive revoked
messages for “non-issued” certificates, and the existence of a
precertificate is proof that it is “not non-issued”

As I understand it, this is the main topic of this discussion, trying to
> interpret the best course of action for this gap. If the responder was
> allowed to respond with revoked and all the provisions of 6960 related to
> "non-issued" certificates, until the final certificate is issued (if it is
> ever issued), that seems like a safer option for Relying Parties because
> they would not risk seeing a "valid" response for a Certificate that has
> not been issued yet.
>

No. That’s the more dangerous approach which I’ve tried repeatedly to
dissuade. You should produce, and distribute, the Good response with the
pre-certificate.

[Dimitris Zacharopoulos]

On 2019-09-23 5:00 μ.μ., Ryan Sleevi via dev-security-policy wrote:
> No. That’s the more dangerous approach which I’ve tried repeatedly to
> dissuade. You should produce, and distribute, the Good response with the
> pre-certificate.

Understood. Thank you for the clear guidance.

Dimitris.

[Andy Warner]

The last thing we intended was for our prior mail to be interpreted as negative and without substance.  That said, it is clear our mail was not received in the light in which it was intended.

We would like to rectify that. We have been closely monitoring this thread and as it began to converge on a conclusion we started planning for each of our CA environments what if any changes would be required and what solutions compliant with our understanding of the conclusions would look like.

With that background, our understanding is that the goal of this change is to make it easier to monitor the issuance and revocation practices of a CA based on the existence of precertificates, i.e. extending the use of certificate revocation data to include this monitoring use case. We see value in this and are supportive of the overall change, as it is clear that CT, as a whole, has made significant quality improvement to the WebPKI as a whole and this provides additional incremental benefit.

However, we see several challenges that we want to discuss, in particular:

1. The new text added to the Mozilla Recommended and Required Practices for this topic states only OCSP status is required for precertificates. Many CAs provide both CRLs and OCSP services and it would be problematic if these two mechanisms provided different answers to the same question. 

The practice of revoking non-issued certificates would therefore lead to CRL growth which would further make reliable revocation checking on bandwidth constrained clients more difficult.

Though this tax may be deemed acceptable, there is a clear impact and GTS feels that increasing CRL sizes for this use case is not in the best interest of users. We can see both sides of the argument, but we think a bit more detail is required to ensure our implementations align with best practices and user interests.

2. There seem to be a number of assumptions that precertificate issuance and certificate issuance is roughly atomic. In reality, a quorum of SCTs is required prior to final certificate issuance, so that is not the case.

CAs are rate limited by logs or logs experience availability issues that make achieving quorum require retries or fail altogether. GTS, for example, experiences approximately 0.05% delays / order abandonment related to an inability to achieve quorum.

As a result of this, the existence of a precertificate is possible without a final certificate having been issued. With the wider availability of sharded logs, this number has been improving, but it continues to be our most common cause of issuance delay or order abandonment.

3. This raises the question of how much time a CA has from the time they issue a precertificate to when the final certificate must be issued. When there are logs ecosystem issues that are beyond the control of a CA, the gap can easily be orders of magnitude higher than normal operating conditions.

Likewise, there is the question of how soon the revocation information must be produced and reachable by an interested party (e.g. someone who has never seen the certificate in question but still wants to know the status of that certificate). [Aside, Wayne, you specifically said relying parties earlier, did you intend to say interested party or relying party? We have some additional questions if relying party was actually intended, as using it in that context seems to redefine what a relying party is.]

This “reachable” part is particularly meaningful in that when using a CDN there are often phased roll outs that can take hours to complete. Today, the BRs leave this ambiguous, the only statement in this area is that new information must be published every four days:

"The CA SHALL update information provided via an Online Certificate Status Protocol at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days."

With this change, it would seem there needs to be a lower bound defined for how quickly the information needs to be available if it is to be an effective monitoring tool.

* Clarifications

This in turn raises the question if CAs can re-use authorization data such as CAA records or domain authorizations from the precertificate? If a final certificate has not been issued due to a persistent quorum failure, and that failure persists longer than the validity of the used authorization data, can the authorizations that were done prior to the precertificate issuance be re-used? If the precertificate is a promise to issue the exact same cert, it would seem to imply yes, but there are plenty or real world scenarios where that would not be sensible or in-line with the requester's intent. If the CAA record changes between initial validation for the precertificate and re-validation for actual issuance if there were delays, what is the correct course of action? 

* Process

On Thursday last week, Wayne added the topic to Recommended and Required Practices (https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates) as a “requirement”. 

It is entirely the right of each browser to have their own technical requirements, in this particular case it seems that implementation changes will be needed in several CA software packages and in-house implementations to meet this interpretation.

As such, in our opinion, a roll out period to enable software and deployment changes to be made would be appropriate. Had this conversation taken place within the CA/Browser forum, the implementation date would have been discussed before becoming a formal requirement. We leave it to Browsers to determine reasonable timelines and we're not seeking to delay, simply recognition that many changes take time to implement and it is tough to effectively respond to changes that become new requirements in an instant.

Browsers should set whatever requirements they believe are in the best interest of their users, but the more requirements are split across multiple root program's requirements, the CA/Browser Forum and IETF, the harder it becomes to reason about what a correct behavior is. Given the historical precedent of rule making in CA/Browser forum and the fact that it covers all participants, it seems like the ideal body to ensure consistency within the ecosystem. As a community body with often divergent viewpoints, we acknowledge that users are not always best served by waiting on change via the CA/B Forum. In a case like this, Browsers making recommendations on their preferred practices without being overly prescriptive initially helps ensure the community is moving in the right direction. If formal clarification via the CA/B Forum is not proceeding quickly enough, shifting from recommendations to requirements may well be appropriate on a timeline commensurate to the severity of the issue. 

--
Andy Warner
Google Trust Services

[Kurt Roeckx]

On Mon, Sep 23, 2019 at 02:53:26PM -0700, Andy Warner via dev-security-policy wrote:
>
> 1. The new text added to the Mozilla Recommended and Required Practices for this topic states only OCSP status is required for precertificates. Many CAs provide both CRLs and OCSP services and it would be problematic if these two mechanisms provided different answers to the same question. 
>
> The practice of revoking non-issued certificates would therefore lead to CRL growth which would further make reliable revocation checking on bandwidth constrained clients more difficult.

There have been suggestions to revoke them, but it's my
understanding that there is no such requirement.

> 2. There seem to be a number of assumptions that precertificate issuance and certificate issuance is roughly atomic. In reality, a quorum of SCTs is required prior to final certificate issuance, so that is not the case.

I don't see anybody suggesting that, nor how it's relevant.

With all the uptime requirements on the logs and the number of
available logs, I don't see why you should have a failure rate
of 1 in 2000, and that more seems like an implementation problem.

> 3. This raises the question of how much time a CA has from the time they issue a precertificate to when the final certificate must be issued. When there are logs ecosystem issues that are beyond the control of a CA, the gap can easily be orders of magnitude higher than normal operating conditions.

At what is the issue with that?

> * Clarifications
>
> This in turn raises the question if CAs can re-use authorization data such as CAA records or domain authorizations from the precertificate? If a final certificate has not been issued due to a persistent quorum failure, and that failure persists longer than the validity of the used authorization data, can the authorizations that were done prior to the precertificate issuance be re-used?

So 1 year is sometimes not enough to get SCTs?


Kurt

[Andy Warner]

The CRL question is not about it being a requirement, but rather the fact
that it could / would lead to disparate treatment between CRL and OCSP for
the same certificate, which does not feel right.

On the CT quorum issue, we use a mix of the most available sharded logs and
that is the failure rate we're observing. We have a few ideas for
improvements we're working on. If other operators are seeing much different
success rates, we'd love to compare notes. We're using the published best
practices, spreading load and using sharded logs, so an implementation
issue is not obvious if there is one. That said, other groups within Google
including the CT team also exchange messages with CT logs in fairly high
volumes, so we may experience atypically high rate-limiting due to all
being bucketed together.

CAA validations are only good for 8 hours, so the suggestion of a year
misses the much shorter timeline that needs to be honored for CAA.

--
Andy Warner
Google Trust Services

[Curt Spann]

> The CRL question is not about it being a requirement, but rather the fact
> that it could / would lead to disparate treatment between CRL and OCSP for
> the same certificate, which does not feel right.

The CRL would only grow if the (pre-cert || cert) needed to be revoke for any reason. CRLs only contain a list of revoked (pre-cert || cert) and don’t attempt to address whether the (pre-cert || cert) has been issued.

- Curt

[Ryan Sleevi]

On Mon, Sep 23, 2019 at 11:53 PM Andy Warner via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> The practice of revoking non-issued certificates would therefore lead to
> CRL growth which would further make reliable revocation checking on
> bandwidth constrained clients more difficult.

As others have pointed out, it sounds like GTS is confused. This only
applies if you need to revoke them.

I’m not sure how many times it bears repeating, but the suggestion that you
need to revoke if you issued a precert, but not the cert, is patently
absurd. Among other things, as you point out, it causes both CRL and OCSP
growth.

Luckily, every browser participating has seemingly tried to make it clear
that’s not expected. So one objection handled :)

2. There seem to be a number of assumptions that precertificate issuance
> and certificate issuance is roughly atomic. In reality, a quorum of SCTs is
> required prior to final certificate issuance, so that is not the case.

Could you point to an example? All of the conversation I’ve seen has
highlighted that they are sequential, and can suffer a variety of delays or
errors. This is why the conversation has been about the least error prone
approach, in that it leads to the most consistent externally observable
results.

I admit, I’m honestly not sure what part of the conversation is being
referred to here.

As a result of this, the existence of a precertificate is possible without
> a final certificate having been issued.

Yup. And it’s been repeatedly acknowledged that is perfectly fine. The
proposed language further considers that, but emphasizes that by producing
and logging the precertificate, then regardless of the issue, the CA should
be prepared to provision services for it for the duration.

If you find yourself continually generating precertificates, that suggests
an operational/design issue, which you can remediate based on which is
cheaper for you: fixing the pipeline to be reliable (as many reliability
issues seen, to date, have been on the CA side) or continue to provision
services when things go bad. Either works, you can choose.

The important part is you need to treat (pre-cert || cert) in scope for all
your activities. You must be capable of revoking. You must be capable of
searching your databases. You must be capable of validating.

3. This raises the question of how much time a CA has from the time they
> issue a precertificate to when the final certificate must be issued.

It doesn’t, because it’s a flawed understanding that’s been repeatedly
addressed: you don’t have to issue the final certificate. But you MUST be
prepared to provision services as if you had.

In general, this means you provision and distribute those services ahead of
time. My reply to Dimitris earlier today provided a road map to an error
prone design, as well as two different ways of accomplishing compliant
design. Given that GTS is responding to that thread, I’m surprised to see
it come up again so quickly, as it seems like GTS may not have understood?

Likewise, there is the question of how soon the revocation information must
> be produced and reachable by an interested party (e.g. someone who has
> never seen the certificate in question but still wants to know the status
> of that certificate). [Aside, Wayne, you specifically said relying parties
> earlier, did you intend to say interested party or relying party? We have
> some additional questions if relying party was actually intended, as using
> it in that context seems to redefine what a relying party is.]

I cannot see how it redefined relying party, as anyone who decides to trust
GTS becomes a relying party of GTS, and does not change anything.

The question of how soon has been mentioned earlier, but again is addressed
by earlier replies. We’ve seen the problems with CAs arguing CDN
distribution. There is no reasonable way that the relying party community
can or should accept the phased rollout delays as compliant, particularly
with a 24 hour revocation timeline (for example).

A common approach to this is to pregenerate responses for distribution,
with edge caches (5019-style) that can talk to an authoritative origin
(6960-style) under the hood. If a client queries for the status, the edge
cache serves it if it’s a cache hit, otherwise communicates back to the
origin and pulls into the cache. This is perhaps unsurprising, as it’s the
model many active CDNs use, functioning as it were as a reverse proxy with
caching (and the ability to globally evict from the cache).

Since the CA already needs to ensure that they can have a globally
consistent response distributed within 24-hours, and that any time spent
synchronizing is time that the CA itself cannot use to investigate/respond,
this design discourages CAs from multihour rollouts (and that’s a good
thing). If you can’t meet those timelines, then you’re setting yourself up
for a CA incident that other CAs will have designed around.

If you think through the logical consequences for relying parties, it’s
clear that there are approaches CAs can use that are harmful, and there are
approaches they can use that are helpful. As publicly trusted CAs, they are
expected to be beyond reproach, and make every decision with the relying
parties’ interests at heart: not the Subscriber’s, not the Applicant’s, not
the CA’s. Something about putting the user first, and the user here is
everyone that will trust a certificate from that CA.

This “reachable” part is particularly meaningful in that when using a CDN
> there are often phased roll outs that can take hours to complete. Today,
> the BRs leave this ambiguous, the only statement in this area is that new
> information must be published every four days:
>
> "The CA SHALL update information provided via an Online Certificate Status
> Protocol at least every four days. OCSP responses from this service MUST
> have a maximum expiration time of ten days."

It’s not ambiguous.

Read 4.9.1.1 and 7.1.2.3(c). You aren’t providing a responder if it can’t
answer for four days, and you aren’t meeting the revocation timeline if you
aren’t publishing revocation information in 24 hours.

The normal timeline:
- Upon issuance, the definitive response is available
- That definitive response is refreshed at least every four days
- While the BRs max is ten days, a reminder that Microsoft sets a minimum
of 8 hours, requires the maximum be 7 days, and new information available
at half that - e.g. 3.5 days
- The responder should maintain global consistency (e.g. if using RFC5019,
this is easier)

When revoking:
- That response should be globally available and published with 24 hours or
five days.

With this change, it would seem there needs to be a lower bound defined for
> how quickly the information needs to be available if it is to be an
> effective monitoring tool.

Again, it sounds like GTS hasn’t been following the thread or the updates,
which have clarified as to why the presumed gap (between precert and cert)
is irrelevant, and thus a lower bound not needed here. This only becomes an
issue if GTS is responding unknown for several hours after issuing certs -
but by that logic, GTS is not providing responders for several hours after
issuance, which is a BR violation today.

* Clarifications
>
> This in turn raises the question if CAs can re-use authorization data such
> as CAA records or domain authorizations from the precertificate?

It doesn’t, because the BRs answer this, if GTS reads them. Specifically,
3.2.2.8 answers this for CAA.

If a final certificate has not been issued due to a persistent quorum
> failure, and that failure persists longer than the validity of the used
> authorization data, can the authorizations that were done prior to the
> precertificate issuance be re-used?

It seems a responsible CA would answer “No”, and ensure that the validity
period of any information they use is good for (pre-cert issuance time +
time they’re willing to wait for SCTs). They would avoid this whole issue,
by avoiding trying to do the “least possible” and recognizing that they
have the flexibility to unambiguously avoid any compliance issues here.

As such, in our opinion, a roll out period to enable software and
> deployment changes to be made would be appropriate. Had this conversation
> taken place within the CA/Browser forum, the implementation date would have
> been discussed before becoming a formal requirement. We leave it to
> Browsers to determine reasonable timelines and we're not seeking to delay,
> simply recognition that many changes take time to implement and it is tough
> to effectively respond to changes that become new requirements in an
> instant.

This is entirely unproductive and unhelpful, because it talks around the
issue. This is the behaviour we the community largely see of problematic
CAs that don’t have user’s security first.

If you think there’s an issue with the date, a productive, useful
contribution, would be:
- Highlight when
- Highlight why

However, none of the discussion “should” be a functional change for any CA
following the rules. Even as a clarification of expectations, it’s trivial
to resolve and get into compliance, judging by the responses we’ve seen
from CAs to date.

I’m most encouraged, and most discouraged, that it seems even still today,
GTS is having trouble understanding what’s proposed, and seeing things that
simply aren’t there, rather than the things that are. Hopefully, the
clarifications to this thread, showing GTS has not followed the
conversation, do much to assuage the concerns that GTS is being asked to
implement major changes. The only major change I can see is it sounds like
GTS may have had other compliance issues with its responder services,
likely similarly based on misunderstanding the requirement as a publicly
trusted CA. As I said, that’s encouraging and discouraging.

I know that’s far more direct than Wayne would be, but any publicly trusted
CA that’s been following this Forum should recognize that GTS is following
a playbook used by CAs to push back on security improvements
unconstructively, as a stalling tactic that usually exists to hide or paper
over non-compliance, and then arguing the non-compliance was because of
something ambiguous, rather than thinking through the logical consequences
of their decisions.

This isn’t to say pushing back gets you branded as a poor CA; however, this
specific approach, still lacking in actionable data and misunderstanding
both Root Policy and the CA/B Forum, absolutely causes a crisis of
confidence in the CAs that do this, and for good reason, as time has born
out.

Browsers should set whatever requirements they believe are in the best
> interest of their users, but the more requirements are split across
> multiple root program's requirements, the CA/Browser Forum and IETF, the
> harder it becomes to reason about what a correct behavior is. Given the
> historical precedent of rule making in CA/Browser forum and the fact that
> it covers all participants, it seems like the ideal body to ensure
> consistency within the ecosystem.

This is ahistorical. The historic precedent is and has been root program
requirements, especially with respect to matters like the topic at hand,
eventually flowing into the BRs.

That a CA would suggest that the CA/B Forum is a better place for
discussing this than here deeply saddens me, precisely because of the
intentional exclusion of a number of people from the Forum that have made
incredibly valuable and worthwhile contributions. Honestly, I suppose I had
expected GTS to value the openness and transparency this provides over the
Forum.

It is true that CAs bear the responsibility of following the rules of the
root programs they are in, and that can be complex if those requirements
aren’t centrally codified. A trivial solution exists for this, but which
CAs rarely avail themselves of: they can draft text (if they aren’t voting
members) or prepare and sponsor ballots (if they are) to incorporate the
root program requirements into text. For example, I continue to remain
shocked that no CA has thought to do so with Microsoft’s OCSP requirements,
or both Microsoft and Mozilla’s EKU requirements.

However, since this neither changes the expectations in the BRs nor
requires anything new of CAs, and merely explains the logical consequences
of RFC5019/6960 to those who may struggle with it, it does not seem to at
all raise to the level suggested here.

[Ryan Sleevi]

On Tue, Sep 24, 2019 at 2:36 AM Clint Wilson <cl...@wilsonovi.com> wrote:

> On Mon, Sep 23, 2019 at 6:29 PM Ryan Sleevi via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> Yup. And it’s been repeatedly acknowledged that is perfectly fine. The
>> proposed language further considers that, but emphasizes that by producing
>> and logging the precertificate, then regardless of the issue, the CA
>> should
>> be prepared to provision services for it for the duration.
>>
>> If you find yourself continually generating precertificates, that suggests
>> an operational/design issue, which you can remediate based on which is
>> cheaper for you: fixing the pipeline to be reliable (as many reliability
>> issues seen, to date, have been on the CA side) or continue to provision
>> services when things go bad. Either works, you can choose.
>>
>> The important part is you need to treat (pre-cert || cert) in scope for
>> all
>> your activities. You must be capable of revoking. You must be capable of
>> searching your databases. You must be capable of validating.
>>
>

> Agreed especially with the final paragraph here.
> Apologies if this is too tangential, but one potential change I see coming
> out of this discussion is around CT Log "outages". That is, separate from
> the misconfiguration issues we've seen, one other instance where sometimes
> pre-certificates are generated without an associated certificate is when CT
> logs necessary for meeting a browser CT policy aren't available (as Andy
> points out). Even if for very brief windows, today we occasionally see
> windows where quite a few pre-certs can be generated but final certificate
> issuance abandoned due to lack of SCTs (which is purely an implementation
> choice as to when to abandon retries, I think).
>

Right. I think that's the substance of it. It's unclear to me what the
benefit is of abandoning versus retrying later. I suspect it's a question
of what the CA's window would be for (validation + SCTs), and if it's
easier to kick it back into a validation flow if the SCT window elapses.
Does that guess sound right?


> Thinking through this discussion, it seems like one useful change for us
> here may be to issue those final certs without the SCTs rather than
> abandoning the pre-cert as we do today. We'd obviously still need to
> re-attempt issuance of another cert with the SCT list (as that's what a
> vast majority of customers expect), but reducing the number of orphaned
> pre-certs seems like a reasonably good thing, even if inconsequential for
> how we interact with the (pre-cert || cert). Does that seem like a
> reasonable change in process to make?
>

It's not clear to me why this would be good or desirable? It doesn't seem
to benefit the client/relying party ecosystem any. And it seems like it'd
be more work for the CA to do.

Perhaps I'm just not familiar with the set of CA problems it would solve?
Could you help me out?

[Clint Wilson]

On Mon, Sep 23, 2019 at 6:29 PM Ryan Sleevi via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Yup. And it’s been repeatedly acknowledged that is perfectly fine. The
> proposed language further considers that, but emphasizes that by producing
> and logging the precertificate, then regardless of the issue, the CA should
> be prepared to provision services for it for the duration.
>
> If you find yourself continually generating precertificates, that suggests
> an operational/design issue, which you can remediate based on which is
> cheaper for you: fixing the pipeline to be reliable (as many reliability
> issues seen, to date, have been on the CA side) or continue to provision
> services when things go bad. Either works, you can choose.
>
> The important part is you need to treat (pre-cert || cert) in scope for all
> your activities. You must be capable of revoking. You must be capable of
> searching your databases. You must be capable of validating.
>

Agreed especially with the final paragraph here.
Apologies if this is too tangential, but one potential change I see coming
out of this discussion is around CT Log "outages". That is, separate from
the misconfiguration issues we've seen, one other instance where sometimes
pre-certificates are generated without an associated certificate is when CT
logs necessary for meeting a browser CT policy aren't available (as Andy
points out). Even if for very brief windows, today we occasionally see
windows where quite a few pre-certs can be generated but final certificate
issuance abandoned due to lack of SCTs (which is purely an implementation
choice as to when to abandon retries, I think).

Thinking through this discussion, it seems like one useful change for us
here may be to issue those final certs without the SCTs rather than
abandoning the pre-cert as we do today. We'd obviously still need to
re-attempt issuance of another cert with the SCT list (as that's what a
vast majority of customers expect), but reducing the number of orphaned
pre-certs seems like a reasonably good thing, even if inconsequential for
how we interact with the (pre-cert || cert). Does that seem like a
reasonable change in process to make?


>

[Erwann Abalea]

Bonjour,

Le vendredi 20 septembre 2019 22:20:02 UTC+2, Curt Spann a écrit :
[...]

> My interpretation is a “revoked” OCSP response should be used in the following conditions:

[...]

> 2. When the OCSP request contains an issuerNameHash and issuerKeyHash for which the OCSP responder IS authoritative and the CA corresponding to the issuerNameHash and issuerKeyHash has been revoked.

A CA is not revoked, only certificates are. A CA can have several certificates, all sharing the same subject name while public keys may be identical or different, chaining to identical or different Trust Anchors, and some of the certificates issued to the CA might have been revoked while others are still valid. Returning a revoked answer whenever a CA certificate is revoked regardless of the status of all the other certificates is not going to work.

RFC6960 includes some provisions in clause 2.7 regarding CA key compromise, and in such condition, the OCSP responder MAY return a revoked status.

[Clint Wilson]

On Tue, Sep 24, 2019 at 5:06 AM Ryan Sleevi <ry...@sleevi.com> wrote:

>
>
> On Tue, Sep 24, 2019 at 2:36 AM Clint Wilson <cl...@wilsonovi.com> wrote:
>
>> On Mon, Sep 23, 2019 at 6:29 PM Ryan Sleevi via dev-security-policy <
>> dev-secur...@lists.mozilla.org> wrote:
>>
>> Agreed especially with the final paragraph here.
>> Apologies if this is too tangential, but one potential change I see
>> coming out of this discussion is around CT Log "outages". That is, separate
>> from the misconfiguration issues we've seen, one other instance where
>> sometimes pre-certificates are generated without an associated certificate
>> is when CT logs necessary for meeting a browser CT policy aren't available
>> (as Andy points out). Even if for very brief windows, today we occasionally
>> see windows where quite a few pre-certs can be generated but final
>> certificate issuance abandoned due to lack of SCTs (which is purely an
>> implementation choice as to when to abandon retries, I think).
>>
>

> Right. I think that's the substance of it. It's unclear to me what the
> benefit is of abandoning versus retrying later. I suspect it's a question
> of what the CA's window would be for (validation + SCTs), and if it's
> easier to kick it back into a validation flow if the SCT window elapses.
> Does that guess sound right?
>

Yeah, that's exactly right. That's also partially because we don't cache
CAA for 8 hours, so we could instead widen the window of retries as well.

>
>
>> Thinking through this discussion, it seems like one useful change for us
>> here may be to issue those final certs without the SCTs rather than
>> abandoning the pre-cert as we do today. We'd obviously still need to
>> re-attempt issuance of another cert with the SCT list (as that's what a
>> vast majority of customers expect), but reducing the number of orphaned
>> pre-certs seems like a reasonably good thing, even if inconsequential for
>> how we interact with the (pre-cert || cert). Does that seem like a
>> reasonable change in process to make?
>>
>

> It's not clear to me why this would be good or desirable? It doesn't seem
> to benefit the client/relying party ecosystem any. And it seems like it'd
> be more work for the CA to do.
>
> Perhaps I'm just not familiar with the set of CA problems it would solve?
> Could you help me out?
>

So I'm not totally confident that it is good or desirable, but my thought
was more along the lines of cognitive benefits than operational. It's
apparently somewhat difficult to grok that "cert" interactions need to
apply to pre-certs, so if CAs moved away from abandoning pre-certs
(wherever possible), then a lot of the behavior changes discussed here
would happen automatically. That is, we have to put in a fix for ensuring
services are available either way for (pre-certs || certs), but if there is
more reliably (pre-cert && cert) available then the services are (from what
I can see) already available for CAs. Maybe that's a change that can occur
ahead of patches for the misconfiguration issues.
Since all of that's relatively short-term benefits, I'm probably not
approaching this the best way, but that was the thought.

[Neil Dunbar]

> On 24 Sep 2019, at 07:35, Clint Wilson via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
>
> […] it seems like one useful change for us

> here may be to issue those final certs without the SCTs rather than
> abandoning the pre-cert as we do today. We'd obviously still need to
> re-attempt issuance of another cert with the SCT list (as that's what a
> vast majority of customers expect), but reducing the number of orphaned
> pre-certs seems like a reasonably good thing, even if inconsequential for
> how we interact with the (pre-cert || cert).

Perhaps I’m misunderstanding, but wouldn’t the generation of a set of certificates (at least two in that set - one with SCTs embedded, and one without) end up with several certificates signed by the same Issuing CA, but with identical serial numbers? This would violate RFC 5280 Section 4.1.2.2. For publicly trusted CAs, a (pre-cert, cert) pair does not violate that condition by virtue of BR Section 7.1.2.5. Combining the two documents, it would seem that the number of certificates following a pre-certificate issuance is strictly limited to one.

Again - I may have misunderstood: apologies if this is the case - corrections welcome.

Regards,

Neil

[Clint Wilson]

Sorry, I think the misunderstanding is my fault. You're correct if the same
pre-cert was used for two subsequent leaf signings.
What I meant was where now we would abandon retrying signing of the leaf
due to failure in retrieval of the SCTs, we would instead sign the leaf
without SCTs, then start the entire process over again once CT logs were
available (new tbsCert, new pre-cert, new leaf).
So same subject/sAN contents, but not the same serial number.

Cheers!
Clint

[Wayne Thayer]

I've initiated a CAB Forum ballot [1] to resolve the inconsistency that Rob
identified.

I also want to acknowledge the feedback from Google on the timing of this.
I can appreciate the framing of this as a new policy that's been added
without due process, but I view this as a clarification of existing
requirements. Some CAs have already been held accountable for this
requirement [2] and some that have been paying close attention adhere to
it. Others were struggling to determine what to do. Under these
circumstances, it made no sense to me to roll back the policy, so the only
reasonable course was to clarify it in favor of the consensus that emerged
from this thread.

I'm still open to making changes to our "required practice" on
precertificates, but having caught up on the thread I don't think any
further changes are necessary.

- Wayne

[1] https://cabforum.org/pipermail/servercert-wg/2019-September/001111.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390
[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/PYIAoh6W6x0/R0gr1d6wBQAJ

On Wed, Sep 25, 2019 at 3:59 AM Clint Wilson via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
>

[Rob Stradling]

On 01/10/2019 00:45, Wayne Thayer via dev-security-policy wrote:
> I've initiated a CAB Forum ballot [1] to resolve the inconsistency that Rob
> identified.

Thanks Wayne. I've offered to endorse.

> I also want to acknowledge the feedback from Google on the timing of this.
> I can appreciate the framing of this as a new policy that's been added
> without due process, but I view this as a clarification of existing
> requirements.

I view [4] as new policy that's been added without due process. I would
have preferred to see your CABForum ballot [1] resolve this in the BRs
first, so that CAs weren't faced with conflicting requirements.

> Some CAs have already been held accountable for this requirement [2]
> and some that have been paying close attention adhere to
> it. Others were struggling to determine what to do. Under these
> circumstances, it made no sense to me to roll back the policy, so the only
> reasonable course was to clarify it in favor of the consensus that emerged
> from this thread.

Some CAs (including Sectigo, as I mentioned in an earlier message) are
currently compliant with (quoting you [1])...
"During a lengthy discussion on the mozilla.dev.security.policy forum,
it was discovered that BR section 4.9.10 combined with BR
section 7.1.2.5 prevents a CA from responding “good” for a
precertificate." [1]

...but are not compliant with [4].

If/when your CABForum ballot [1] passes and (after the IPR period) takes
effect, it will become possible for CAs to comply with [4] without
falling out of compliance with the root program policies of Apple,
Microsoft, etc, which incorporate the BRs but don't have a BR policy
override equivalent to [4]). Until then, what does Mozilla expect CAs
to do?

> I'm still open to making changes to our "required practice" on
> precertificates, but having caught up on the thread I don't think any
> further changes are necessary.

I propose that you update [4] to say that Mozilla won't treat
non-compliance with [4] as an "incident" whilst it remains the case that
the BRs are inconsistent with [4].

> - Wayne
>
> [1] https://cabforum.org/pipermail/servercert-wg/2019-September/001111.html
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390
> [3]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/PYIAoh6W6x0/R0gr1d6wBQAJ

[4]
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates

--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

[Wayne Thayer]

On Tue, Oct 1, 2019 at 3:34 AM Rob Stradling <r...@sectigo.com> wrote:

>
> I propose that you update [4] to say that Mozilla won't treat
> non-compliance with [4] as an "incident" whilst it remains the case that
> the BRs are inconsistent with [4].
>
>

I could simply move [4] to a "recommended practice" (SHOULD) until the
ballot comes into force, then move it back to "required". That implies that
the bugs which have been opened for this specific issue (responding
"unknown" - not to be confused with "returns 1 byte") will be closed as
INVALID.

Are there strong objections to this course of action?

- Wayne

[4]
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates

[Rob Stradling]

On 02/10/2019 00:51, Wayne Thayer wrote:

> On Tue, Oct 1, 2019 at 3:34 AM Rob Stradling wrote:
>
> I propose that you update [4] to say that Mozilla won't treat
> non-compliance with [4] as an "incident" whilst it remains the case
> that the BRs are inconsistent with [4].
>
> I could simply move [4] to a "recommended practice" (SHOULD) until the
> ballot comes into force, then move it back to "required". That implies
> that the bugs which have been opened for this specific issue (responding
> "unknown" - not to be confused with "returns 1 byte") will be closed as
> INVALID.
>
> Are there strong objections to this course of action?

It seems a bit strange to recommend a practice that CAs cannot currently
adhere to without violating the BRs and some other root programs'
policies, but at the same time it is helpful to signpost upcoming policy
changes.

I don't object strongly.

> - Wayne
>
> [4]
> https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates

[Wayne Thayer]

I've gone ahead and moved [4] to the "Recommended Practices" section.

The ballot to modify the BRs is now in the formal discussion period leading
up to a vote [5].

I'll be resolving the existing compliance bugs on this issue as INVALID.
I'd like to thank the CAs that proactively submitted incident reports
rather than taking a "wait and see" approach. That degree of transparency
is both appreciated and encouraged.

- Wayne

[5] https://cabforum.org/pipermail/servercert-wg/2019-October/001145.html

[Andrew Ayer]

On Tue, 1 Oct 2019 16:51:34 -0700
Wayne Thayer via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> I could simply move [4] to a "recommended practice" (SHOULD) until the
> ballot comes into force, then move it back to "required".

Since Ballot SC23 has come into force, can we now move
https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates
back to the Required section?

Regards,
Andrew