[Servercert-wg] Ballot SC23: Precertificates

[Mike Reilly (GRC)]

Thanks Ryan for the quick response.  Wayne and ballot endorsers (Jeremy and Rob):  We (Microsoft) are continuing to discuss how a pre-cert is nearly treated like a cert and it still feels like we’ll have a disconnect between the BRs and root program requirements with this ballot language.  I’ve added Rashmi to this mail who can add more depth to the discussion than I can in the hopes of improving the ballot language and intent we’re all trying to achieve.  Thanks, Mike

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Thursday, October 10, 2019 12:35 PM
To: Mike Reilly (GRC) via Servercert-wg <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Ballot SC23: Precertificates



On Thu, Oct 10, 2019 at 3:16 PM Mike Reilly (GRC) via Servercert-wg <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>> wrote:
Wayne and SCWG folks.  I’ve read the threads on this ballot.  I have two questions for clarification:


  1.  Reading the proposed update to section 4.9.10 of the Baseline Requirements which states ”If the OCSP responder receives an OCSP request but has no record of ever having issued any certificate with the certificate serial number in that request, using any current or previous issuing key for the CA subject, then the responder SHOULD NOT respond with a "good" status. OCSP responders for CAs that are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "good" status for such certificates. The CA SHOULD monitor the responder for such requests as part of its security response procedures.”  Are we are stating that a CA must (e.g. shall) be able to provide an OCSP response for a pre-certificate even if there is no corresponding issues certificate?  Is this basically stating that 4.9.10 requires the CA to provide the OCSP service (e.g. ability to provide a response) for pre-certificates even if there is no corresponding issued certificate?  I understand that if there is both the precert and issued cert then OSCP is required.
I don't believe this is intended to place a SHALL requirement within the BRs.

This provides a MAY allowance, which Root Programs can then impose a SHALL upon, in terms of what constitutes a record of having issued. The language here was chosen to mirror the relevant RFCs.

The concern that was raised was that a browser [Mike Reilly change of “CA” to “Browser” here based on Ryan’s later email correction ] Browser placing a SHALL requirement, in their Program, can result in a CA interpreting the Root Program to imposing something prohibited in the BRs. While there are other interpretations that do not result in a conflict, this ballot hopefully removes any ambiguity by removing the possibility of potential conflict. A CA MAY provide OCSP services for the serial number associated with a precertificate, despite there being no equivalent certificate issued, by treating the precertificate as a "record of having issued any certificate with the certificate serial number". Similarly, a Root Program MAY require that CAs in their program MUST provide OCSP services for serial numbers associated with precertificates as if the final certificate had been issued.


  1.  Also, current BR section “7.1.2.5 Application of RFC 5280” 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.”  With the removal of that language from the new BR section 7.1.2.5 does this mean that a precert with no corresponding cert is not defined as a certificate and then does not require to have an OCSP service?
This goes back to the Ballot 134 discussion, and whether or not a Precertificate is a Certificate or not, or if it's something different, in the way that, say, a CRL, OCSP, and Certificate all use the SIGNED{} syntax of RFC 5912, but are different. For what it's worth, RFC 6962-bis avoids this issue entirely; this is only something relevant to RFC 6962.

If the view is that a Precertificate is not-a-Certificate, then this imposes no new requirements. Root Programs then dictate what the not-a-Certificate is expected to look like (e.g. that the not-a-Certificate is proof of an equivalent Certificate, which may then not comply with Root Program requirements)

If the view is that a Precertificate is-a Certificate, merely with an additional critical poison OID, which was part of the concern when Ballot 134 was adopted, then this permits for duplicate serials - but only duplicate serials, and only if it aligns with RFC 6962. The current language, as predicted during the Ballot 134 discussion, have lead to conclusions such as the issuance of a pre-certificate need not conform to the BRs' profile at all, which is misaligned with Root Program expectations, if the Root Program treats the existence of a Precertificate as proof of an equivalent certificate potentially existing.


That's the "intent" part. If there are gaps you see, such as seeing it as REQUIRING the provision of services, and that would be a concern, then I think it's reasonable to try and find language to better capture that the CA MAY, and leave it to Root Programs MUST. This would be much like we do today with Mozilla/Microsoft requiring particular Audit Report disclosures, or Microsoft requiring a stricter profile of OCSP than the BRs require.

This is why it makes it easier to avoid a phase in (from the BRs perspective) - the BRs only need to make it clear it's permissible, and to address the interpretation that would suggest a conflict, and then Root Programs can decide when and how to phase in that requirement for their participating members.

[Mike Reilly add below with Ballot details]
Ballot SC23: Precertificates

Purpose of Ballot:

