On Friday, February 8, 2019 at 7:25:08 PM UTC-8, Jakob Bohm wrote: > On 09/02/2019 01:36, Santhan Raj wrote: > > On Friday, February 8, 2019 at 4:09:32 PM UTC-8, Joanna Fox wrote: > >> I agree on the surface this bug appears to be the same, but the root cause > >> is a different. The issue for bug 1462844 was a specific status not > >> counting as active when it was. To mitigate this issue, we updated the > >> query to include the missing status. However, we are in the process of > >> simplifying the data structures to simplify these types of queries. > >> > >> For the underscore certificates, these were non-active, not even > >> considered as provisioned since they were not delivered to a customer and > >> not publicly used for any encryption. These certificates were effectively > >> abandoned by our system. > > > > Is the term "certificate" accurate in this case? Assuming you embed SCTs > > within the EE cert, what you have is technically a pre-cert that was > > abandoned (not meant to be submitted to CT). Right? I ask because both the > > cert you linked are pre-certs, and I understand signing a pre-cert is > > intent to issue and is treated the same way, but still wanted to clarify. > > > > Or by non-active certificate, are you actually referring to a fully signed > > EE that was just not delivered to the customer? > > > > And in either case, the only reasonable sequences of events within > expectations (and possibly within requirements) would have been: > > Good Scenario A: > 1. Pre-certificate is logged in CT. > 2. Matching certificate is signed by CA key. > 3. Signed certificate is logged in CT. > 4. At this point the customer _might_ retrieve the certificate from CT > without knowledge of CA. > 5. Thus certificate is in reality active, despite any records the CA > may have of not delivering it directly to customer. > > Good Scenario B: > 1. Pre-certificate is logged in CT. > 2. CA decides (for any reason) not to actually sign the actual > certificate. > 3. The serial number listed in the CT pre-certificate is formally > revoked in CRL and OCSP. This is done once the decision not to > sign is final. > 4. If possible, label these revocations differently in CRL and OCSP > responses, to indicate to independent CT auditors that the EE was > never signed and therefore not logged to CT. > > Scenario B should be very rare, as the process from pre-cert logging to > final cert logging should typically be automatic or occur within a > single root key ceremony. Basically, something unusual would have to > happen at the very last moment, such as an incoming report that a > relied-upon external system (Global DNS, Internet routing, reliable > identity database etc.) may have been compromised during the vetting. > > In neither case would a CT-logged serial number be left in a > not-active but not-revoked state beyond a relevant procedural > delay. > > As pointed out in other recent cases, CA software must allow > revoking a certificate without making it publicly valid first, in > case Scenario B happens. > > > > 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
My assumption is, 1) Pre-cert is generated 2) something breaks 3) pre-cert is never submitted to CT (and is termed a non-active certificate) The basis for my assumption is "In rare cases, due to an order of operation problem, non-active certificates were being logged to CT." and in another response "These non-active certificates were revoked and we are taking steps to prevent non-active certificates from being logged to CT within the next 2 weeks. " There is no reason to "prevent non-active certificates from being logged to CT" if the pre-cert is already in CT. To me, it makes sense to say "prevent non-active pre-cert from being logged to CT". Thanks, Santhan _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
