Voting Period Begins - Ballot SC-082: "Clarify CA Assisted DNS Validation under 3.2.2.4.7"

[Slaughter, Michael]

Closing the discussion period and opening up the voting period.

 

Ballot SC-082 is proposed by Michael Slaughter (Amazon Trust Services) and endorsed by Martijn Katerbarg (Sectigo) and Wayne Thayer (Fastly).

 

— Purpose of Ballot SC-082 —

 

The purpose of this ballot is to clarify the practice of CA Assisted DNS Validation and add constraints under Method 7 (3.2.4.4.7 DNS Change). Modification of other domain validation methods and the introduction of new domain validation methods are not in scope of this ballot but may be addressed in a future ballot.

 

Background:

 

CA Assisted DNS Validation is the practice where Certification Authorities (CAs) instruct Applicants to create Canonical Name (CNAME) records specifically for the purpose of assisting the Applicant with Domain Control Verification (DCV) of their domain.

At F2F 59 (July 23’), the Validation Subcommittee of the Server Certificate WG presented the following conclusions on the practice of CA Assisted DNS Validation:

• More clarity is needed around the practice
• Applicants generally delegate the performance of many aspects of operating a website.
• If done correctly, allowing Applicants to delegate the placement of the Random Value/ Request Token boosts agility and automation.
• There are reasonable interpretations of the BRs that such delegation is already allowed today.

A tiger team was formed to threat model CA Assisted DNS Validation and propose modifications to the BRs to add clarity and constraints around the practice under section 3.2.2.4.7. The results of the threat model exercise [1] were presented and discussed at F2F 60 [2] and F2F 61 [3].

 

Overview of Changes:

• New definition: Canonical Authorization Domain Name
• Add Canonical Authorization Domain Names into section 3.2.2.4.7 (DNS Change)
• Addition of constraints around the usage of Canonical Authorization Names by CAs
  • Enforce CNAMEs are unique to an Applicant and not shared with multiple Applicants
  • Expire DNS lookup results after 8 hours
  • Restrict the type of DNS records located in zones used for this purpose.

 

References:

[1] Validation SC Threat Modeling Doc: https://docs.google.com/document/d/1G2GYb0eg0rqE23f844J8qs7RYGU1jFVDsU5Pf7UYg3g/edit

[2] F2F-60 Presentation: https://docs.google.com/presentation/d/1M80h1N7MpBuqvZS0FdtJ_zj-AsaFxu7BNBSUJ6Ia5jU/edit?usp=sharing

[3] F2F-61 Presentation: https://docs.google.com/presentation/d/1rKW7I5jOYh37jQFtd1S-fKIs0j-dCAyUUU-fq_C8UKw/edit?usp=sharing

[4] https://github.com/cabforum/servercert/pull/501

 

The following motion has been proposed by Michael Slaughter (Amazon Trust Services) and endorsed by Martijn Katerbarg (Sectigo) and Wayne Thayer (Fastly)

 

GitHub pull request for this ballot: https://github.com/cabforum/servercert/pull/501

 

— Motion Begins —

 

MODIFY the "Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates" ("TLS Baseline Requirements") based on Version 2.0.9 as specified in the following redline:

https://github.com/cabforum/servercert/compare/911e47e2657de64a7455ba16319b96ffdb5816cd..76f6e1b7a39f44f6e7b5a1bc0c4a0df744457d84

 

— Motion Ends —

 

 

This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows:

 

Discussion (7 days)

 

- Start: 2024-11-12 17:30:00 UTC

- End no earlier than: 2024-11-19 17:30:00 UTC

 

Vote for approval (7 days)

 

- Start: 2024-11-20 18:30:00 UTC

- End:  2024-11-27 18:30:00 UTC

 

 

 

[Clint Wilson]

Hello,

I apologize for the tardiness of this email, in relation to the discussion period for SC-082. I have a few points of feedback that I’d like to understand better from the perspective of the ballot author and endorsers.

Canonical Authorization Domain Name

This ballot introduces a new definition for a Canonical Authorization Domain Name (CADN), however it’s not clear how this is a new concept — or whether it’s intended to be. An Authorization Domain Name (ADN) includes in its scope the RDATA values of CNAME records located at the ADN and 3.2.2.4.7 includes in its scope an ADN prefixed with an underscore character.

FQDN = example.com

3.2.2.4.7 -> _domainlabel.example.com

