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: - The corresponding actual certificate has been signed and submitted to CT (regardless if said submission was accepted), and all CA provided revocation mechanisms and servers report that the actual certificate is valid and not revoked. - The corresponding actual certificate has been signed, SHOULD have been submitted to CT (regardless if said submission was accepted) and was later revoked. All CA provided revocation mechanisms and servers MUST report that the actual certificate exists and SHOULD report that it has been revoked at a time no earlier than 1 second before the notBefore time in the preCertificate (other policy requirements or BRs state that they MUST so report before a different deadline). - The corresponding actual certificate has not been signed and MUST not be subsequently signed. All CA provided revocation mechanisms and servers must report that the certificate serial number was revoked at least 60 seconds before the time specified as "notBefore" in the preCertificate. Rationale: - Requirements explicitly refer to revocation of the corresponding actual certificate, not the (perhaps differently signed) preCertificate. - 96 hours is the existing BR deadline for updating revocation servers. - 24 hours is reasonable time for rolling out the "certificate good" status throughout a CA infrastructure, before taking actions such as submitting the actual certificate to CT. In practice, a CA will need to do this faster if it wants to provide the actual certificate to subscribers faster than this. - If a CA wishes to make an actually/possibly signed certificate never valid, it can report it as revoked 1 or 0 seconds before the notBefore time. This is appropriate where a problem report indicates that the certificate should never have been issued, or if signing the actual certificate was initiated but the result was not successfully stored. - Revocation times of 2 to 59 seconds before notBefore are reserved for use in future policies. - A CA system can be compliant while having only transaction-level reliability. - This caters to fast online CAs that complete the entire process in a few minutes or seconds. - This also caters to CAs that keep the private CA key offline and require human confirmation of signing actions. Such a CA may perform human confirmation of PreCertificate signing on a Friday, only accept problem report revocations during the weekend, then manually confirm signing of actual certificate, CRL and canned OCSP responses on Monday. Root CAs with signing ceremonies would be a typical case. Dedicated high security issuing SubCAs would be another case. - This also caters to the scenario where a usually fast online CA experiences a technical glitch that prevents completion of issuance, followed by a few days to detect the situation and revoke the non- issued certificates. - It also caters to the scenario of a CT log failing to issue the expected CT proofs, and the CA timing out the wait for that CT log after 24 to 72 hours. - It also caters to the scenario where a CT log fails to accept submission of the signed actual certificate. - Issuing a CT logged certificate but keeping it locked up in the CA building explicitly becomes a policy violation after just a few days, because it is then explicitly required to be published in CT and/or revoked. Practicalities: - CA systems (in-house of standard) will need to implement error handling logic to handle the various scenarios that can trigger the "revoke without issuing" case and the "issued-but-retroactively- revoked" case. Implementations need to be robustly tested in simulated environments with simulated failures and timeouts, thus final testing would probably take weeks or months just triggering the real timeouts, then requesting a bug fix. - If a CA revokes a PreCertificate serial with a revocation time indicating the never-issued case, it is a policy violation incident for that CA to have actually signed the certificate, even if the certificate never left the building. - If a CA revokes a serial with a revocation time indicating the issued-then-revoked case, it can be expected to have the actual certificate available in all but a few cases, and to submit that actual certificate to CT in all but a few of the remaining cases. - If a CA signs a certificate, but then immediately looses it (perhaps a disk or server failed when trying to save it), it would be one of the issued-then-revoked cases that cannot submit the signed actual certificate to CT. - In practice the never-signed revocation case can use a larger time delta (such as 2 hours) while remaining compliant. - CT log watching systems can distinguish the two revocation cases, and report them differently. - The required transactional integrity may or may not use a database engine as an implementation technique. The important thing is to securely store the fact (and data) of passing certain crucial moments in the issuance process such that they are not lost if a consumable component (such as a COTS disk system or COTS server) fails. - A system failure during actual certificate signing needs to be detected and handled within the 24 hour deadline. But such failures are typically detected within the hour, thus during any business hours signing ceremony. Also quickly enough for other servers in a fast CA cluster to automatically do the needed revocations or alert a 24/7 operator team. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
