Section 4.9.10: Untangle "assigned" vs "reserved" serials, precertificates, and OCSP

[aarongable]

The Profiles ballot updates Section 7.1.2.9 to say:

Once a Precertificate is signed, relying parties are permitted to treat this as a binding committment from the CA of the intent to issue a corresponding Certificate, or more commonly, that a corresponding Certificate exists.

This language is, to my understanding, just a reification of the common position that has been taken by root programs for a number of years now. For example, the MRSP says:

The logging of a precertificate in a Certificate Transparency log is considered by Mozilla to be a binding intent to issue a final certificate[.]

There is a slight difference between the current Mozilla policy and the proposed Profiles language: Mozilla says that "logging to CT" is a binding intent to issue, while the Profiles ballot says that just "signing" is a binding intent to issue. To be honest, I prefer the new language, but it introduces some weirdness regarding OCSP.

Section 4.9.10 of the BRs says:

A certificate serial number within an OCSP request is...

• "assigned" if a Certificate with that serial number has been issued by the Issuing CA
• "reserved" if a Precertificate [RFC6962] with that serial number has been issued[...].

It also says:

The OCSP responder MAY provide definitive responses about "reserved" certificate serial numbers, as if there was a corresponding Certificate that matches the Precertificate [RFC6962].

But if, as the Profiles ballot text says, a "Precertificate is... a binding commitment... that a corresponding Certificate exists", then there's no actual difference between "reserved" and "assigned". All serials which are "reserved" may be treated by relying parties as actually "assigned", and therefore the OCSP responder MUST provide a definitive response for them.

This isn't a huge deal: as noted above, the new Profiles language largely just carries forward existing Mozilla language, so most publicly trusted CAs are already in this state today. But I think it would be worthwhile to clean up Section 4.9.10 to only list two categories of serials, to make the requirements clearer.

[timfromdigicert]

I think you erred by omitting “of the intent to issue” using ellipses. Doing so completely changes the meaning of the sentence. It is not true that a “Precertificate is a binding commitment that a corresponding certificate exists”, because it may simply indicate an intent to issue. Most certificates go through a time period where they have been CT logged but have not yet been issued. During this phase, there is a binding commitment of the intent to issue, but no corresponding Certificate exists (yet).

-Tim

