Question about implementation of DNSSEC checks for E-Mail based Domain Validation

[Roman Fischer]

Dear all,

 

The vendor of our CA system has started planning for the implementation of DNSSEC validation of Domain Validation and CAA (SC-085v2).

 

On point came up: We do currently support domain validation method 3.2.2.4.4 Constructed Email to Domain Contact. This is implemented in a way that the CA system has the mail-server configured where it hands off the emails to be sent out.

 

It's now not really clear how to handle this with respect to DNSSEC validation. Is the expectation of the community that the sending mail-server will have to do DNSSEC validation as described in the TLS BR?

 

If so, that would have the side-effect that when such a DNSSEC validation fails, the mail-server currently has no way of signaling this failure back to the CA system. This in turn would mean that the customer would simply not receive the constructed email with the token and the domain validation would remain in a "pending" state.

 

1. What is the community's expectation regarding DNSSEC checks for email-based domain validation methods?

2. How are other CA's implementing this case?

 

Thanks for any feedback and experience sharing!

 

Kind regards
Roman

 

Roman Fischer

Information Security Manager

 

+41 76 310 12 66

roman....@swisssign.com

 

SwissSign AG

Sägereistrasse 25

Postfach

CH-8152 Glattbrugg
swisssign.com

 

Nichts mehr verpassen: Folgen Sie uns auf LinkedIn!

Abonnieren Sie unseren Newsletter oder besuchen Sie unseren Blog.

 

[Andrew Chen]

Roman,

Assuming you configure your mail server to require DNSSEC validation, failure processing could be implemented by having a unique return-path per message sent, pointing to an inbound parse webhook that can process the bounce.

Andrew

--
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/ZR0P278MB01708F040851FCAA255AFC2EFA30A%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM.

[Dimitris Zacharopoulos (HARICA)]

During the last WG Teleconference, this topic was briefly discussed. While some members expressed an expectation that DNSSEC should apply to Email Domain Validation methods, the BRs are not so explicit about it. Some amendments may be needed before the effective date of SC085 (March 15, 2026).

It was suggested that this topic is added to the agenda of the next Validation Subcommittee Teleconference.


Thank you,
Dimitris.

--
Dimitris Zacharopoulos
CA/B Forum SCWG Chair

[Roman Fischer]

Dear all,

 

Following up on a discussion during the last face-2-face meeting, we are asking the community for feedback on (realistic) threat vectors that could abuse the situation where DNSSEC would not be checked for E-Mail based Domain Control Validation while DNSSEC would be checked for CAA checks.

 

The reason we're looking for such threat vectors is to decide if a temporary exclusion of DNSSEC check for e-mail based DCV would present a risk that is not sufficiently mitigated by doing CAA checks with DNSSEC validation during certificate issuance.

 

Kind regards
Roman

[Martijn Katerbarg]

Hi Roman,

While I expect everyone on this list to be aware of the fact, I think it’s good to reiterate the difference between DCV and CAA:

• DCV needs to be perform to specifically prove control over a domain name, and with that, allow the CA to issue a certificate for said domain, to a specific Applicant. In a broad sense, this is a whitelist mechanism, a very narrowly scoped one.
• CAA on the other hand, is essentially the exact opposite. In the first place, it’s a blacklisting mechanism. If no record exists, every CA is allowed to issue, for any Applicant (not taking DCV into account). As soon as a single record does exist, it sort of turns into a whitelist, but then still, it turns into a whitelist for which CA is allowed to issue, not which CA for which subscriber (That is, until https://github.com/cabforum/servercert/pull/567 is a thing).

To this, we should add the fact that E-mail based DCV currently doesn’t require MPIC to be performed. 

It seems to me like Email based DCV is one of our weakest links at the moment. The method is open to BGP hijacks, something which, depending on where in the chain it is performed, could allow for the CA to be returned falsified record sets. Blocking the processing of invalidly signed DNSSEC records, for organizations that want to rely on DNSSEC, would at least mitigate those cases.

With CAA records still not very widely adopted, and when it is adopted, limits issuance at the CA level, not Subscriber level, I do not believe this poses as a valid mitigating mechanism.

Regards,

Martijn

From: 'Roman Fischer' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Friday, 17 October 2025 at 13:09
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] RE: Question about implementation of DNSSEC checks for E-Mail based Domain Validation

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