This ballot intends to clarify requirements placed on precertificates in BR section 7.1.2.5.

During a lengthy discussion on the mozilla.dev.security.policy forum [1], 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. This is a problem because there is no guarantee that a certificate corresponding to a precertificate has not been issued, resulting in root store policies such as [2] that require CAs to treat the existence of a precertificate as a presumption that a corresponding certificate has been issued and thus that a valid OCSP response is required.

This ballot intends to resolve the problem by reducing the scope of section 7.1.2.5. This section was originally [3] intended only to address duplicate serial numbers that would violate RFC 5280 section 4.1.2.2. In addition, this ballot removes legacy effective dates from BR section 4.9.10.

[1] https://groups.google.com/d/msg/mozilla.dev.security.policy/LC_y8yPDI9Q/NbOmVB77AQAJ<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsg%2Fmozilla.dev.security.policy%2FLC_y8yPDI9Q%2FNbOmVB77AQAJ&data=02%7C01%7CMike.reilly%40microsoft.com%7Cda8d31be310d41aca8c308d748274ed5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637057205980121304&sdata=YsxKzW25uUt76F326BjT4RnCkRr9iDViTUXc0qHiDC8%3D&reserved=0>
[2] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.mozilla.org%2FCA%2FRequired_or_Recommended_Practices%23Precertificates&data=02%7C01%7CMike.reilly%40microsoft.com%7Cda8d31be310d41aca8c308d748274ed5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637057205980131303&sdata=AEzghuLnZQ98oe1TeDeWb8mnNbt3xlCOHNhcNEfvJPQ%3D&reserved=0>
[3] https://cabforum.org/pipermail/public/2014-January/002694.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum.org%2Fpipermail%2Fpublic%2F2014-January%2F002694.html&data=02%7C01%7CMike.reilly%40microsoft.com%7Cda8d31be310d41aca8c308d748274ed5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637057205980131303&sdata=jcpSkpLXVywgSYZMiCtxDOC2oHzgJqdNJafLq5uQ92E%3D&reserved=0>

The following motion has been proposed by Wayne Thayer of Mozilla and endorsed by Jeremy Rowley of DigiCert and Rob Stradling of Sectigo.

-- MOTION BEGINS --

This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” as follows, based on Version 1.6.6:

REPLACE section 7.1.2.5 of the Baseline Requirements in its entirety with:

7.1.2.5 Application of RFC 5280

For purposes of clarification, any Precertificate MAY have the same serial number as exactly one certificate that is not a Precertificate, provided that the two are related as described in RFC 6962 - Certificate Transparency. This is a modification of the uniqueness requirements of RFC 5280  - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile section 4.1.2.2 under these Baseline Requirements.

REPLACE section 4.9.10 of the Baseline Requirements in its entirety with:

4.9.10 On-line Revocation Checking Requirements

The CA SHALL support an OCSP capability using the GET method for Certificates issued in accordance with these Requirements.

For the status of Subscriber Certificates:
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.

For the status of Subordinate CA Certificates:
The CA SHALL update information provided via an Online Certificate Status Protocol at least (i) every twelve months and (ii) within 24 hours after revoking a Subordinate CA Certificate.

If the OCSP responder receives an OCSP request but has no record of ever having issued any certificate with the certificate serial number in that request, using any current or previous issuing key for the CA subject, then the responder SHOULD NOT respond with a "good" status. OCSP responders for CAs that are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "good" status for such certificates. The CA SHOULD monitor the responder for such requests as part of its security response procedures.

-- MOTION ENDS --

*** WARNING ***: USE AT YOUR OWN RISK.  THE REDLINE BELOW IS NOT THE OFFICIAL VERSION OF THE CHANGES (CABF Bylaws, Section 2.4(1)):

A comparison of the changes can be found at: https://github.com/wthayer/documents/commit/f0b7c0a27fe51e73d5ed5d8d453024c51713ed70<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fwthayer%2Fdocuments%2Fcommit%2Ff0b7c0a27fe51e73d5ed5d8d453024c51713ed70&data=02%7C01%7CMike.reilly%40microsoft.com%7Cda8d31be310d41aca8c308d748274ed5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637057205980141295&sdata=mX6jXApg2Ueh1i9a14RjSAa5KMv0e%2Fcuf7zhPTFBcMQ%3D&reserved=0>

The procedure for approval of this ballot is as follows:

Discussion (7+ days)

Start Time: 3-October 2019 18:00 UTC

End Time: No earlier than 10-October 2019 18:00 UTC

Vote for approval (7 days)

Start Time: TBD

End Time: TBD

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191010/12732486/attachment-0001.html>