From: Aaron Gable @.> Sent: Wednesday, February 15, 2023 4:09 PM To: cabforum/servercert @.> Cc: Subscribed @.***> Subject: [cabforum/servercert] Section 4.9.10: Untangle "assigned" vs "reserved" serials, precertificates, and OCSP (Issue #422)

The Profiles ballot updates Section 7.1.2.9https://github.com/cabforum/servercert/blob/profiles/docs/BR.md#7129-precertificate-profile to say:

Once a Precertificate is signed, relying parties are permitted to treat this as a binding committment from the CA of the intent to issue a corresponding Certificate, or more commonly, that a corresponding Certificate exists.

This language is, to my understanding, just a reification of the common position that has been taken by root programs for a number of years now. For example, the MRSP says:

The logging of a precertificate in a Certificate Transparency log is considered by Mozilla to be a binding intent to issue a final certificate[.]

There is a slight difference between the current Mozilla policy and the proposed Profiles language: Mozilla says that "logging to CT" is a binding intent to issue, while the Profiles ballot says that just "signing" is a binding intent to issue. To be honest, I prefer the new language, but it introduces some weirdness regarding OCSP.

Section 4.9.10https://github.com/cabforum/servercert/blob/2c63814/docs/BR.md#4910-on-line-revocation-checking-requirements of the BRs says:

A certificate serial number within an OCSP request is...

• "assigned" if a Certificate with that serial number has been issued by the Issuing CA
• "reserved" if a Precertificate [RFC6962] with that serial number has been issued[...].

It also says:

The OCSP responder MAY provide definitive responses about "reserved" certificate serial numbers, as if there was a corresponding Certificate that matches the Precertificate [RFC6962].

But if, as the Profiles ballot text says, a "Precertificate is... a binding commitment... that a corresponding Certificate exists", then there's no actual difference between "reserved" and "assigned". All serials which are "reserved" may be treated by relying parties as actually "assigned", and therefore the OCSP responder MUST provide a definitive response for them.

This isn't a huge deal: as noted above, the new Profiles language largely just carries forward existing Mozilla language, so most publicly trusted CAs are already in this state today. But I think it would be worthwhile to clean up Section 4.9.10 to only list two categories of serials, to make the requirements clearer.

— Reply to this email directly, view it on GitHubhttps://github.com/cabforum/servercert/issues/422, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIFREHHE4CONMGG2K3CVK7LWXVAVJANCNFSM6AAAAAAU5K6QJ4. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[aarongable]

I only elided that text near the end. The beginning of the issue contains the full quotation, which is:

Once a Precertificate is signed, relying parties are permitted to treat this as a binding committment from the CA of the intent to issue a corresponding Certificate, or more commonly, that a corresponding Certificate exists.

This parses as "relying parties are permitted to treat this as a binding commitment from the CA (of the intent to issue a corresponding Certificate), (or more commonly), (that a corresponding Certificate exists". Both "binding commitment from the CA of the intent to issue a corresponding Certificate" and "binding commitment from the CA that a corresponding Certificate exists" are valid parsings of the conjunctive clause.

More importantly, there's a second quote in the same section:

The existence of a signed Precertificate can be treated as evidence of a corresponding Certificate also existing, as the signature represents a binding committment by the CA that it may issue such a Certificate.

This makes it clear to me that, from an outside perspective, there's no difference between a Precertificate existing and a Certificate existing.

[timfromdigicert]

Yeah, but the outside perspective isn’t the only one that matters. These requirements are also consumed by auditors, for example, who may be trying to align these requirements with internal audit logs.

I would be very hesitant to try to simplify away the difference between a Precertificate existing and a Certificate existing. I just have a hunch that it is going to cause a problem somewhere and that there’s really not much tangible benefit.

-Tim

From: Aaron Gable @.> Sent: Wednesday, February 15, 2023 4:26 PM To: cabforum/servercert @.> Cc: Tim Hollebeek @.>; Comment @.> Subject: Re: [cabforum/servercert] Section 4.9.10: Untangle "assigned" vs "reserved" serials, precertificates, and OCSP (Issue #422)

I only elided that text near the end. The beginning of the issue contains the full quotation, which is:

Once a Precertificate is signed, relying parties are permitted to treat this as a binding committment from the CA of the intent to issue a corresponding Certificate, or more commonly, that a corresponding Certificate exists.

This parses as "relying parties are permitted to treat this as a binding commitment from the CA (of the intent to issue a corresponding Certificate), (or more commonly), (that a corresponding Certificate exists". Both "binding commitment from the CA of the intent to issue a corresponding Certificate" and "binding commitment from the CA that a corresponding Certificate exists" are valid parsings of the conjunctive clause.

More importantly, there's a second quote in the same section:

The existence of a signed Precertificate can be treated as evidence of a corresponding Certificate also existing, as the signature represents a binding committment by the CA that it may issue such a Certificate.

This makes it clear to me that, from an outside perspective, there's no difference between a Precertificate existing and a Certificate existing.

— Reply to this email directly, view it on GitHubhttps://github.com/cabforum/servercert/issues/422#issuecomment-1432054782, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AIFREHBKHW3B7YMEO2AZ2EDWXVCWVANCNFSM6AAAAAAU5K6QJ4. You are receiving this because you commented.Message ID: @.***>

[robstradling]

I agree with @timfromdigicert that the different perspectives matter. IMHO, "binding commitment...that a corresponding Certificate exists" is just plain wrong and will cause problems. There's a difference between "binding commitment" and the RFC6962 language of "binding intent".

Inside perspective: Issuance of a Precertificate is only a binding intent to issue the corresponding Certificate. It's not a promise or guarantee that the corresponding Certificate will ever be issued.

We are occasionally asked to revoke a Precertificate before our CA system has had time to issue the corresponding Certificate. In such cases we never actually issue the corresponding Certificate, even though our very recent intent had been to issue it. This behaviour is compliant with the rules as I understand them, and I would even argue that it's the best practice in this particular scenario.

Outside perspective: The existence of a Precertificate means that the BRs and browser policies assume that the corresponding Certificate exists, and enforcement of those policies occurs on that basis. This is true regardless of whether or not the corresponding Certificate actually exists (yet or ever), and it's also true even when the CA explicitly claims that they have not issued the corresponding Certificate.

[timfromdigicert]

Right, exactly. My recollection is that the entire reason revocation of pre-certificates exists is to indicate that a particular pre-certificate was part of a flawed issuance process, and the corresponding certificate may not exist. And this language in the BRs was added to allow OCSP servers to respond about the status of such pre-certificates, even though the relevant RFCs would otherwise preclude them from doing so, because no such certificate exists.

[barrini]

Move to the Definitions&Glosary WG. Tim to move it there.

[aarongable]

While I understand the impetus behind this split-horizon internal/external interpretation that you are putting forward, I don't understand the practical effect.

Again, the BRs say:

The existence of a signed Precertificate can be treated as evidence of a corresponding Certificate also existing.

The root programs, and the rest of the community, all share the external perspective. As far as they can tell, if a precertificate exists, then the corresponding certificate exists as well. And if the corresponding certificate exists, then the serial number is Assigned, not just Reserved. And since the serial number is Assigned, then OCSP responders MUST provide a definitive response.

There is no point to allow the carve-out for Reserved serials, because Reserved serials don't exist: all precertificates are evidence that a corresponding certificate also exists, so all precertificate serial numbers have evidence that they are Assigned.

[CBonnell]

The existence of a signed Precertificate can be treated as evidence of a corresponding Certificate also existing.

That language in the certificate profile section of the BRs is describing a natural consequence of the "intent to issue" language in RFC 6962. It's difficult to extrapolate it as a normative requirement or allowance for OCSP responder behavior.

[aarongable]

It's difficult to extrapolate it as a normative requirement or allowance for OCSP responder behavior.

Apologies, but I truly don't understand what you mean by this.

Suppose that a CA issues a precertificate, logs it to CT, and then something goes wrong with the issuance of the final certificate and their issuance process stops. The CA considers the serial number Reserved, and therefore doesn't provide an OCSP response for that serial, since the BRs only say they MAY provide one, and therefore they also MAY not. Then a community member sees the precertificate, assumes the existence of a corresponding final certificate, queries OCSP for that final certificate, and gets an "UNKNOWN" response.

How is that community member supposed to interpret that? Are they supposed to take the CA's word that the corresponding certificate was never issued? The rest of the requirements don't work that way -- the whole point of the "intent to issue" is that we have to assume that the final certificate does actually exist.

What if the issuance failure was between the HSM and the database, and the final certificate was issued but was never logged or saved?

OCSP requests only encode a serial number, not a fingerprint of the whole certificate. There is no distinction between an OCSP request for a precertificate or its corresponding final certificate; those are the same request. As far as the rest of the world is concerned, the CA is serving a non-definitive OCSP response for a final certificate. That's a violation of the BRs (and the Mozilla Root Store Policy), full stop.

The fact that the CA thinks they're complying with this "Reserved serial" MAY clause does not change the fact that they're failing to comply with other, stricter clauses. That's why we need to remove this carve-out, to prevent further confusion.

[CBonnell]

How is that community member supposed to interpret that? Are they supposed to take the CA's word that the corresponding certificate was never issued? The rest of the requirements don't work that way -- the whole point of the "intent to issue" is that we have to assume that the final certificate does actually exist.

Ok, based on your comment above, I think that with this issue you're looking to change the "MAY" in "The OCSP responder MAY provide definitive responses about "reserved" certificate serial numbers, as if there was a corresponding Certificate that matches the Precertificate [RFC6962]." to a "MUST", and not merely looking to clean up the language (which is what I thought this issue was originally accomplishing to do).

Is that correct?

[aarongable]

My preferred solution would be to remove the definition of "reserved", and change the definition of "assigned" to include serials that have been used in precertificates. This would have the same effect as what you describe, but would accomplish it in what I believe to be a cleaner manner.

[CBonnell]

My preferred solution would be to remove the definition of "reserved", and change the definition of "assigned" to include serials that have been used in precertificates. This would have the same effect as what you describe, but would accomplish it in what I believe to be a cleaner manner.

That's probably cleaner, but it is a normative change from what is in the BRs today. I'm certainly not opposed to this change due to the benefits of consistency of OCSP responses for relying parties, but I do think it needs to be clearly communicated that it is a normative requirements change for the BRs, otherwise it will catch some by surprise.

The fact that the CA thinks they're complying with this "Reserved serial" MAY clause does not change the fact that they're failing to comply with other, stricter clauses.

A CA trusted only by Microsoft, for example, would not be running afoul of any requirements as written today. With the change you're proposing, they would be.

[aarongable]

I disagree with that assessment -- I believe that the fact that precertificates are evidence that a final certificate exists means that all precertificate serials are already "assigned", and that the set of "reserved" serials is in fact the empty set and this is dead/dangling language. But I have no issues treating this as though it were a normative change with an effective date and everything to give all CAs time to ensure they comply.

[XolphinMartijn]

I do wonder though, rather having a MAY on "reserved" for a Precertificate (which I agree does not make sense (anymore)), should "reserved" be allowed for a serialNumber included in a tbsCertificate?

[jollyjustify]

Aaron, Tim,

I can’t help wondering, what if a Certificate corresponding to its pre-certificate is never issued, even after the pre-certificate already expired, and obviously in this case the binding commitment of the intent to issue was not fulfilled, do you believe this should be considered as a policy violation, at least with respect to the Mozilla policy?

[aarongable]

No, failing to issue the corresponding certificate is not and should not be a policy violation. CAs have the right to not issue for any reason they like; the BRs are and should be only concerned with what they do issue.

The problem is not whether or not the corresponding certificate was ever issued. The problem is whether or not an outside observer can be confident that the corresponding certificate was never issued. Once a precertificate exists, outside observers are allowed to assume that the rest of the issuance process completed and that a corresponding certificate exists, even if they've never seen it.