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

Fri Oct 25 14:37:08 MST 2019

Ryan, thanks for the summary.  I’ll digest it and get back with any additional concerns.  I’m sure others who haven’t fully kept up appreciate the summary as well.  @Wayne Thayer<mailto:wthayer at mozilla.com> thanks for your prompt response earlier.  Thanks, Mike

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

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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgoogle.com&data=02%7C01%7CMike.reilly%40microsoft.com%7C1e688464223846e1afa908d7598c2d94%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637076330912064314&sdata=RBA16oomc9Rs7KeoDIh3fiJ7bzirdy8QDnd%2FWaGADcQ%3D&reserved=0>'), 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<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgoogle.com&data=02%7C01%7CMike.reilly%40microsoft.com%7C1e688464223846e1afa908d7598c2d94%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637076330912064314&sdata=RBA16oomc9Rs7KeoDIh3fiJ7bzirdy8QDnd%2FWaGADcQ%3D&reserved=0>.

  *   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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fcompare%2Fmaster...wthayer%3Aballot-sc23&data=02%7C01%7CMike.reilly%40microsoft.com%7C1e688464223846e1afa908d7598c2d94%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637076330912074307&sdata=x5A1UQgJTQcaHnqiwXxFeHRoKe1VV6WZMrYKRaH95Ss%3D&reserved=0> . 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fcompare%2Fmaster...sleevi%3A2019-10-OCSP&data=02%7C01%7CMike.reilly%40microsoft.com%7C1e688464223846e1afa908d7598c2d94%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637076330912074307&sdata=VLZUkSFS0U07nkqTzB2NmL6KQKAPT2xie587JOhYHoo%3D&reserved=0> . 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum.org%2Fpipermail%2Fservercert-wg%2F2019-October%2F001289.html&data=02%7C01%7CMike.reilly%40microsoft.com%7C1e688464223846e1afa908d7598c2d94%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637076330912084298&sdata=DEGZOJdeIshnSdbiZb9OWNedau2okDDiQpttCap8%2B18%3D&reserved=0> ) 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/35369cfa/attachment-0001.html>