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