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 

 - Requirements explicitly refer to revocation of the corresponding 
  actual certificate, not the (perhaps differently signed) 

 - 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 

 - 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

 - 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.


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

Reply via email to