Proposal for an Interim Policy to Address Delayed Revocation

[Ben Wilson]

Hi folks, 

We have discussed delayed revocation a bit internally and wanted to come back to the community with some thoughts. 

We agree that expanding beyond the existing revocation timelines (24 hours / 5 days) is undesirable. While we think some exceptional delayed revocations are necessary as a current practicality, we do want to eventually sunset this policy. To that end, we’d like to refine our existing policy so that it is more effective and equitable during the interim. 

We’re skeptical about proposals to pre-identify domains that will require delayed revocation. We expect that many sites might ask for such exceptions, and an extensive amount of deliberation would be required in order to process these requests. Worse, in practice, doubtless some sites impacted in a revocation event would not have followed the procedure, and CAs would still be left with a last-minute decision about whether a revocation will inflict substantial harm. 

Instead, we would like to seek the community's feedback on the following two proposals: 

1. Clarification of existing requirements
   We would be more explicit about what would be required for delayed revocation. Some ideas include: 

1. Explicitly clarifying that CAs must revoke certificates by default, that any delayed revocation must be the result of an explicit request by the subscriber, containing the necessary information, and meeting the requirements under such interim policy;

2. That subscriber requests contain a clear claim or explanation about the critical nature of the system and why timely revocation is not possible (more detailed requirements to be discussed);

3. That the requests are signed by a company officer, or similar legal representative, stating that the information in the request is accurate to the best of their knowledge;

4. That the information contained in the subscriber’s request be accurate to the CA’s understanding (e.g. not materially contradicted by other facts known to the CA);

5. That each granted request be published for the community (and Mozilla) to scrutinize (allowing CAs to redact PII prior to publication); and

6. That CAs be required to produce summary statistics in their reports (alongside the individual granted requests) detailing how many requests were received, how many were well-formed, how many were granted, etc.
   
   

2. Consequences of Delayed Revocation
   We believe that if a domain hosts critical infrastructure that cannot tolerate timely revocation, then it is deeply damaging to the web PKI. In order to help these domains transition to effective certificate management practices and automated tooling, we propose that domains that are granted delayed revocation must then be limited to shorter-lifetime certificates as a consequence of such decision. This also ensures that future revocations impacting such domains have much less impact.
   
   Concretely, the domains accepted for delayed revocation by a CA are already public. If this proposal were to be adopted, root programs would manage a shared list of such domains (e.g. via the CCADB) and require CAs to limit the lifetimes of certificates issued to these domains (e.g. to 90 days). 

We stress that both of these proposals are presented for early feedback, and we look forward to the community’s thoughts on whether they are likely to be suitable and effective, and how they might be improved. We would also look to align these policies across the root programs in order to provide clarity for the entire community. 

Thanks and best wishes,

Ben

[Matt Palmer]

On Thu, Sep 19, 2024 at 03:53:16PM -0600, 'Ben Wilson' via dev-secur...@mozilla.org wrote:
> 1.

>
> Clarification of existing requirements
> We would be more explicit about what would be required for delayed
> revocation. Some ideas include:

> 1.

>
> Explicitly clarifying that CAs must revoke certificates by default,
> that any delayed revocation must be the result of an explicit request by
> the subscriber, containing the necessary information, and meeting the
> requirements under such interim policy;

If there are any CAs that currently think that they *shouldn't* revoke
certificates by default, I would be very deeply concerned.

> 2.

>
> That subscriber requests contain a clear claim or explanation about
> the critical nature of the system and why timely revocation is
> not possible
> (more detailed requirements to be discussed);

> 3.

>
> That the requests are signed by a company officer, or similar legal
> representative, stating that the information in the request is
> accurate to
> the best of their knowledge;

> 4.

>
> That the information contained in the subscriber’s request be
> accurate to the CA’s understanding (e.g. not materially contradicted by
> other facts known to the CA);

> 5.

>
> That each granted request be published for the community (and
> Mozilla) to scrutinize (allowing CAs to redact PII prior to publication);
> and

Requiring publication of the detailed reasons for delayed revocation as
part of a delayed revocation report would be a great benefit to the
WebPKI, I believe.

> 6.

>
> That CAs be required to produce summary statistics in their reports
> (alongside the individual granted requests) detailing how many requests
> were received, how many were well-formed, how many were granted, etc.