--

You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/ZR0P278MB01702808B7138FF964689428FAF6A%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM.

[Dimitris Zacharopoulos]

Hi Martijn,

If the Domain Owner's zone is DNSSEC-enabled, and there is some error in the DNS responses, even for the CAA negative existence query (NSEC3), the CA is not allowed to issue. So, in the specific cases where the zone is DNSSEC-enabled and the CA gets an invalid response, whether it is for a CAA query or a DCV, the CA is not allowed to issue.

That's why I believe DNS MX queries, for those secure zones, are not so necessary, especially when there is a plan to deprecate them.

Thanks,

DZ.

Oct 23, 2025 12:12:43 'Martijn Katerbarg' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>:

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/SA1PR17MB65031667BD0123B865E96F2DE3F0A%40SA1PR17MB6503.namprd17.prod.outlook.com.

[Martijn Katerbarg]

Hi Dimitris,

A good point. But that relies on the DCV and CAA being done very close to each other, time wise, which may not be the case. 

A DCV could be done in, say, May. The CA sees a valid DCV and is allowed to store it for re-use, but halts issuance due to CAA DNSSEC issues. But then, the DNS spoofing attack is over after a few days. The attacker asks the CA to retry issuance. The CA would be fully in its right to only retry CAA, and poof, the certificate gets issued.

Regards,

Martijn

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/511a4e89-70ae-46d4-ac18-004b350f7285%40harica.gr.

[Dimitris Zacharopoulos]

Thanks Martijn, let me try to describe the threat in my own words to make sure I understood. During the DCV phase, the attacker sends an unsigned fake DNS response about the MX record associated with a Domain Name (example.com), the CA does not check DNSSEC errors and sends the challenge to the inbox of -say- admini...@example.com which ends up to the mail server of the attacker and completes the DCV.

Then the attacker stops the DNS attack and sends a request to issue the certificate, in which case the CA will query the real DNSSEC-signed zone, verify there is no CAA record (or a CAA that allows issuance) and issues the certificate. Is that a fair description of the threat scenario?

If this is a correct description, I would like to ask Henry who's tested equally-specific prefix BGP attacks before (or anyone else with similar experience), how likely and easy it is for such a threat to be executed considering the fact that the fake mail server must be up for some time in order to receive the challenge email.


Thanks,

DZ.

Oct 23, 2025 13:22:31 'Martijn Katerbarg' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>:

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/SA1PR17MB6503A5310F033E76C8684B9BE3F0A%40SA1PR17MB6503.namprd17.prod.outlook.com.

[Michael Richardson]

'Dimitris Zacharopoulos' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:
> Thanks Martijn, let me try to describe the threat in my own words to
> make sure I understood. During the DCV phase, the attacker sends an
> unsigned fake DNS response about the MX record associated with a Domain
> Name (example.com), the CA does not check DNSSEC errors and sends the
> challenge to the inbox of -say- admini...@example.com which ends up
> to the mail server of the attacker and completes the DCV.

Yes. So it seems like if there is DNSSEC, then it needs to be validated.
Seems like an own goal by the CA, as example.com did the right thing with DNSSEC.

> Then the attacker stops the DNS attack and sends a request to issue the
> certificate, in which case the CA will query the real DNSSEC-signed
> zone, verify there is no CAA record (or a CAA that allows issuance) and
> issues the certificate. Is that a fair description of the threat
> scenario?

