On Mon, Sep 16, 2019 at 3:25 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 16/09/2019 19:08, Andrew Ayer wrote:
> > On Fri, 13 Sep 2019 08:22:21 +0000
> > Rob Stradling via dev-security-policy
> > <dev-security-policy@lists.mozilla.org> wrote:
> >
> >> Thinking aloud...
> >> Does anything need to be clarified in 6962-bis though?
> >
> > Yes, it's long past time that we clarified what this means:
> >
> > "This signature indicates the CA's intent to issue the certificate.  This
> > intent is considered binding (i.e., misissuance of the precertificate is
> > considered equivalent to misissuance of the corresponding certificate)."
> >
> > The goal is that a precertificate signature creates an unrebuttable
> > presumption that the CA has issued the corresponding certificate. If a
> > CA issues a precertificate, outside observers will treat the CA as if
> > it had issued the corresponding certificate - whether or not the CA
> > really did - so the CA should behave accordingly.
> >
> > It's worth explicitly mentioning the implications of this:
> >
> > * The CA needs to operate revocation services for the corresponding
> > certificate as if the certificate had been issued.
> >
> > * If the corresponding certificate would be misissued, the CA will be
> > treated as if it had really issued that certificate.
> >
> > Are there any other implications that 6962-bis should call out
> > explicitly?
> >
> > Regards,
> > Andrew
> >
> How about the following (Mozilla) policy rules:
> If a CA submits a preCertificate to CT, then it MUST ensure that one of
> the following is true no more than 96 hours after submitting the
> preCertificate and no more than 24 hours after signing the corresponding
> actual certificate:

This seems like a significantly worse change than Andrew's proposal,
because we can, do, and should expect better of CAs. A requirement like
this, captured in policy, actively discourages improvements to the status
quo, by explicitly encouraging delays.

It also seems to tie in a number of much broader, more impacting changes
that aren't immediately correlated, and thus would further delay productive
changes and clarifications. For example, magic values are very undesirable,
so we should try to avoid those.

I'm much more supportive of Andrew's change, as originally written. There
are other natural implications that may be worth expanding on, based on
some CAs' failures to think through them:

* If any corresponding certificate with the same serial number and issuer
exists, and can not be verified to match the precertificate using the
algorithms in 6962(-bis), it will be considered misissued.
  - This covers duplicate serial numbers, which may result if a CA fails to
mark the serial 'used' or 'issued' in their database
  - This logically implies that improperly (DER) encoding the SCT extension
within the final certificate is a BR compliance issue, while /not/ taking a
position on whether those SCTs conform to policy (e.g. number of logs or
diversity of logs), if/when Mozilla should adopt such a policy
  - This also covers situations where CAs reordered the extensions between
the issuance of a precertificate and the final certificate, as we saw some
CAs do, by suggesting it's a misissuance to do so; implicitly, it's stating
these are "different final certificates" - two certs with the same serial
with different extensions

* In examining historical issuance, the CA must consider both final
certificates and precertificates, even if the precertificate did not
ultimately result in the issuance of a certificate
  - We've seen multiple CAs "forget" to scan because they signed a precert,
but didn't mark a cert as 'active' or 'didn't issue the final certificate',
despite there still being misissuance.
  - However, CAs are also permitted to omit logging of certificates (e.g.
the policy does not /require/ logging of precerts /or/ certs, and both
Apple and Google permit local Enterprises to disable this), so it's not
sufficient to scan only precerts or final certs, but the union of both, to
ensure no omissions

Based on CA's failures, those two logical consequences stand out from
Andrew's proposal, which captures much of the spirit and intent.
dev-security-policy mailing list

Reply via email to