Thank you, this is helpful (to me at least).
On 9/28/2024 3:31 PM, David Adrian wrote:
> I think that this process in its current form has not served to
minimize or eliminate delayed revocation.
Unlike literally every other rule, one root program had an explicit
exception for just this rule. And unsurprisingly, the exception was
leveraged a lot.
I don't think it's fair to describe this as being unique to Mozilla's
root program, though Mozilla's expectations were more explicit--if not
generally, or maybe ever, honoured in their entirety. As an
example,Chrome's root program
<https://www.chromium.org/Home/chromium-security/root-ca-policy/#7-reporting-and-responding-to-incidents>
provides for Filing A(nother) Incident if the expected remediation
doesn't happen in the prescribed timeframe:
"If the Chrome Root Program Participant does not perform the required
follow-up actions, or does not perform them in the expected timeframe,
the Chrome Root Program Participant SHOULD file a secondary incident
report describing any certificates involved, the expected timeline to
complete any follow-up actions, and what changes they are making to
ensure they can meet these requirements consistently in the future."
(That SHOULD not being a MUST breaks my heart a little, but I think that
practically it doesn't have much effect.)
Similarly, the CCADB incident process
<https://www.ccadb.org/cas/incident-report> itself says:
"CA Owners should submit an additional, separate incident report when:
* Policy requires the revocation of one or more certificates by a
certain deadline, such as those in BR section 4.9, but that deadline
will not be or has not been met by the CA Owner."
In what ways do you feel that those are materially different from
Mozilla's supplemental incident response guidance, other than that
unlike Mozilla's these cases are directly part of the policies?
There is a solution to "there is a pattern of incidents" available to
root programs already. I do not understand why, given a pattern of
incidents, the solution Mozilla is proposing is "add an exception",
not either trust actions, or actually changing the rule. Either strike
the rule, or don't.
Ah, this is interesting. I see the 90-day-limit as in fact being an
explicit description of a trust action that is being proposed as Mozilla
policy: we will no longer trust this subscriber-domain to . It's a bit
unusual in that it's a trust action that's directed more at the
subscriber than at the CA, but practically that's where responsibility
and agency for "critical infrastructure" and related misuses of the Web
PKI are going to live.
Another way to imagine this rule is "Mozilla will not trust certificates
with a validity period > 90 days if they are issued against a domain in
this shitlist". Getting that to be the case across multiple root
programs would obviously improve things for Mozilla in matters of market
share /realpolitik/, and if CAs can be convinced not to issue in the
first place then that's a better situation for all involved IMO; in
terms of the effect on Mozilla's users as relying parties, though, I
think they're pretty much equivalent.
As far as I can tell, Ben is not proposing a solution to "a pattern of
incidents", nor a limitation on how those might be addressed. As I
understand the proposal, this would apply to all delayed revocation
cases, including the "first offense" for any given CA or subscriber. It
doesn't take any tools out of Mozilla's hands with respect to how to
address CAs who Mozilla feels are not acting appropriately, such as
distrust or partial-trust limitations. A separate discussion on what
constitutes a pattern of incidents, and how Mozilla might in the future
decide to respond, could be valuable, but I would not want to do
anything that kept Mozilla from being able to distrust a root at its
sole discretion.
Any proposal to add an exception to the rules, rather than actually
changing the rules
I'm not sure exactly what you mean here. Adding an exception is
obviously changing the rules, if you see this as adding an exception.
I see it as adding a more explicit statement of consequence to accompany
"Mozilla does not grant exceptions to the BR revocation requirements". I
do think that the wording on the CA/Responding _To_An_Incident page
would benefit from some edits for clarity, and I think that Ben is
already working on changes in that direction. The existence of that page
does seem to have been taken by some CAs and perhaps subscribers as
permitting delayed revocation if the administrative tasks of the
additional incident are fulfilled. Mozilla's responses to such delayed
revocation cases, and patterns thereof, have been more muted than I
would have personally preferred, but I take these proposals as a welcome
sign that Ben and the team are looking closely at how they now want to
respond in cases where delayed revocation does occur.
I see now that among my comments in my earlier reply to Ben, I missed
one that I wanted to make:
Having parents pick up children late from daycare is a big problem for
many care providers. In order to deter such behaviour--or, if you
prefer, to motivate timely pickup--some daycares institute additional
fees/fines incurred when a child is picked up late. Unfortunately, this
often has the opposite effect to what's desired: parents see the fee as
being the fair-exchange price of arriving late, and reason on that
basis. "It's worth $50 to me to not leave this meeting early." I do
worry about situations where CAs and subscribers reason about the cost
of migrating to a 90-day cycle versus the cost of prompt revocation, on
a similar fair-exchange basis.
(If I recall correctly, the most effective means for reducing late
pickup were "N-maybe-zero-strikes after which the parents are given 90
days to find a different daycare" or "rely on social pressure and the
human relationship and guilt and such soft tools". The latter seems to
not be especially viable for root programs, and I don't know that a
bright line N-strikes policy would be in the interests of the web either.)
, is harmful to the ecosystem, and in particular, harmful to any root
program that expects the rules and incident process to be followed.
Could you elaborate on the specific rules or process elements in the
CCADB or non-Mozilla root programs that you feel are put at risk by
providing clarity on how Mozilla plans, at least in part, to respond to
future delayed revocation cases?
Mozilla could *always* have said "we're not going to trust > 90 certs
from this domain now" after a delayed revocation incident. This is not
giving them new permission, because root programs can basically do
whatever they want, or reducing any possible penalty. It's providing
clarity about how Mozilla plans to react in the future, and how it hopes
other root programs will as well. With or without this proposal being
described in detail, Ben can always say "you're a 90-day domain now",
and has always been able to. This is a proposal for Mozilla to make its
operating policy be that it will react in a certain way to *any* delayed
revocation, and to document that policy decision for the benefit of the
community.
From the perspective of it being corrective rather than punitive, a
shorter limit would be more effective, because if it's setting the upper
boundary on how long revocation for a cert can be delayed, then 90 days
is still too high. I'm OK with it relying on the punitive element and it
creating better incentives for automation, and this policy wouldn't
prevent Mozilla from setting a shorter limit on a domain's certs
whenever it felt that was appropriate.
Mike
--
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 on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/40b7576f-6464-409a-8aa5-0766fad43ec8%40gmail.com.