> If this is a correct description, I would like to ask Henry who's
> tested equally-specific prefix BGP attacks before (or anyone else with
> similar experience), how likely and easy it is for such a threat to be
> executed considering the fact that the fake mail server must be up for
> some time in order to receive the challenge email.

I don't know why you need a BGP attack.
The mail server can be at fubar.attacker.example, and it can just remain live
for as long as they like. I'm not sure if mailenator.com will accept all
email, or just mail to @mailenator.com, but if it accepts anything, then one
could just use that.

[Dimitris Zacharopoulos (HARICA)]

I originally thought one would need to perform a BGP attack to hijack
the IP address of the official mail server but you're right, if the
attacker can spoof the DNS it can change the MX record value to anything
under the attacker's control.

So, assuming the CA performs the DCV process far apart from the
certificate issuance (when it checks CAA), this method does not protect
domain owners as well as the other methods.

I guess from this point on, the big question is if the WG considers this
risk acceptable in light of the deprecation of email/phone methods, and
allow these methods to continue without DNSSEC validation, or not.

Dimitris.

[Martijn Katerbarg]

Hi Dimitris,

>Is that a fair description of the threat scenario?

Indeed it is!

>I guess from this point on, the big question is if the WG considers this risk acceptable in light of the deprecation of email/phone methods, and allow these methods to continue without DNSSEC validation, or not.

Agreed. I think you know my opinion 😉.

I would add that a CA not wanting to do DNSSEC for email methods, might need to introduce more complexity into their systems. I would assume most CAs use 1 pair of DNS resolvers, managed by themselves, for any DCV related activities. If DNSSEC checking is enforced on that resolver, then for any CA to not do DNSSEC for email, they would need to setup an additional pair or resolvers. This increases the risk for misconfigurations and a CA might suddenly find themselves in a spot where they’ve used the wrong one for the wrong method.

Regards,

Martijn

From: 'Dimitris Zacharopoulos (HARICA)' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Friday, 24 October 2025 at 08:57
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: Re: [Servercert-wg] Re: Question about implementation of DNSSEC checks for E-Mail based Domain Validation

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

On 10/23/2025 9:56 PM, Michael Richardson wrote:
> 'Dimitris Zacharopoulos' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:
>      > Thanks Martijn, let me try to describe the threat in my own words to
>      > make sure I understood. During the DCV phase, the attacker sends an
>      > unsigned fake DNS response about the MX record associated with a Domain
>      > Name (example.com), the CA does not check DNSSEC errors and sends the
>      > challenge to the inbox of -say- admini...@example.com which ends up
>      > to the mail server of the attacker and completes the DCV.
>
> Yes.  So it seems like if there is DNSSEC, then it needs to be validated.
> Seems like an own goal by the CA, as example.com did the right thing with DNSSEC.
>
>      > Then the attacker stops the DNS attack and sends a request to issue the
>      > certificate, in which case the CA will query the real DNSSEC-signed
>      > zone, verify there is no CAA record (or a CAA that allows issuance) and
>      > issues the certificate. Is that a fair description of the threat
>      > scenario?
>
>      > If this is a correct description, I would like to ask Henry who's
>      > tested equally-specific prefix BGP attacks before (or anyone else with
>      > similar experience), how likely and easy it is for such a threat to be
>      > executed considering the fact that the fake mail server must be up for
>      > some time in order to receive the challenge email.
>
> I don't know why you need a BGP attack.
> The mail server can be at fubar.attacker.example, and it can just remain live
> for as long as they like.  I'm not sure if mailenator.com will accept all
> email, or just mail to @mailenator.com, but if it accepts anything, then one
> could just use that.

I originally thought one would need to perform a BGP attack to hijack 
the IP address of the official mail server but you're right, if the 
attacker can spoof the DNS it can change the MX record value to anything 
under the attacker's control.

So, assuming the CA performs the DCV process far apart from the 
certificate issuance (when it checks CAA), this method does not protect 
domain owners as well as the other methods.

