[Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates

[Ryan Sleevi]

I'll try to summarize with bullets, in the hope this would help. But
apologies if I'm not helping.

Goals:

   - This has nothing to do with requiring any CA support Certificate
   Transparency
   - This is not meant to put any normative requirements on CAs to do
   something new; that is, it is strictly to make the BRs language more
   permissive (at least, as read by some CAs), while not prohibiting anything
   they're currently doing, nor requiring through the BRs do anything
   different or new

The question this is trying to resolve is:

   - If a CA issues (and logs) a Precertificate, but does not sign an
   equivalent Certificate, do the BRs permit them to provide status
   information for that associated serial number?

The desired result is:

   - If a CA issues (and logs) a Precertificate, but does not sign an
   equivalent Certificate, the BRs clearly permit them to provide status
   information for that Precertificate, but does not require them to do so.
   - If a CA issues (and logs) a Precertificate, Root Programs can, via
   their own Root Policy, require the CA to provide status information for the
   associated serial number/Precertificate.

There are two ways, so far, identified to do this:

   - Require the CA sign an equivalent Certificate for every Precertificate
   they issue. That is, IF they log a Precertificate, THEN they MUST issue a
   matching Certificate
      - This "solves" the problem because a CA never has to worry about
      providing information for a Precertificate: because they're always
      providing information for the matching Certificate.
   - Clarify, in the BRs, that a CA MAY provide revocation information for
   the serial numbers within a Precertificate, with no further requirements.

Now, the problem with the first option is that if a CA issues a "bad"
precertificate (e.g. a precertificate for 'google.com'), they MIGHT catch
it before they've issued an actual Certificate ("post-issuance linting").
If the first option was used, it would mean they MUST misissue a
Certificate for google.com.

   - If you're a Root Program that doesn't use/care about CT, then the
   existence of the Precertificate is not a problem. However, if/once they
   issued the Certificate, it would be a Big Problem.
      - This means this option is bad for Root Programs that don't use
      CT/don't care about Precertificates, because now CAs would HAVE
to misissue
      the equivalent Certificate if they misissue a Precertificate.
   - If you're a Root Program that does use/care about CT, then there's no
   difference here, and the first option is Meh/no change.

Wayne's version is
https://github.com/cabforum/documents/compare/master...wthayer:ballot-sc23 .
This is what is called SC23.

It attempts to do the second option: trying to clarify, in the BRs, that a
CA MAY provide revocation information for the serial number within a
Precertificate. It does this by defining a Precertificate as a Certificate.
This way, the CA providing revocation information for a Precertificate is
really just providing revocation information for a Certificate, and there's
no issue.

Concerns:

   - Bruce, at Entrust, raised concerns that this would mean CAs MUST
   provide revocation information for Precertificates. This was suggested for
   a Phase-In, because it's not just a MAY, but a MUST.
   - Myself/Google raised concerns that this would have impact a variety of
   other aspects of the BRs. (This is my fault, too, since I originally helped
   Wayne try to craft the language for the Ballot, because I was unfortunately
   too optimistic we'd solve a different problem with the language as well)



In hindsight, I offered a different approach, at
https://github.com/cabforum/documents/compare/master...sleevi:2019-10-OCSP .
This is not an official Ballot

It attempts to do the second option: trying to clarify, in the BRs, that a
CA MAY provide revocation information for the serial number within a
Precertificate. It does this by continuing to say a Precertificate is not a
Certificate, but adjusting our OCSP language so that a CA MAY provide
status information for these, in addition to the status information that
they already (no change) MUST provide for Certificates.

Concerns:

   - Dimitris raised concerns about the understandability of the language,
   but those seem to have been addressed.
   - Jeremy raised the concern that it doesn't solve that second problem I
   mentioned, which is why Wayne's approach is preferable to Jeremy.
      - I'm explicitly not trying to solve the second problem with this
      draft, but I agree it's important, and have made suggestions on how to
      solve it (as a separate ballot)
   - Jeremy raised concern with language Dimitris originally proposed as a
   modification to that draft
      - I believe the substance of Jeremy's concern (
      https://cabforum.org/pipermail/servercert-wg/2019-October/001289.html
      ) is now addressed
   - Kirk raised concerns that we can't/shouldn't reference RFCs, and/or
   that we should define Precertificate.
      - However, this is keeping with our existing language and approach in
      the BRs, and the approach used in the text is extensively used elsewhere
      within the BRs.
   - Tim raised a concern that the term Precertificate should be added to
   the Definitions (1.6.1), rather than the text used.
      - This is slightly similar to Kirk's remarks; however, as with Kirk's
      remarks, the proposed language matches what we do in a number of other
      places, and with the existing text in the BRs
      - I'm not supportive of adding it to the Definitions (1.6.1) in this,
      because that runs the risk of making the second problem (the one
not being
      fixed) worse. Because it matches what we do, and doesn't make the second
      problem worse, I don't want to make Tim's suggested change.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191025/816d863c/attachment-0001.html>