ADN -> _domainlabel.example.com. IN CNAME otherdomain.com

otherdomain.com is then both the/an Authorization Domain Name and the Canonical Authorization Domain Name, based on the definitions. Am I correct in understanding that the purpose of defining the CADN is to specify exactly this form of ADN, in order to differentiate it from any other possible formulation of an ADN? Is this term intended to convey any other intrinsic property, separate from a “basic” ADN?

Adding to Method 7

A major concern I have with this proposal is its addition of this approach to domain validation to the existing 3.2.2.4.7 method. Separating out the operation of CADNs by CAs is necessary to ensure the use of this validation method is appropriately scoped and implemented, now and if further refinement is required in the future. As noted in 3.2.2.4, "CAs SHALL maintain a record of which domain validation method, including relevant BR version number, they used to validate every domain.” If this method is not separated out, it may not be reliably ascertained after the fact whether a domain was validated using 3.2.2.4.7 as it exists today or through reliance on the CA’s operation of a CADN. 

Given the new factors and participants added to the domain validation process in this ballot, I don’t believe it should be treated as an extension of 3.2.2.4.7 and instead should be added as a new validation method in 3.2.2.4.21 — perhaps with some additional constraints to ensure a higher degree of confidence that the use of this method does not enable abuse of the Web PKI.

It should not be overshadowed the level to which this changes the TLS security model. By delegating an Authorization Domain Name to the CA, the CA arguably (as written today) becomes an Applicant Representative which introduces an explicitly approved channel through which a CA could request and issue certificates to themselves (or another party). Note that the threat model’s assumption of account separation mechanisms being effective is irrelevant in this regard as this ballot does not limit issuance to individual accounts. It’s not clear whether this interaction was intended or considered, so perhaps I’m missing something which prevents this scenario from playing out.

As a side note, as with many ballots, it seems like a future effective date would be worthwhile to ensure that there is adequate time for systems changes, rather than incentivizing, to any extent, an unnecessarily quick implementation timeline.

Certification

My final overarching concern with this validation method is its instantiation of a relationship which further distances the certification process described by the TLS Baseline Requirements from resulting in a certificate which directly binds a public key to a domain name where that binding is explicitly and individually granted by the holder/owner of both the public key and the domain name.

This is, perhaps, somewhat of a philosophical concern, but from the perspective of a relying party, the ideal outcome of a TBR-compliant certificate is a 1:1 relationship between the validation of data (domain control <> public key) by an RA and the certification of that data by a CA. In this idealized scenario, each public key would be individually validated as an authorized public key for a given FQDN — this would provide the highest degree of assurance to relying parties. The reuse of any validation inherently distances reality from this ideal. Quoting from https://cseweb.ucsd.edu/~goguen/courses/275f00/geer.html: "a trust management paradigm says that a digital signature is only as valid as the key (in which it was signed) was at the moment of signature”.

This method introduces an abundance of convenience, and I don’t want to downplay that. However, I think along with that comes a tradeoff in which relying parties find themselves relying upon a relationship between a CA and Subscriber, represented through the one-time creation of a DNS record which does not naturally expire or require interaction to maintain. Instead of a certificate representing the authorization of a key, it represents the authorization of a business relationship. The risks associated with that shift are strongly — but not solely — tied to (shorter) certificate lifetimes and validation data reuse periods. To an extent, the adoption of this ballot would further emphasize the need for SC-081, possibly even increasing its urgency.

To be clear, I’m not requesting a change to this ballot to directly address this, rather I wanted to highlight this aspect of the ballot in case it’s something others don't agree with, see differently, or weren’t aware of as a perspective. I do think this shift is worth consideration when determining whether this method is suitable for addition to the TBRs as-is.

Thanks!

-Clint

-- 
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/591A7733-9F52-4049-9B88-9B9274F3C78E%40amazon.com.

[Slaughter, Michael]

Hi Clint,

 

Given that the voting period for this ballot has opened, I will specifically address the questions, suggestions and claims related to the language in this ballot. I apologize if I missed something.

 

As stated in the purpose section of the ballot, the intent of this ballot is to clarify and constrain an existing capability of CAs under method 3.2.4.4.7 rather than introduce or confer CAs new capabilities.

 

Question: Is [Canonical Authorization Domain Name] intended to convey any other intrinsic property, separate from a “basic” ADN?