I guess from this point on, the big question is if the WG considers this 
risk acceptable in light of the deprecation of email/phone methods, and 
allow these methods to continue without DNSSEC validation, or not.

Dimitris.

-- 
You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.
To view this discussion visit https://urldefense.com/v3/__https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/0c434c43-22cd-4e0d-8848-a854d237392f*40harica.gr__;JQ!!J5K_pWsD!3_YHRDKMRVzPFnfjQEFPTjSsZYh1olCrg2qzYMSOBtMqMTWAHEKDJkCoV6eY9y-D8le7ZNhpS8389mkEkop-T_HdnFvHcHk4QhosTHE$.

[Roman Fischer]

Hi Martijn,

 

Just regarding the multiple DNS resolvers thing: At least in our environment we already use two resolvers. One is built-in to the CA system and the other is used for everything else, including outbound e-mail. My guess is that some CAs may even have (or want to) offload the e-mail sending to a cloud service which would also use a separate DNS resolver.

 

Rgds
Roman

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/SA1PR17MB6503ADCF2151336F078EE509E3F1A%40SA1PR17MB6503.namprd17.prod.outlook.com.

[Martijn Katerbarg]

>My guess is that some CAs may even have (or want to) offload the e-mail sending to a cloud service which would also use a separate DNS resolver.

Consider though that there’s two types of email sendings that a CA may do. 1 is, regular emails (invoices, notifications, support, etc etc). All that is fine in cloud.

Then there’s DCV email sending. Using a cloud service for that, and also a cloud DNS resolver for that, would mean the CA is utilizing a Delegated Third Party for DCV, if the mail server and resolver are not controlled by the CA. 

Regards,

Martijn

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/ZR0P278MB0170577B87F9A6B0C1C489CCFAF1A%40ZR0P278MB0170.CHEP278.PROD.OUTLOOK.COM.

[Roman Fischer]

Yes, I'm aware of the Delegated Third Party issue. 👍 Just brought it up because of the recent discussions about possible usage of cloud services. 😉

 

-Roman

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/SA1PR17MB650336D2D54BBFC550EC5849E3F1A%40SA1PR17MB6503.namprd17.prod.outlook.com.

[Dimitris Zacharopoulos (HARICA)]

On 10/24/2025 10:09 AM, 'Martijn Katerbarg' via Server Certificate WG (CA/B Forum) wrote:

Hi Dimitris,

>Is that a fair description of the threat scenario?

Indeed it is!

>I guess from this point on, the big question is if the WG considers this risk acceptable in light of the deprecation of email/phone methods, and allow these methods to continue without DNSSEC validation, or not.

Agreed. I think you know my opinion 😉.

I would add that a CA not wanting to do DNSSEC for email methods, might need to introduce more complexity into their systems. I would assume most CAs use 1 pair of DNS resolvers, managed by themselves, for any DCV related activities. If DNSSEC checking is enforced on that resolver, then for any CA to not do DNSSEC for email, they would need to setup an additional pair or resolvers. This increases the risk for misconfigurations and a CA might suddenly find themselves in a spot where they’ve used the wrong one for the wrong method.

Martijn, I don't think it's that simple, as discussed at the recent validation calls. Although some CAs use local resolvers to directly contact authoritative name servers to perform DNS and HTTP queries, there are a number of CAs relying on external mail service providers (I recall the names of SendGrid, Azure and AWS mail providers coming up in those discussions). I'm not sure the group concluded that those third-party mail providers are considered DTPs. In a similar manner we discussed about mail validation methods relying on regular postal mail, SMS providers, etc. Taking your interpretation about third-party mail providers, leads me to assume that using telephone or third-party SMS providers as part of the DCV process could also be considered DTPs.


Thanks,
Dimitris.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/SA1PR17MB6503ADCF2151336F078EE509E3F1A%40SA1PR17MB6503.namprd17.prod.outlook.com.

