[Servercert-wg] Ballot SC23: Precertificates

[Ryan Sleevi]

On Thu, Oct 10, 2019 at 3:16 PM Mike Reilly (GRC) via Servercert-wg <
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 CA 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191010/6827ba8b/attachment.html>