• Response: The purpose of the CADN definition is to 1) enhance the readability of the ballot language and 2) restrict that the ADNs used for this purpose to subdomains of a ca operated domain prefixed with an underscore. In your example, the CADN would be “_applicant-unique-prefix.otherdomain.com” rather than “otherdomain.com”.

 

Suggestion: Include a future effective date to allow for any required changes to systems.

• Response: I have not received feedback regarding an effective date or the need for one which is why it was not included. I would appreciate feedback from CAs on 1) if an effective date is required at all for the changes included in this ballot and 2) and if so, what a reasonable effective date might be.

 

Suggestion: Consider adding this as a new validation method (3.2.2.4.21) instead of as an extension to 3.2.2.4.7.

• Response: The purpose of this ballot is to clarify and constrain the practice of CA assisted DNS validation in the context of method 7. This course of action was decided based off of the conclusions presented at F2F59 made by the validation subcommittee after years of discussion and that there are reasonable interpretations of the BRs that this practice is already allowed today. As you may recall, we decided the first step was to clarify the practice under method 7. Creating a new validation method with additional constraints as you suggested is a fruitful idea that has always been considered the logical next step following this 3.2.2.4.7 clarification ballot.

 

Claim: “By delegating an Authorization Domain Name to the CA, the CA arguably (as written today) becomes an Applicant Representative.”

• Response: I do not believe there is anything in the current proposed ballot language that could reasonably be interpreted as changing the status of a “CA” to a natural person or human sponsor who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant: Existence of a CADN does make the CA an authorized agent who:
  • signs and submits, or approves a certificate request on behalf of the Applicant, and/or
  • signs and submits a Subscriber Agreement on behalf of the Applicant, and/or
  • acknowledges the Terms of Use on behalf of the Applicant when the Applicant is an Affiliate of the CA or is the CA.

 

Claim: “[this ballot] introduces an explicitly approved channel through which a CA could request and issue certificates to themselves (or another party)”

• Response: This ballot does not include language that grants CAs the ability to request and issue certificates to themselves (or another party).

 

Claim: The risks associated with [the one-time creation of a DNS record which does not naturally expire or require interaction to maintain] are strongly — but not solely — tied to (shorter) certificate lifetimes and validation data reuse period.“

• Response: This ballot does not address (nor is it intended to address) concerns related to certificate validity and domain validation reuse periods. As you identified, those are rightfully being discussed and considered for all domain validation methods in SC-81.

 

Thanks,
M. Slaughter

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/8C4354F9-61D5-4FB8-BBD3-0C7F1B24B7B4%40apple.com.

[Slaughter, Michael]

I need to correct/clarify my answer to the Canonical Authorization Domain Name question I provided below.

 

Question: Is [Canonical Authorization Domain Name] intended to convey any other intrinsic property, separate from a “basic” ADN?

• Response:  The purpose of the CADN definition is to 1) enhance the readability of the ballot language and 2) convey the structure of the CNAME used for this purpose. It specifies that the CNAME “Name” is an underscore prefixed subdomain of the domain being validated and that the CNAME “RDATA” is where the CADN is located. In your example, the CADN would be “applicant-account-binding-id.otherdomain.com” rather than “otherdomain.com”.

 

Thanks,

 

M. Slaughter

[Clint Wilson]

Hi Slaughter,

On Nov 21, 2024, at 7:21 AM, 'Slaughter, Michael' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org> wrote:

Hi Clint, 

 

Given that the voting period for this ballot has opened, I will specifically address the questions, suggestions and claims related to the language in this ballot. I apologize if I missed something.

 

As stated in the purpose section of the ballot, the intent of this ballot is to clarify and constrain an existing capability of CAs under method 3.2.4.4.7 rather than introduce or confer CAs new capabilities.

 

Question: Is [Canonical Authorization Domain Name] intended to convey any other intrinsic property, separate from a “basic” ADN?

• Response:  The purpose of the CADN definition is to 1) enhance the readability of the ballot language and 2) convey the structure of the CNAME used for this purpose. It specifies that the CNAME “Name” is an underscore prefixed subdomain of the domain being validated and that the CNAME “RDATA” is where the CADN is located. In your example, the CADN would be “applicant-account-binding-id.otherdomain.com” rather than “otherdomain.com”.

To confirm, within the scope of the BRs today, would "applicant-account-binding-id.otherdomain.com” be considered a valid ADN today? That is, this structure of forming an ADN from CNAME records exists today and a CADN solely as defined in the ballot can exist today?