[Martijn Katerbarg]

Fair.  I do believe this was discussed in the past, not sure if conclusions were drawn though. 

It’s where you place the line, absolutely, but if you’re placing the line before email servers, then others might draw the line before DNS servers. In my personal opinion, both those lines are incorrect. 

(Perhaps this is the reason many CAs don’t offer these methods)

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/46d9a868-b7f9-48fd-a95c-4540104d5eed%40harica.gr.

[Dimitris Zacharopoulos (HARICA)]

The recent analysis provided by the Chrome team in the SC-90 discussion was very useful. The conclusion I made from this analysis is that the email validation methods are not considered "broken" but not "upgrade-able", and not able to improve their security posture compared to the other DNS/HTTP-based methods which have gained so much from MPIC and DNSSEC. Chris, is that a fair statement?

If that's the case and the deprecation path and timeline for SC-90 is something the WG can agree to, is the DNSSEC enforcement for email DCV methods really necessary at this point, considering the fact that CAs which have not implemented DNSSEC to their email servers will have to make changes, only to deprecate these methods two years later?

Does it make sense to add some language in SC-90 to allow an exception for DNSSEC enforcement in the email DCV methods until these methods are deprecated?


Thank you,
Dimitris.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/SA1PR17MB6503F68A291621588BEEAB7EE3FCA%40SA1PR17MB6503.namprd17.prod.outlook.com.

[Chris Clements]

The recent analysis provided by the Chrome team in the SC-90 discussion was very useful. The conclusion I made from this analysis is that the email validation methods are not considered "broken" but not "upgrade-able", and not able to improve their security posture compared to the other DNS/HTTP-based methods which have gained so much from MPIC and DNSSEC. Chris, is that a fair statement?

The “not upgrade-able” characterization seems accurate, but it’s also a symptom of the larger issue, which is that these validation methods are already at a deficit from a security-by-design perspective. They rely on a less direct proof of control, inherit systemic vulnerabilities from the entire email ecosystem, and present a broader attack surface than the alternatives.

If that's the case and the deprecation path and timeline for SC-90 is something the WG can agree to, is the DNSSEC enforcement for email DCV methods really necessary at this point, considering the fact that CAs which have not implemented DNSSEC to their email servers will have to make changes, only to deprecate these methods two years later?

Does it make sense to add some language in SC-90 to allow an exception for DNSSEC enforcement in the email DCV methods until these methods are deprecated?

SC-090's objective is the full deprecation of those methods due to their inherent risk. While it may have gone unnoticed to some, SC-090’s preamble acknowledges the DNSSEC challenges for email-based methods. The ballot attempts to mitigate this risk by discouraging, but not prohibiting, their use upon SC-085 becoming effective (example). This intends to balance short-term tradeoffs while realizing the long-term benefit.

Generally speaking, we think ecosystem resources should focus on continued migration to more secure, modern methods, rather than temporarily hardening phone- and email-based ones.

Regardless, if the community feels explicit exemptions for SC-085 are necessary, we believe they should occur in a separate and targeted ballot rather than being commingled with SC-090's existing text. This approach is consistent with past working group discussions on managing ballot scope and complexity, just as the community agreed that SC-091's contents, though closely related to SC-090, were best served by a separate ballot.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/d84d3489-8be1-4272-a48e-6abb95693eb2%40harica.gr.

[Dimitris Zacharopoulos (HARICA)]

On 11/5/2025 4:02 PM, 'Chris Clements' via Server Certificate WG (CA/B Forum) wrote:

The recent analysis provided by the Chrome team in the SC-90 discussion was very useful. The conclusion I made from this analysis is that the email validation methods are not considered "broken" but not "upgrade-able", and not able to improve their security posture compared to the other DNS/HTTP-based methods which have gained so much from MPIC and DNSSEC. Chris, is that a fair statement?