This, too, would be valuable information to improve the visibility and
resilience of the WebPKI.

> Consequences of Delayed Revocation
> We believe that if a domain hosts critical infrastructure that cannot
> tolerate timely revocation, then it is deeply damaging to the web PKI. In
> order to help these domains transition to effective certificate management
> practices and automated tooling, we propose that domains that are granted
> delayed revocation must then be limited to shorter-lifetime certificates as
> a consequence of such decision. This also ensures that future revocations
> impacting such domains have much less impact.

I believe this would be an admirable improvement, because as you say, a
shorter lifetime for such certificates reduces the period of time in
which a known-flawed certificate could be misused, if revocation were
significantly delayed for some reason.

Taking this thought to its logical conclusion, if a certificate is so
important that revocation is too dangerous to execute within the
strictures of the WebPKI, it should be moved to a seven-day lifetime,
which as I understand it means that the CA is no longer required to
revoke.

> Concretely, the domains accepted for delayed revocation by a CA are
> already public. If this proposal were to be adopted, root programs would
> manage a shared list of such domains (e.g. via the CCADB) and require CAs
> to limit the lifetimes of certificates issued to these domains (e.g. to 90
> days).

By "domain", are you referring to FQDN (ie sAN values) or the associated
eTLD+1? I would expect it to be FQDN, based on my understanding of the
intent, but it's worth clarifying, IMO, to ensure everyone's on the same
page.

- Matt

[Walt]

I think broadly this is a good decision. 

As Matt mentioned, I really really hope there are no CAs that think they shouldn't revoke by default, given the events of the past few months. 

I'd go a step further than that proposal however and suggest that each and every delayed revocation request requires a separate action to be made. 

For example, if I had: 

• acme.example.com
• example.com
• *.example.com

as three separate certificates that I needed delayed revocation on, I as the officer of Acme would need to submit three separate signed requests as Ben mentioned on the critical nature of the system etc. The goal here is to avoid a process where a company just goes "critical services, don't revoke" on a certificate set that is hundreds or thousands of certs. There's a potentially separate conversation to be had about subscribers not understanding the meaning of "CA can revoke within 24/120h" in the subscription agreement they're all agreeing to (at least I hope), but that's somewhat out of scope for this discussion.