Suggestion: Include a future effective date to allow for any required changes to systems.

• Response: I have not received feedback regarding an effective date or the need for one which is why it was not included. I would appreciate feedback from CAs on 1) if an effective date is required at all for the changes included in this ballot and 2) and if so, what a reasonable effective date might be. 

 

Suggestion: Consider adding this as a new validation method (3.2.2.4.21) instead of as an extension to 3.2.2.4.7.

• Response: The purpose of this ballot is to clarify and constrain the practice of CA assisted DNS validation in the context of method 7. This course of action was decided based off of the conclusions presented at F2F59 made by the validation subcommittee after years of discussion and that there are reasonable interpretations of the BRs that this practice is already allowed today. As you may recall, we decided the first step was to clarify the practice under method 7. Creating a new validation method with additional constraints as you suggested is a fruitful idea that has always been considered the logical next step following this 3.2.2.4.7 clarification ballot. 

From this, it sounds like the ballot did take into consideration the past disagreements (and associated recommendations/proposals) with the conclusion that the process described therein is currently allowed; am I understanding that correctly?

Claim: “By delegating an Authorization Domain Name to the CA, the CA arguably (as written today) becomes an Applicant Representative.”

• Response: I do not believe there is anything in the current proposed ballot language that could reasonably be interpreted as changing the status of a “CA” to a natural person or human sponsor who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant: Existence of a CADN does make the CA an authorized agent who:
  • signs and submits, or approves a certificate request on behalf of the Applicant, and/or
  • signs and submits a Subscriber Agreement on behalf of the Applicant, and/or
  • acknowledges the Terms of Use on behalf of the Applicant when the Applicant is an Affiliate of the CA or is the CA. 

In the current ballot it states: “…. Applicants to add a CNAME record containing a Canonical Authorization Domain Name controlled by the CA.” If the CA controls the Canonical Authorization Domain Name, the CA is now operating infrastructure which is representing the Applicant, expressly granted by the Applicant. This seems well in line with interpretations we’ve seen on numerous occasions in the Web PKI.

From the F2F 60 presentation, it appears that at one point the intent was to enforce a rule which ensured a unique account binding, however this doesn’t appear present in the ballot and (in part) leads to the concern highlighted here.

Claim: “[this ballot] introduces an explicitly approved channel through which a CA could request and issue certificates to themselves (or another party)”

• Response: This ballot does not include language that grants CAs the ability to request and issue certificates to themselves (or another party). 

Is an Applicant Representative able to request Certificates on behalf of an Applicant?

Is there language in the TBRs which provides clear, unequivocal restrictions which prevent a CA from qualifying and acting as an Applicant Representative?

Does this ballot introduce language that establishes a relationship between an Applicant and a CA wherein the CA represents the Applicant to the CA for the purpose and within the process of validating control of an Applicant’s Domain?

Claim: The risks associated with [the one-time creation of a DNS record which does not naturally expire or require interaction to maintain] are strongly — but not solely — tied to (shorter) certificate lifetimes and validation data reuse period.“

• Response: This ballot does not address (nor is it intended to address) concerns related to certificate validity and domain validation reuse periods. As you identified, those are rightfully being discussed and considered for all domain validation methods in SC-81.  

My understanding here is that there are known risks associated with the changes included in this ballot that the ballot intentionally does not address. To be clear, I’m not trying to indicate that it should, but I am trying to understand the intent.

Thank you,

-Clint

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/24BD68A9-87C7-4A21-9279-A91C62096EDB%40amazon.com.

[Michael Slaughter]

Hi Clint, 

Responses below. 

To confirm, within the scope of the BRs today, would “applicant-account-binding-id.otherdomain.com” be considered a valid ADN today? That is, this structure of forming an ADN from CNAME records exists today and a CADN solely as defined in the ballot can exist today?

That is correct. The intent of this definition is not to create a new concept but rather constrain the usage of existing concepts in a specific context. An Applicant today has the ability to configure a CNAME from an underscore-prefixed subdomain they control to a DNS location where the TXT token resides the Applicant may or may not control.

From this, it sounds like the ballot did take into consideration the past disagreements (and associated recommendations/proposals) with the conclusion that the process described therein is currently allowed; am I understanding that correctly?

