On 1/3/2025 11:49 AM, Roman Fischer wrote:
I think the problem of delayed revocation is automatically solved once
the proposed clarification by Mozilla (and other root store operators)
clearly states that delayed revocation will unconditionally to removal
from the trust store. Why invent a whole new mechanism when the same
goal can be achieved much easier?
Because in some cases it can have a huge impact that puts the stability
of the entire WebPKI ecosystem at risk, causing economic and social
impact at a Global scale. What would happen if Let's Encrypt revoked all
their Certificates in https://bugzilla.mozilla.org/show_bug.cgi?id=1715455?
Best regards,
Dimitris.
Kind regards & welcome to 2025
Roman
*From:*[email protected]
<[email protected]> *On Behalf Of *Mike Shaver
*Sent:* Montag, 23. Dezember 2024 17:21
*To:* Rich Salz <[email protected]>
*Cc:* Matt Palmer <[email protected]>; [email protected]
*Subject:* Re: MRSP 3.0: Issue #276: Delayed Revocation
There are certainly CAs who could improve the overall state of the Web
PKI by being more responsive to their commitments. We had an example
this year of a CA sitting on revocation of invalid certs for more than
a month because the vendor of their CA-management software said it
would take that long to get the fix to their issuance (rather than
directing their subscribers to get certs from another CA who could
correctly issue certificates at that time—because it would cause
inconvenience for the subscribers).
However, in many delayed revocation cases, it is indeed the Subscriber
who needs to be more responsive to their (legally binding, as required
per the BRs) commitments to tolerate prompt revocation. CAs in these
circumstances are pressured to violate their covenants under the BRs
and related policies, and defer revocation to accommodate Subscriber
convenience (both immediate and historical, in the form of
underinvestment in certificate management or automation). A random
revocation test is really a test of the *Subscriber* population, and
how they are influenced by the policies and (more importantly) actions
of their chosen CA.
To emphasize, as a customer of the CA operating under the TLS BRs, you
have legally agreed that the CA can blow away the cert in 24/120 hours
and that you will tolerate that without
unacceptable-to-the-world-and-the-web consequences. That legal
commitment is often not reflected operationally, unfortunately, and
the desired result of a random revocation audit is to smoke out those
cases, and if that results in some operational distress for
underprepared Subscribers, then hopefully their distress is helpful
/pour encourager les autres/ as well as motivating the Subscribers in
question to improve their operations.
IMO the random revocation should take exactly the same operational
form as a real revocation under the 5-day clock: CA is notified that
they need to revoke, identically to a CPR being filed, and then they
inform the subscriber and the clock has started. When the clock
expires, the certificate is revoked. I don't think that the process of
issuing the replacement certificate is typically the long pole, and
rather it's available as soon as the Subscriber asks for it. If the
DCV is still in its validity period then the CA could proactively
reissue at the point of the CPR arriving, if that proves to be a
meaningful assistance to the Subscriber in replacing things.
Mike
On Thu, Dec 19, 2024 at 8:24 PM Rich Salz <[email protected]> wrote:
On Thu, Dec 19, 2024, 6:59 PM Matt Palmer <[email protected]> wrote:
Oh, I don't know... ransomware has been far more effective at
improving
DR practices than several decades of education was.
An important difference is that I am a customer of the CA, and
often paying for a service. I'm not paying you to DoS me.
In the venues where I mainly work( the ietf) we often say that
revocation does not work on the web. Which part of the Web PKI
needs to become more responsive? My hunch is that it is not the CAs.
--
You received this message because you are subscribed to the Google
Groups "[email protected]" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected].
To view this discussion visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAFH29trsULk%3D%2BTjyMkZBkr716vkXomrq0mOD0_Tpb8TMLF7-AQ%40mail.gmail.com
<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAFH29trsULk%3D%2BTjyMkZBkr716vkXomrq0mOD0_Tpb8TMLF7-AQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To view this discussion visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqtjanuDV1GEMhXzuEFG%2BnaC5ZVKfDgchYX4UfuxRtpwFA%40mail.gmail.com
<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqtjanuDV1GEMhXzuEFG%2BnaC5ZVKfDgchYX4UfuxRtpwFA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To view this discussion visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZR0P278MB017059F4DBB48A4B20BEA95AFA152%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM
<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ZR0P278MB017059F4DBB48A4B20BEA95AFA152%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/5fe1e9c2-3598-4001-9447-2f6ec646770f%40it.auth.gr.
