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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