That is correct. The validation subcommittee conclusions, the threat modeling exercise, F2F presentations directly led to the ballot language presented here. That context was referenced in the Threat model, the presentations, the ballot text and the ballot preamble.

In the current ballot it states: “…. Applicants to add a CNAME record containing a Canonical Authorization Domain Name controlled by the CA.” If the CA controls the Canonical Authorization Domain Name, the CA is now operating infrastructure which is representing the Applicant, expressly granted by the Applicant. This seems well in line with interpretations we’ve seen on numerous occasions in the Web PKI.

From the F2F 60 presentation, it appears that at one point the intent was to enforce a rule which ensured a unique account binding, however this doesn’t appear present in the ballot and (in part) leads to the concern highlighted here

The ballot includes the following language: “the CA MUST ensure that each Canonical Authorization Domain Name is used for a unique Applicant, and not shared across multiple Applicants”. The ballot does not intend to define how a CA models applicants into accounts.

Is an Applicant Representative able to request Certificates on behalf of an Applicant?

Is there language in the TBRs which provides clear, unequivocal restrictions which prevent a CA from qualifying and acting as an Applicant Representative?

Does this ballot introduce language that establishes a relationship between an Applicant and a CA wherein the CA represents the Applicant to the CA for the purpose and within the process of validating control of an Applicant’s Domain?

While these are interesting questions, I think definitively answering them is out of scope for this ballot. The reason is that the answers apply not just to a modified Method 7 but also to any existing domain validation method, including Method 7 as it stands today.

My understanding here is that there are known risks associated with the changes included in this ballot that the ballot intentionally does not address. To be clear, I’m not trying to indicate that it should, but I am trying to understand the intent.

As we discussed during the Threat Modeling meetings, the perspective of this ballot is that there are numerous threats that exist today under Method 7. The intent of the exercise and this ballot was to identify a set of mitigations for those threats that work to ensure that CAs that currently (or plan to) assist Applicants with automation do so under a reasonable set of constraints.

Thanks,

M. Slaughter  

[Clint Wilson]

Hi Slaughter,

I’ve responded in-line below:

To confirm, within the scope of the BRs today, would “applicant-account-binding-id.otherdomain.com” be considered a valid ADN today? That is, this structure of forming an ADN from CNAME records exists today and a CADN solely as defined in the ballot can exist today?

That is correct. The intent of this definition is not to create a new concept but rather constrain the usage of existing concepts in a specific context. An Applicant today has the ability to configure a CNAME from an underscore-prefixed subdomain they control to a DNS location where the TXT token resides the Applicant may or may not control.

From this, it sounds like the ballot did take into consideration the past disagreements (and associated recommendations/proposals) with the conclusion that the process described therein is currently allowed; am I understanding that correctly?

That is correct. The validation subcommittee conclusions, the threat modeling exercise, F2F presentations directly led to the ballot language presented here. That context was referenced in the Threat model, the presentations, the ballot text and the ballot preamble.

To be clear, these are conclusions reached by, perhaps, a majority of those involved, but which never reached a clear consensus — namely with regards to the consistent objections I have raised. I am absolutely not disputing the validity of this ballot nor its adoption, but I wanted to be sure that these outstanding protestations had been understood — in particular because I did not manage to contribute this latest reiteration of that position during the Discussion Period of this ballot.

In the current ballot it states: “…. Applicants to add a CNAME record containing a Canonical Authorization Domain Name controlled by the CA.” If the CA controls the Canonical Authorization Domain Name, the CA is now operating infrastructure which is representing the Applicant, expressly granted by the Applicant. This seems well in line with interpretations we’ve seen on numerous occasions in the Web PKI.

From the F2F 60 presentation, it appears that at one point the intent was to enforce a rule which ensured a unique account binding, however this doesn’t appear present in the ballot and (in part) leads to the concern highlighted here

The ballot includes the following language: “the CA MUST ensure that each Canonical Authorization Domain Name is used for a unique Applicant, and not shared across multiple Applicants”. The ballot does not intend to define how a CA models applicants into accounts.

Yes, this is clear and remains an unaddressed issue with adopting this ballot. As the threat analysis highlights, there are difficult challenges which need to be meaningfully addressed before this validation method should be widely deployed, and certainly before it can be accepted as a compliant validation method within the TBRs (in my opinion). This has been my message throughout the years of discussion you reference in the ballot explainer; initially as a hypothesis which I helped test through the threat analysis, but has, since the conclusion of that analysis, been a clearly maintained position. 

