Re: DigiCert OCSP services returns 1 byte

[Curt Spann via dev-security-policy]

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

On Fri, Sep 20, 2019 at 4:20 PM Curt Spann via dev-security-policy <
dev-security-policy@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 

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Andy Warner via dev-security-policy]

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

On Friday, September 20, 2019 at 1:20:02 PM UTC-7, Curt Spann 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.
> 
> 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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Curt Spann via dev-security-policy]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Wayne Thayer via dev-security-policy]

On Fri, Sep 20, 2019 at 4:56 AM Dimitris Zacharopoulos 
wrote:

> 
>
> 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?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Ryan Sleevi via dev-security-policy]

On Fri, Sep 20, 2019 at 9:58 AM Rob Stradling  wrote:

> On 19/09/2019 21:01, Ryan Sleevi wrote:
> 
> > 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?
>

I've replied there as to why I think it belongs here, and is inappropriate
for there.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Rob Stradling via dev-security-policy]

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

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

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Rob Stradling via dev-security-policy]

On 16/09/2019 18:08, Andrew Ayer wrote:
> On Fri, 13 Sep 2019 08:22:21 +
> Rob Stradling via dev-security-policy
>  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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert OCSP services returns 1 byte

[Dimitris Zacharopoulos via dev-security-policy]

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