The “not upgrade-able” characterization seems accurate, but it’s also a symptom of the larger issue, which is that these validation methods are already at a deficit from a security-by-design perspective. 

Thanks for the confirmation.

They rely on a less direct proof of control, inherit systemic vulnerabilities from the entire email ecosystem, and present a broader attack surface than the alternatives.

While the assumption about non-"direct proof of control" is accurate, when the CA/B Forum discussed the security properties of each method in 2017 (ballot 190), it was deemed that some cases of indirect proof of control was sufficiently secure. Of course some methods have been reconsidered and demonstrated to have significant security flaws, and the WG did not hesitate to deprecate in a short timeframe. I don't believe the same applies to the current email validation methods, despite being an indirect proof of control over a Domain Name.

If that's the case and the deprecation path and timeline for SC-90 is something the WG can agree to, is the DNSSEC enforcement for email DCV methods really necessary at this point, considering the fact that CAs which have not implemented DNSSEC to their email servers will have to make changes, only to deprecate these methods two years later?

Does it make sense to add some language in SC-90 to allow an exception for DNSSEC enforcement in the email DCV methods until these methods are deprecated?

SC-090's objective is the full deprecation of those methods due to their inherent risk. While it may have gone unnoticed to some, SC-090’s preamble acknowledges the DNSSEC challenges for email-based methods. The ballot attempts to mitigate this risk by discouraging, but not prohibiting, their use upon SC-085 becoming effective (example). This intends to balance short-term tradeoffs while realizing the long-term benefit.

Generally speaking, we think ecosystem resources should focus on continued migration to more secure, modern methods, rather than temporarily hardening phone- and email-based ones.

It appears we are in agreement that temporarily hardening methods is unnecessary, when there is a plan to migrate to more secure methods.

Regardless, if the community feels explicit exemptions for SC-085 are necessary, we believe they should occur in a separate and targeted ballot rather than being commingled with SC-090's existing text. This approach is consistent with past working group discussions on managing ballot scope and complexity, just as the community agreed that SC-091's contents, though closely related to SC-090, were best served by a separate ballot.

I may have missed something but during the discussion of SC-091 it was decided that instead of having two separate ballots, the WG would achieve two things at the same time:

• the deprecation of a possibly problematic validation method; and
• the introduction of a more secure validation method that replaces the older method.

I don't see this a lot different than SC-90, which introduces a deprecation plan but at the same time it could present an exception for email validation methods (that are scheduled for deprecation). Otherwise, if there was an attempt to add a DNSSEC exception alone via a separate ballot, without the deprecation of the corresponding email DCV methods, it would be an unrestricted risk. Adding them in the same ballot seems like a safer approach.

Does that make sense? 

To be as clear as possible, if there was a distinct ballot to add an exception without securing the deprecation plan, I wouldn't vote for it :-)


Thanks,
Dimitris.

[Chris Clements]

Hi Dimitris,

To clarify our perspective, when we discussed SC-090 at the 2025-09-04 Validation Subcommittee, we also considered including the contents of what is now SC-091 within SC-090’s scope. The group concluded that despite these work items being related and motivated by a shared problem, narrowly focused ballots are best and allow targeted discussion. 

To maintain consistency with that principle of creating narrowly focused ballots, while also avoiding unnecessary or risky dependencies, we still think it would be most effective to address potential DNSSEC exception(s) as a separate work item, especially since:

1. The idea of an exception was just recently raised in this thread about 2 weeks ago, and consensus on the path forward is not yet clear.

2. The relevant DNSSEC requirements do not take effect until March 2026, allowing ample time for a thorough, dedicated discussion.

Thank you

-Chris

--

You received this message because you are subscribed to the Google Groups "Server Certificate WG (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to servercert-w...@groups.cabforum.org.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/591e7b90-f09e-4f21-b504-f30c0e8a3db0%40harica.gr.