I have been similarly consistent, I hope, in conveying and confirming my support for adding a method which enables delegation of domains to a CA for the purposes of domain validation if done properly, with sufficient and clear security boundaries. I similarly worked to help identify the set of initial properties those boundaries may need to be composed of, though with an understanding that further exploration of the effectiveness of those protections in the context of a concrete proposal adding a new domain validation method of this variety would be warranted and necessary. I recognize the concepts of adding a new method and adding text to an existing method have a fair amount of overlap, and it’s been quite some time since the threat analysis concluded, so perhaps my support for the one option and objection to the other did not remain distinctly understood in the interim.

Is an Applicant Representative able to request Certificates on behalf of an Applicant?

Is there language in the TBRs which provides clear, unequivocal restrictions which prevent a CA from qualifying and acting as an Applicant Representative?

Does this ballot introduce language that establishes a relationship between an Applicant and a CA wherein the CA represents the Applicant to the CA for the purpose and within the process of validating control of an Applicant’s Domain?

While these are interesting questions, I think definitively answering them is out of scope for this ballot. The reason is that the answers apply not just to a modified Method 7 but also to any existing domain validation method, including Method 7 as it stands today.

The first two questions certainly are relevant to the TBRs as a whole, independent of this ballot. However, the third is very much clearly in scope of this ballot as it is the thing introducing the language I’m highlighting as a concern — especially when considering the context of my stated disagreement with the interpretation that the current TBRs already allow the delegation described in this ballot.

My understanding here is that there are known risks associated with the changes included in this ballot that the ballot intentionally does not address. To be clear, I’m not trying to indicate that it should, but I am trying to understand the intent.

As we discussed during the Threat Modeling meetings, the perspective of this ballot is that there are numerous threats that exist today under Method 7. The intent of the exercise and this ballot was to identify a set of mitigations for those threats that work to ensure that CAs that currently (or plan to) assist Applicants with automation do so under a reasonable set of constraints.

I agree, that was one side of the discussion. Another side being that mitigations for those threats are misplaced given that there is no consensus that this method is currently allowed, and thus the origin for those threats a non-factor for the purposes of adding a validation method which provides for this form of delegation — which was, of course, the stated desire when this proposal was first raised. Threats which exist independent of the “allowable” interpretation of this method can and should be addressed independent of this ballot. Threats which exist as part of this ballot, including subsequent increases to preexisting threats, should be addressed within a ballot seeking to add the desired validation method.

I’m trying to be direct and clear in my responses here, but I hope that has not caused my tone to come across negatively as that is definitely not my intent. From your responses here, it sounds like there may be (and have been) a solid understanding of my historical concerns, in which case I apologize for making much ado about nothing. On the off chance my concerns were not fully understood by all, then hopefully this was helpful to some small extent.

Regards,

-Clint

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/cde9088e-beeb-478d-8989-9fad9e3c591en%40groups.cabforum.org.

[Ponds-White, Trev]

Amazon Trust Services votes yes.

 

From: 'Slaughter, Michael' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, November 20, 2024 10:28
To: server...@groups.cabforum.org
Subject: [EXTERNAL] [Servercert-wg] Voting Period Begins - Ballot SC-082: "Clarify CA Assisted DNS Validation under 3.2.2.4.7"

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

 

--

[Doug Beattie]

GlobalSign votes Yes on Ballot SC-082.

 

Doug

 

From: 'Slaughter, Michael' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>

--

[Bruce Morton]

Entrust votes Yes to ballot SC-082.

 

 

Bruce.

 

From: 'Slaughter, Michael' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, November 20, 2024 1:28 PM
To: server...@groups.cabforum.org

--

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/591A7733-9F52-4049-9B88-9B9274F3C78E%40amazon.com.

Any email and files/attachments transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

[Kateryna Aleksieieva]

Certum votes YES on Ballot SC-082

Kind regards,

Kateryna Aleksieieva

---

From: 'Slaughter, Michael' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>

Sent: Wednesday, November 20, 2024 19:28
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-082: "Clarify CA Assisted DNS Validation under 3.2.2.4.7"

 

--

[Dimitris Zacharopoulos (HARICA)]

HARICA abstains. It appears that more discussion is required to reach consensus.

Dimitris.

--

[Ben Wilson]

Mozilla abstains from voting on Ballot SC-082.

--