Maybe a bit of a stretch goal here (especially since this would generally run counter to the incentives of the average CA [in that profit is more or less the priority by virtue of them being a for profit business) is that not only do any of these limited domains only allow a 90 day certificate, but a CA can only issue them using ACME or other fully automated protocols for x amount of time. Since this also has downstream impact in terms of EV/DV certs, this is a much harder sell, but as a counter point on why this may not be necessary if the 90 day max lifespan is implemented, a 90 day long certificate is rotating frequently enough that just from pure hassle alone it may make sense to switch to automating the certificates, whether or not enforcing ACME or similar is a mandated part of that list. 

[Wayne]

I have no concerns with the proposal as-written, and would like to thank Mozilla for taking feedback on the prior proposal.

- Wayne

[Suchan Seo]

I think 90 days max can stop it, because curreny proposal makes each and all domains included in delayed certificate have 90 days max, so clients likely wouldn't add domain unless it's required.

2024년 9월 20일 금요일 오전 10시 26분 5초 UTC+9에 Walt님이 작성:

[Q Misell]

Hi all,

Thanks Ben for this proposal. Overall I find it well thought out and it moves things in the right direction. Publishing the requests received from customers will do a lot to help with what has until now been a series of vague justifications from CAs on why revocation was delayed.

I agree with Walt that every FQDN should be a separate request with its own justification; excess paperwork is a great way to drive a point home with some corporates.

Moving delayed FQDNs to shorter term certificates is a nice tradeoff, a clever idea! I think 90 days in the first instance is about right, but if it happens again the FQDN should be moved to STAR certificates. If it happens a third time then I'm not quite sure what to do other than say 'are we absolutely positively sure WebPKI is right for this application?'

I don't think specific technical standards, such as ACME, as Walt suggested should be written into this proposal. A customer should generally be free to manage their certificates however they like. If they choose to manage 90 day (or even 7 day) certs manually, that's on them.

Q

---

Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/07e2ef29-85ed-4080-b8c9-a542770a294en%40mozilla.org.

[James R Moir]

"As Matt mentioned, I really really hope there are no CAs that think they shouldn't revoke by default, given the events of the past few months. "

But we should not forget there are some CAs who feel that they can delay revocation of over 80.000 certificates just because of a problem with 70 of them.

I welcome this proposal from Mozilla.

JR

Sent with Proton Mail secure email.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/7325aa62-c3b0-41b0-962d-5d44e0847c9an%40mozilla.org.

[Aaron Gable]

Ben,

I like these proposals. I think they will do a good job of preventing the kinds of delayed revocation incidents we have seen lately.

However, there is one other kind of delayed revocation incident we've seen in the past that I think these policies don't address: https://bugzilla.mozilla.org/show_bug.cgi?id=1715455. That incident three years ago affected 185 million certificates; if a similar incident were to happen today it would affect over 400 million. While I completely agree that the impact on any individual website would be negligible, and that delayed revocation should not happen at the behest of site operators, I do worry about the impact on end-users when certificates are revoked at such a large scale. In particular, I worry about accidentally training people to believe that clicking through their browser's SSL warnings is OK.

Thankfully technologies like ARI are improving things here: it's deployed by several CAs, implemented in several clients, and is ready for Working Group Last Call at the IETF. But ARI hasn't yet become ubiquitous enough to significantly mitigate the aggregate effect of revoking 400M certificates with (in the worst case) less than 24 hours of warning.

So if possible I'd like there to be some thinking about this other mass-revocation case.

Thanks,

Aaron

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYZWhgfs23hB-Z%3DgEQCybugPrP8W4MSdnX9Y-dyoMoarA%40mail.gmail.com.

[Jesper Kristensen]

The proposals are very interesting.

Regarding limiting lifetimes, would you consider allowing per-CA lists instead of a shared list? I think that would have some advantages:

- Faster to implement because CAs don't have to wait for CCADB to develop such a shared list.

- Faster/easier for CAs to implement because they can use whatever internal format and process that suits them instead of having to build a new integration to CCADB.

- CAs could be required to add a FQDN to the list as soon as they decided to delay a revocation instead of allowing them to wait until Mozilla updates CCADB.

- If a CA and a subscriber disagrees afterwards about who requested the delay, then that dispute would only impact the CA in question and not other CAs which were not involved.

- CAs with never-delay revocation policies might not have to implement such a list.

- Incentivises CAs to revoke on time to avoid having their customer on their internal list but not on their competitor's list.

The Chrome root program has previously described an intent to reduce lifetime for all certificates to 90 days in the future. It would be great if Mozilla could do the same and then use this proposal as a first step towards that goal.

And similar to what Aaron said, these proposed policies should be scoped to when a CA delays revocation because subscribers requested it or because the CA is worried about the potential impact to its subscribers. This will still cover almost all delayed revocation incidents we have seen lately. If CAs then start to blame themselves instead of subscribers to avoid the new requirements, they would then have to add action items to their incident reports to reflect that.

--

[Tim Callan]

We would like to commend Mozilla and the CCADB members for this excellent work.  It is a very strong first step in solving the rampant delayed revocation problem afflicting the WebPKI today.  We expect this approach to be effective for these reasons:

·        It eliminates automatic or thoughtless delayed revocation.  By forcing both Subscribers and CAs to take on significant actions for each delayed revocation, it combats the common tendency we see to simply delay revocation for vast tranches or entire bodies of misissued certificates.

·        It requires a true, individualized justification for each delayed revocation incident.  This will help the community understand the circumstances in which existing revocation timelines are legitimate societal problems and work on solutions.

·        It has a strong deterrent effect for unnecessary delays.  By mandating documentation of reasons and restricting affected domains to 90-day certificates in the future, both Subscribers and CAs are motivated to hold back delays to only those cases where they are truly warranted.

·        It still allows for delay in legitimate emergency cases.  There does exist a failsafe for the very rare occasion where a delayed revocation is truly warranted.

·        It mitigates risk for non-agile environments.  Restricting domains experiencing delayed revocation to shorter-lived certificates reduces the overall risk these non-agile environments bring to the WebPKI.

·        It encourages repair of the root problem.  Subscribers reduced to maximum 90-day term will be strongly motivated to adopt agile processes or move to private-root PKI solutions.  As Subscribers become aware of this possibility, they will be motivated to prepare in advance for revocation events to avoid this eventuality.

We wholeheartedly endorse this plan while recognizing that an additional level of detail remains to be worked out.  To that effect, we have a few comments.

The plan as written restricts certificates to 90-days for affected domains regardless of issuing CA.  As a mitigating measure, this makes sense. It prevents Subscribers from simply hopping to another CA to avoid solving the core agility problem.  The suggested affected domains list managed by CCADB will be essential to this program working correctly.  A “90-day linter” would be valuable in aiding CA compliance with this requirement.  If this part of the proposal becomes enforced policy, Sectigo is very interested in creating this linter and also plugging it into pkimetal.

We believe this program strongly motivates Subscribers to become more agile with critical systems and to consider more seriously before demanding revocation delays.  As such public education of the new rules will strongly affect success.  We will encourage both CAs and browsers to assist in communicating these new rules clearly and broadly.

We notice that there is no end date for the 90-day certificate limit.  We agree with this decision, as it seems likely that the entire ecosystem will move to this timeline in the fairly near future anyway.  We will point out that the deterrent and mitigating effects of this limit are eliminated once the maximum term for all public TLS certificates drops to 90-days.  Once that happens, CCADB may want to consider a shorter limit for delrev domains (30 days?) to reinstate these benefits.

Regarding which domains should be restricted to 90-days, as Matt also comments, we believe it would be essential to restrict the base, registrable domain and all subdomains under this policy. Doing otherwise would allow subscribers to get around this restriction through sub-domain hopping. While this could also be circumvented by registrable domain hopping, obviously that is considerably more difficult and comes with its own consequences.

In conversation another CA suggested that we need to deal with the issue of change of domain ownership.  Our first-blush reaction is that the shortened maximum term should remain even when a domain changes hands.  This is mostly for practical reasons.  It prevents Subscribers from shifting domains between their own companies or other such shenanigans.  It prevents M&A activity from wiping clean domains that should still be restricted to 90-days.  And it removes the need to create an entire mechanism for tracking ownership changes and marrying them back to maximum term.

We hope a mechanism could exist to make the maximum allowed term of a domain generally available knowledge.  That way potential buyers of domains or companies have the opportunity to account for that information before purchasing.

There does exist the possibility of a delayed revocation that is unintentional by both the CA and the Subscriber.  This could owe itself to a software bug or procedural error made purely in good faith.  Under these circumstances there is no agility/criticality risk indicated for the domains in question.  CCADB should consider what is required here.  Clearly there will be no request from the Subscriber, and the CA’s explanation will be the same for all domains, which will be the error that led to the delay.  Though such a thing is very rare, it is possible.

Under these circumstances limiting affected domains to 90 days might be unnecessarily hard on Subscribers through no fault of their own.  We are inclined to say in the case of a truly accidental revocation delay that this limit not be placed.  Of course, this does open a potential loophole for bad-faith declarations from CAs that a revocation delay was motivated by an unwitting error.  We expect that public scrutiny and reputational damage to the CA will be sufficient demotivators to prevent this kind of deceit and suggest there be a different set of requirements for unintended revocation delay.  The CA should still be expected to report and explain the problem and to provide credible action items to prevent repeat of this error, just as with any other bug.

[Mike Shaver]

Hi Ben,

First, thanks for this proposal. It is excellent leadership on the part of Mozilla and yourself to address the underlying cause of chronic delayed revocation: incentives that are mismatched with the goals and needs of the Web PKI. I think it represents tremendous progress towards a healthier and more secure Web PKI, which is to say one for which relying parties can be more confident that certificates they encounter are properly issued and trustworthy. Backtesting this against the last year’s incidents paint the future you describe in a much more pleasant colour than the recent past we endured as a community.

Some more specific comments:

On Thu, Sep 19, 2024 at 5:53 PM 'Ben Wilson' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:

We’re skeptical about proposals to pre-identify domains that will require delayed revocation.

Agree.

We expect that many sites might ask for such exceptions, and an extensive amount of deliberation would be required in order to process these requests. Worse, in practice, doubtless some sites impacted in a revocation event would not have followed the procedure, and CAs would still be left with a last-minute decision about whether a revocation will inflict substantial harm. 

One notable issue we’ve seen in the past is differing understanding of what constitutes “substantial harm” or “critical infrastructure”. I recognize that it will require a fair bit of deliberation and debate to settle on one even for the scope of Mozilla’s root program, let alone the broader CA/BF community, but I think it is important to nail that down more crisply and to avoid skew between CAs.

1. Clarification of existing requirements
   We would be more explicit about what would be required for delayed revocation. Some ideas include: 

1. Explicitly clarifying that CAs must revoke certificates by default, that any delayed revocation must be the result of an explicit request by the subscriber, containing the necessary information, and meeting the requirements under such interim policy;

I think we need a template or similar to show what the necessary information is, and to reinforce the criteria for “critical infrastructure” or similar. I volunteer to draft one in October, drawing hopefully on the wisdom of this community, if that would be helpful.

1. That subscriber requests contain a clear claim or explanation about the critical nature of the system and why timely revocation is not possible (more detailed requirements to be discussed);

We should expect that there will be push-back on this via security or other such angles, but I agree that it’s important.

“Not possible” isn’t really appropriate here, IMO, since it’s very rarely physically prohibited given sufficient investment and assumption of risk. Goes back to the “substantial harm” definition, sort of.

1. That the requests are signed by a company officer, or similar legal representative, stating that the information in the request is accurate to the best of their knowledge;
   

Extremely good.

1. That the information contained in the subscriber’s request be accurate to the CA’s understanding (e.g. not materially contradicted by other facts known to the CA);

What might the consequence be if this were found to not be honoured? One challenge of the current policy around delayed revocation is that there isn’t a clear “or else”.

1. That each granted request be published for the community (and Mozilla) to scrutinize (allowing CAs to redact PII prior to publication); and
   

Should this be limited to granted requests, or others that the CA might themselves have declined? I think the additional visibility would help CAs and others refine their communication with subscribers in order to improve alignment on the criteria. It might also disincentivize subscribers from trying “just in case it works” and creating additional work for CAs and others evaluating these requests in good faith.

1. Concretely, the domains accepted for delayed revocation by a CA are already public. If this proposal were to be adopted, root programs would manage a shared list of such domains (e.g. via the CCADB) and require CAs to limit the lifetimes of certificates issued to these domains (e.g. to 90 days). 

I like the idea of the centralized list, but I’m concerned that it puts CCADB infrastructure in the critical path of certificate issuance. That’s a big operational responsibility and a type of centralized dependency that AFAIK doesn’t currently exist in the ecosystem. Could we find a way to piggyback on CT or similar infrastructure, which is already maintained to the standards required?

1. We would also look to align these policies across the root programs in order to provide clarity for the entire community. 

I agree that cross-program alignment would be valuable, but I would hope that it wouldn’t be a prerequisite for Mozilla adopting a policy. Some root programs are more engaged than others in these matters, and letting them delay the implementation of an improvement like this one would be unfortunate.

Mike

Apologies for this Gmail nonsense:

[David Adrian]

I don't understand why these proposals exist. We have a process for delayed revocation already, it's called Filing An Incident.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqu2-_ByLaOFf3fadH_b7AiqGeOe3OKb7ZGZkvLiRrNOAw%40mail.gmail.com.

[Mike Shaver]

I think that this process in its current form has not served to minimize or eliminate delayed revocation. The requirement to file an incident, and the kinds of remediation that have historically been promised or provided in the context of those incidents, have not materially improved the trustworthiness of certificates on the web, and in my opinion something has to. I think that the view that the process for delaying revocation is simply to “file an incident”, and that it is merely an administrative burden rather than a signal that material change must occur between CA and subscriber, is a major contributor to the issues we have had over the past year(s).

Do you feel that the frequency and magnitude of delayed revocation over the last year, across many CAs, should be acceptable to root programs and the community? Do you feel that the proposals are harmful in some way?

Mike

[David Adrian]

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

> Do you feel that the frequency and magnitude of delayed revocation over the last year, across many CAs, should be acceptable to root programs and the community? 

Delayed revocation incidents should be exceptional, not routine. 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.

We have a process for making mistakes and exceptional circumstances already, it's called Filing An Incident. It is expected that incidents themselves are routine, and evaluated by root programs holistically and with discretion. There should be no expectation that an single delayed revocation would result in immediate trust actions. 

> Do you feel that the proposals are harmful in some way?

Yes.

Any proposal to add an exception to the rules, rather than actually changing the rules, is harmful to the ecosystem, and in particular, harmful to any root program that expects the rules and incident process to be followed. The recent Digicert delayed revocation incident would have been much easier to handle if there had been no expectation of an "exception", especially given that Digicert sought an exception from multiple root programs _that did not have exception processes_. Ironically, I am not even sure Digicert considered Mozilla important enough to ask. Mozilla's existing process is harmful, and doing anything other than getting rid of it exacerbates the problem.

[Mike Shaver]

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

[Sandy Balzer]

Dear Ben,

 

Thanks a lot for your effort which is highly appreciated.

 

SwissSign would prefer option 2 (Consequences of Delayed Revocation) over option 1 as an interim policy change. The reason being that it has nudges the customer toward automation. However we believe that there are some customers who really struggle with automation and we believe it is important to get more insights into what exactly their problems are.

 

Additionally, from a customer point of view (as well as the whole PKI community) it would be important to outline the final target state that such an interim policy change would work towards including the time frame of the final state.

 

From our previous delayed revocation, we know that:

• public trust certificates are used where private PKIs may be better suited
• customer internal approval processes take more time than a 24h/5d revocation timeline allows
• certificate pinning is still used (although it is generally known that it's a bad idea) that requires update to applications
• update of certificates in Apps that require re-publishing in App-Stores which may not be possible within the required timeline
• customer awareness of their contractually agreed requirement to be able to deal with 24h/5d revocation is low

 

All these are not problems that a CA alone can fix. All we can do is educate, support to the best of our abilities and revoke on time.

 

Finally, we think that we should consider if TLS and S/MIME should be treated the same or not. To this, we currently don't have a position/preference.

 

Kind regards

 

Sandy Balzer / SwissSign team

--

You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYZWhgfs23hB-Z%3DgEQCybugPrP8W4MSdnX9Y-dyoMoarA%40mail.gmail.com.

[Matt Palmer]

On Tue, Oct 01, 2024 at 12:26:08PM +0000, Sandy Balzer wrote:
> Dear Ben,
>
> Thanks a lot for your effort which is highly appreciated.
>

> However we believe that there are some customers who really struggle
> with automation and we believe it is important to get more insights
> into what exactly their problems are.

Towards that end, what has SwissSign done to (a) confirm that first belief,
and (b) gather the insights? What is SwissSign's timeline to complete
those information gathering activities, and to what degree is SwissSign
willing to commit to sharing the details and conclusions from that work?

> Additionally, from a customer point of view (as well as the whole PKI
> community) it would be important to outline the final target state
> that such an interim policy change would work towards including the
> time frame of the final state.

I think the final state is fairly straightforward: that no revocation is
delayed beyond the BR-mandated limits due to subscriber action (or
inaction). The desired time frame is "years ago".

> From our previous delayed revocation, we know that:
>

> * public trust certificates are used where private PKIs may be
> better suited
>
> * customer internal approval processes take more time than a
> 24h/5d revocation timeline allows
>
> * certificate pinning is still used (although it is generally

> known that it's a bad idea) that requires update to applications
>

> * update of certificates in Apps that require re-publishing in

> App-Stores which may not be possible within the required timeline
>

> * customer awareness of their contractually agreed requirement to

> be able to deal with 24h/5d revocation is low

This is a solid distillation of the problems that subscribers have
caused for themselves (and their CAs). It would be useful, I think, for
all CAs, particularly those with extended issuance periods and legacy
issuance mechanisms (which are those most likely to have a large number
of customers with these problems) to consider these issues and determine
what work they will do to mitigate or eliminate them. If I were
Mozilla, I might even put them in a future CA questionnaire...

> All these are not problems that a CA alone can fix. All we can do is
> educate, support to the best of our abilities and revoke on time.

While a CA alone may not be able to fix these problems, from the
perspective of the WebPKI community, these are all problems that are the
CA's responsibility. The CA is the interface between the WebPKI and its
subscribers, and thus is the best-placed party to influence the
behaviour of its subscribers.

- Matt