[Wayne Thayer]

Fastly votes Yes on ballot SC-082.

- Wayne

[Tim Hollebeek]

DigiCert votes YES on SC-082.

 

-Tim

 

From: 'Slaughter, Michael' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, November 20, 2024 1:28 PM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-082: "Clarify CA Assisted DNS Validation under 3.2.2.4.7"

 

Closing the discussion period and opening up the voting period.

--

[Silva, Marcelo]

Visa votes Yes to Ballot SC-082.

Marcelo

 

From: 'Slaughter, Michael' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, November 20, 2024 1:28 PM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-082: "Clarify CA Assisted DNS Validation under 3.2.2.4.7"

 

Closing the discussion period and opening up the voting period.

--

[Clint Wilson]

Apple votes NO on SC-082.

[Scott Rea]

eMudhra votes YES on Ballot SC-082

---

From: 'Slaughter, Michael' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>

Sent: Wednesday, November 20, 2024 10:28:33 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>

Subject: [Servercert-wg] Voting Period Begins - Ballot SC-082: "Clarify CA Assisted DNS Validation under 3.2.2.4.7"

CAUTION: This email is originated from outside of the organization. Do not open the links or the attachments unless you recognize the sender and know the content is safe.

--

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/591A7733-9F52-4049-9B88-9B9274F3C78E%40amazon.com.

Disclaimer: The email and its contents hold confidential information and are intended for the person or entity to which it is addressed. If you are not the intended recipient, please note that any distribution or copying of this email is strictly prohibited as per Company Policy, you are requested to notify the sender and delete the email and associated attachments with it from your system.

[郭宗閔]

Chunghwa Telecom votes YES on Ballot SC-082

 

Regards,

Tsung-Min Kuo

--

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/591A7733-9F52-4049-9B88-9B9274F3C78E%40amazon.com.

 

本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.

[仇大伟]

CFCA votes Yes to Ballot SC-082.

qiudawei

-----原始邮件-----
发件人: "'Slaughter, Michael' via Server Certificate WG (CA/B Forum)" <server...@groups.cabforum.org>
发送时间: 2024-11-21 02:28:18 (星期四)
收件人: "server...@groups.cabforum.org" <server...@groups.cabforum.org>
主题: [Servercert-wg] Voting Period Begins - Ballot SC-082: "Clarify CA Assisted DNS Validation under 3.2.2.4.7"

[蔡家宏(chtsai)]

TWCA  votes "yes" on ballot SC-082.

Best Regards

 

蔡家宏 Chya-Hung Tsai

Director

Identification & Certificate Research
Tel: +886-2-2370-8886 ext. 722
Fax: +886-2-2388-6720
Email: cht...@twca.com.tw

10F., No. 85, Yanping South Road,

Taipei 100002, Taiwan(R.O.C.)
https://www.twca.com.tw

 

From: 'Slaughter, Michael' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>

Sent: Thursday, November 21, 2024 2:28 AM
To: server...@groups.cabforum.org

--

[大野 文彰]

SECOM Trust Systems votes ABSTAINS on Ballot SC-082.

We believe more discussion is preferable.

 

Best Regards,

 

ONO, Fumiaki

SECOM Trust Systems Co., Ltd.

 

From: 'Slaughter, Michael' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Thursday, November 21, 2024 3:28 AM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-082: "Clarify CA Assisted DNS Validation under 3.2.2.4.7"

 

Closing the discussion period and opening up the voting period.

--

[Pedro FUENTES]

OISTE votes YES on SC-082.

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

WISeKey SA

Pedro Fuentes
CSO - Trust Services Manager
Office: + 41 (0) 22 594 30 00
Mobile: + 41 (0) 791 274 790

Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland

Stay connected with WISeKey

THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks

CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender

DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.

[Backman, Antti]

Telia votes ’Yes’ on Ballot SC-82.

 

//Antti

 

From: 'Slaughter, Michael' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Wednesday, 20. November 2024 at 20.29
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-082: "Clarify CA Assisted DNS Validation under 3.2.2.4.7"

--

[Michael Guenther]

SwissSign votes 'yes' on SC-082

 

Mike

 

From: 'Slaughter, Michael' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: Wednesday, November 20, 2024 7:28 PM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-082: "Clarify CA Assisted DNS Validation under 3.2.2.4.7"

 

Closing the discussion period and opening up the voting period.

--

[Mads Egil Henriksveen]

Buypass ABSTAINS from voting on ballot SC-082. We agree with Dimitris that more discussion is required.

 

Regards

Mads

 

 

From: 'Slaughter, Michael' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Sent: onsdag 20. november 2024 19:28
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-082: "Clarify CA Assisted DNS Validation under 3.2.2.4.7"

 

Closing the discussion period and opening up the voting period.

--

[Marco Schambach]

IdenTrust votes “Yes” on Ballot SC-082

 

Marco S.

TrustID Program Manager

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

[Martijn Katerbarg]

Sectigo votes YES to ballot SC-82.

 

While we agree with some of the comments made by Clint / Apple, we remain supportive of the ballot in its current state.

 

In our opinion, CA Assisted DNS Validation is an enhancement and specific allowance for a practice within the scope of an existing validation method. While we can see why it might be beneficial to scope this into a completely new defined validation method, we would raise that the same should in that case go for DNS TXT vs DNS CNAME, as well as DNS validation using Random Value vs DNS validation using Request Tokens.

 

Such a separation specification would however (in our opinion) be reasonable to perform through a subsequent ballot, rather than the current SC-82.

Should SC-82 ultimately fail, we would be supportive of a ballot making further changes to the DCV methods within the BRs, including the proposed options of ballot SC-82.

[Andrea Holland]

VikingCloud votes Yes on SC-082.

 

Regards,

Andrea Holland

--

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/eac47c9f-9fd3-4c25-9aa7-8d19c7d38341n%40groups.cabforum.org.

Company Registration Details
VikingCloud is the registered business name of Sysxnet Limited. Sysxnet Limited is registered in Ireland under company registration number 147176 and its registered office is at 1st Floor, Block 71a, The Plaza, Park West Business Park, Dublin 12, Ireland.

Email Disclaimer
The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Sysxnet Limited is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt..

[sde...@godaddy.com]

GoDaddy votes YES to Ballot SC-082

 

Cheers,

Steven

 

From: 'Slaughter, Michael' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>
Date: Wednesday, November 20, 2024 at 12:28 PM
To: server...@groups.cabforum.org <server...@groups.cabforum.org>
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-082: "Clarify CA Assisted DNS Validation under 3.2.2.4.7"

Closing the discussion period and opening up the voting period. Ballot SC-082 is proposed by Michael Slaughter (Amazon Trust Services) and endorsed by Martijn Katerbarg (Sectigo) and Wayne Thayer (Fastly). — Purpose of Ballot SC-082 — The purpose

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

 

ZjQcmQRYFpfptBannerEnd

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/591A7733-9F52-4049-9B88-9B9274F3C78E%40amazon.com.

[Ryan Dickson]

Google ABSTAINS from voting on Ballot SC-082.

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

[Tom Zermeno]

SSL.com ABSTAINS from voting on Ballot SC-082.

 

 

-Tom

SSL.com

 

From: 'Slaughter, Michael' via Server Certificate WG (CA/B Forum) <server...@groups.cabforum.org>

Sent: Wednesday, November 20, 2024 12:28 PM
To: server...@groups.cabforum.org
Subject: [Servercert-wg] Voting Period Begins - Ballot SC-082: "Clarify CA Assisted DNS Validation under 3.2.2.4.7"

 

Closing the discussion period and opening up the voting period.

To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/servercert-wg/591A7733-9F52-4049-9B88-9B9274F3C78E%40amazon.com.

[Michael Guenther]

[Dimitris Zacharopoulos (HARICA)]

Hi Clint,

On 11/22/2024 8:05 PM, 'Clint Wilson' via Server Certificate WG (CA/B
Forum) wrote:
> Another side being that mitigations for those threats are misplaced
> given that there is no consensus that this method is currently
> allowed, and thus the origin for those threats a non-factor for the
> purposes of adding a validation method which provides for this form of
> delegation — which was, of course, the stated desire when this
> proposal was first raised.

I isolated this statement because it came to me as a surprise. If you
consider that this method is currently not allowed, knowing that there
is public information about this method actively being used today, why
are there no public security incidents reported?

In past conversations, I do recall having consensus in the group that
this method is currently allowed because of the very nature of CNAME
chaining. I admit I have not followed the work of the Tiger Team so
closely, but I was surprised to read that Apple considers this method
not allowed with the current rules. Perhaps I misunderstood your statement?


Thanks,
Dimitris.