[cabf_validation] 2024-01-11 Validation-sc draft minutes [REVISED]

[Slaughter, Michael]

Please see the REVISED draft minutes below.
Validation Subcommittee – 11 January 2024 [REVISED 24/01/2024]
Minute Taker: Michael Slaughter (Amazon)

Attendees: Aaron Gable (Let's Encrypt), Aaron Poulsen (Amazon), Andrea Holland (VikingCloud), Aneta Wojtczak-Iwanicka (Microsoft), Ben Wilson (Mozilla), Bruce Morton (Entrust), Cade Cairns (Google), Clint Wilson (Apple), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), David Kluge (Google), Dimitris Zacharopoulos (HARICA), Doug Beattie (GlobalSign), Dustin Hollenback (Microsoft), Eva Vansteenberge (GlobalSign), Gregory Tomko (GlobalSign), Inigo Barreira (Sectigo), Janet Hines (VikingCloud), Johnny Reading (GoDaddy), Mads Henriksveen (Buypass AS), Martijn Katerbarg (Sectigo), Michael Slaughter (Amazon), Michelle Coon (OATI), Nate Smith (GoDaddy), Paul van Brouwershaven (Entrust), Pedro Fuentes (OISTE Foundation), Rebecca Kelley (Apple), Rollin Yu (TrustAsia), Scott Rea (eMudhra), Sissel Hoel (Buypass AS), Stephen Davidson (DigiCert), Thomas Zermeno (SSL.com<http://ssl.com/>), Tobias Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Wayne Thayer (Fastly), Wendy Brown (US Federal PKI Management Authority)

Corey read the note well statement.
Agenda

  1.  Status update for the MPIC
  2.  Status update on Method 7 ballot
  3.  Usage of third parties for domain control verification.
MPIC Update

  *   Chris and Ryan were not present at the meeting and did not provide an update.
  *   Clint said that while he can’t provide an official update, based on his understanding with Chris and Ryan before the holidays the text of the ballot is more or less stable. He then offered that if folks want to review it the ballot text is available as a branch on Ryan’s repo. Most of the work remaining with the ballot is proactively addressing potential IP concerns prior to the official discussion period and voting.
  *   Aaron shared a link to the ballot and said that he agreed with Clint that the ballot is stable. Aaron explained that the recent activity is related to a single comment thread about the phrasing of a single sentence.
  *   Doug emphasized that time is of the essence as the deadlines called out in the ballot are in December and CAs will need time to prepare. Doug said the sooner we can get this ballot into a formal discussion period the better to move it forward. Doug asked about the IP discussion and if there were concerns that the ballot will not happen.
  *   Clint said he doesn’t believe there are IP concerns but added that because the changes originated with the Princeton team presenting to the CABF, when they hadn’t signed the IPR agreement is being looked at as a potential area of concern. Client added that Ryan and Chris are working with the Princeton team to get a “release of IP statement”.
  *   Trev said this seems kind of weird since the ballot is a collaborative solution to a problem.
  *   Aaron agreed with Trev and said that the Princeton legal team disagrees and is pushing the issue. Aaron said that both the Google and the LE legal teams are involved. Aaron added that the Princeton legal team has declared that it will never be appropriate for the Princeton team to sign the IPR agreement and join the CABF as an interested party but they are willing to make a statement regarding the IP claims which can be brought to the CABF for consideration.
  *   Trev did not agree with the idea of getting the Princeton people to sign an IPR in the first place because a presentation at the CABF is not materially different from passing around a link to an interesting finding. She then suggested that the Server Cert working group should look further into identifying a way of handling security researchers when they are sharing findings and not solutions.
  *   Ben said that isn’t about protecting Princeton but rather protecting CAs and answering any kind of objections that CAs might pull out at the last minute. He said that all of this effort is directed towards satisfying CAs and certificate issuers and that Princeton has not been that concerned about the IPR but rather they would not like to sign something that touches on some tangential intellectual property right that they own somewhere else.
  *   Dimitris clarified that the Princeton team did not just present findings, they also contributed to the solution which is where the IP challenges are coming from. Dimitris said that the rules are not intended to protect CAs but rather the entire eco-system. He added that if we were to implement something in the BRs and then someone claimed royalties for that implementation, that would have a negative impact to the eco system.
  *   Trev said that we are not going to raise the security bar without getting input from security researchers. We have to be able to engage with them without the expectation of an IPR. We should put together more forum level guidance so that we don’t run into this in the future.
  *   Dimitris said that no one is blocking us from bringing in researchers or reading the news but we have to develop solutions with members to make sure they are not going to claim anything that they contributed to the Forum. This is currently achieved by asking Members (including Interested Parties) to sign the IPR agreement.
  *   Trev said that we should put together more forum level guidance so we don’t run into this in the future.
  *   Ben said historically, there was the example of the Navy SSL patent which someone got a hold of and started suing all of the biggest subscribers they could find. Ben agreed with Dimitris that the IPR agreement is to protect the eco-system.
Method 7 Ballot Up

  *   Slaughter provided background on the ballot and explained that he was able to capture the feedback from the previous discussion 30/11/2024 and it has been incorporated into a new revision:  https://github.com/slghtr-says/servercert/pull/1/files.
  *   Slaughter requested feedback on the updated language in the form of comments on the PR.
Delegated Third-Parties and Domain Validation

  *   Corey introduced the 3rd topic of the meeting.
  *   Corey said that the BRs are clear that the use of DTPs in the validation process is prohibited. Corey said that CAs are going to be using data centers and upstream ISPs that are going to be handling various aspects of the domain validation process. He said it can be somewhat unclear if it is appropriate to use upstream service providers that provide connectivity to the Internet. Corey referenced a recent Bugzilla bug where the use of the Google web-based DNS tool was deemed as a DTP and not allowed.
  *   Dimitris recalled the original discussion to forbid DTPs from performing domain validation tasks. He said that his understanding was that it had to with the complete domain validation process and that the expectation of the forum at the time was not to deny any third-party component used as part of the process but rather the entity that makes the final decision. Dimitris said that despite the intent, the current language in the BRs explicitly states that using DTPs for any part of the domain validation process is prohibited in sections 3.2.2.4 and 3.2.2.5, which is problematic.
  *   David Kluge said that the discussion and definition is relatively simple but not if you dig deeper. He then explained that section 3.2.2.4 contains a clear prohibition on the use delegated third parties in domain validation but if you look at the definition of DTP it contains a three-fold test to determine what a DTP is. It is defined as a person or legal entity that fulfills one or more of the CA’s requirements but is not in scope of the CA’s audit. David then explained that a third-party is not necessarily a delegated third-party unless it also performs a duty that the CA has. This can get you into trouble if you expand the definition too broadly and extend it to Internet Service Providers (ISPs), Data Center Providers etc. David suggested that we take a look at a few examples and determine where it makes sense to draw the line between the appropriate and inappropriate use of delegated third parties.
  *   Trev said that Dimitris’ explanation of the original intent seems like the consistent interpretation. She added that for EV we have validation specialists and that even for DV we expect the CA to exercise authority over the decision-making process. She added that when she thinks of delegating domain validation, she defines it as delegating the decision rather than the specific mechanisms to retrieve the data required to make the decision. She then asked how a CA could actually perform domain validation if retrieving critical information from a third-party such as WHOIS or a registrar is not allowed. She concluded that the CA exercises judgement over the data it receives.
  *   Clint agreed that this is a pretty complex area of concern but thinks that the conclusion of the bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1872371) is correct. Clint agreed with Trev that CAs have to get data from somewhere but it has to be from the right sources. Clint explained that is why QIS and QGIS exist. For DNS based data, third parties have to be involved because of how the internet works.
  *   Clint said that in the process of validating a domain there are boundaries around what the CA is doing and how it is engaging with the third-parties. CAs have to use the protocol but we should expect the CA to use the protocol authoritatively by directly connecting to the root zone and from there navigating down the DNS hierarchy to the target. Clint said that by using a 3rd party DNS resolver for example, you are delegating an important function in parsing and retrieving the zone information that the CA is trying to get their hands on. Clint asserted that the resolver needs to be in the CAs control. Clint said that if we can come to an agreement on where that line exists, it would be really good to add that clarity to the BRs.
  *   Tobias agreed with Clint’s perspective and said there are really two DNS protocols. 1) Between the client and stub resolver. 2) Between the resolver and the authoritative name servers. Tobias said that the only systems worth checking are the authoritative ones. Tobias then asked if there was actual disagreement about whether or not using a third-party service for DNS resolution is acceptable.
  *   David said the current language is not as specific as it should be and that it doesn’t distinguish between the different parts of the domain name system and leaves it open for interpretation.
  *   Tobias asked if there is agreement that using a 3rd-party DNS resolver should only be allowed if it is a dedicated third-party that is in scope of the audit.
  *   David answered that he doesn’t know and that establishing what the concerns are might help.
  *   Martijn said that he agreed with Clint and Tobias and that some parts of the BRs are more specific where DNS is not. Martijn said that we can look at the WHOIS language as an example of where the language says the information has to be retrieved directly from the domain registrar or registry operator. Martijn agrees that we should only be using third-parties to request authoritative answers from root servers or registries directly and that we should have improvements in the BRs to make that clearer.
  *   Mads Henriksveen said that he will not argue about the suggestions of what is allowed and not allowed, there is some missing language in the BRs. Currently there are some practices that are accepted by the industry and some that are not but it is not obvious what is and what isn’t. Mads added that he hopes that we can add some language that clarifies this for all domain validation methods.
  *   Aaron said that he fundamentally agrees with Clint that DNS lookups need to be made to an authoritative resolver. As discussed in the BugZilla bug there were actually two issues with using Google DNS 1) Google Public DNS is a DTP and DTPs are forbidden and 2) Google Public DNS doesn’t commit to adhering to satisfying all of Public CA requirements such as DNSSEC. Aaron said that the second issue is why contacting the authoritative name server is the thing that needs to be clarified as the requirement.
  *   Aaron said that we need to be talking about this in the context of multiple domain validation methods such as the agreed-upon changes to a website and CAA record-based methods that also rely on DNS lookups. Aaron said that DNS lookups are required for 95% of the domain validation methods so we need to be looking at this holistically. Aaron added that the second concern is how many CAs are using third-parties such as MailChimp to send e-mails for e-mail validation and does that count as a delegated 3rd party?
  *   Dimitris thanked Aaron and said that he tried to highlight some of those issues in the e-mail to the forum list on December 28th which invoked all of the issues from the TLS BRs and SMIME. Dimitris said Aaron mentioned an indirect requirement that comes from DNSSEC and added that there are other requirements that come from other documents such as 5280 that have resulted in several CAs missing them and caused multiple public incidents. Dimitris said that repeated incidents is a strong indication that something is wrong with the BRs. He added that in the current BRs there is no rule or requirement that an authoritative name server needs to be queried. That comes indirectly from the DNSSEC checks that CAs must perform, and most implementations already take that into account by checking with Authoritative name servers, but that doesn’t cover 100% of the implementations.
  *   Corey said there are two themes emerging: 1) Why is the use of a third-party problematic 2) the discussion on DNSSEC. Corey suggested that we continue the discussion on why the use of public resolvers is problematic. Corey asked if anyone could provide an explanation on why the use of public resolvers is problematic.
  *   Dimitris clarified that we are talking about delegated third-parties as part of some component or function executed in the BRs but added that we don’t have any tools to create a light-weight audit for delegated 3rd parties. Dimitris added that it doesn’t really make sense from a security standpoint to require delegated third parties to be audited against the entirety of the BRs when they are only performing some limited function. He said that this was part of the MPIC proposal regarding the remote vantage points.
  *   David said he thinks it might help to frame the problem as a data quality concern. The delegated third-party discussion is about a legal entity allocation but that is not what really matters for the quality of the validation. So, it may help to further specify what the quality or reliability expectations are for the data.
  *   Tobias replied that it’s also about responsibility.
  *   David said yes as an extension in that you care about responsibility because if you have insufficient responsibility, you have bad quality.
  *   Tobias replied that the CAs are responsible to the root programs and have oversight and the ability to react. He expressed the concern that if we just allow DTPs after examining the data, we will not have the same degree of oversight.
  *   David replied that you also run into enforcement problems if you only look at the entity allocation without having a measure for the quality of the data itself.
  *   Dimitris suggested to David that we bring in some risk analysis for the different components that could participate in the validation process such as the DNS resolver.
  *   Tobias responded that the problem is difficult because some of the big public resolvers are likely way more trustworthy because of the level they are operated at. Specifying this out in a way that makes them acceptable is going to be hard.
  *   Trev said she thinks Dimitris’ suggestion is right and unless we do a risk assessment, we will continue spin in fear circles.
  *   Mads said that even if we found a DTP that is 100% reliable it is still not allowed because it’s a DTP so measuring the quality of the data is not the way to go.
  *   David said he agrees we could do an analysis of what criteria flow into data quality and get a better understanding of the likelihood of these occurring and help provide some direction to the discussion.
  *   Dimitris said as we start unpacking the discussion and expand to other DTPs (SMS, Phone etc..) performing a risk assessment would be helpful.
  *   Tobias said he disagrees and thinks there is solid reason to draw the line where it is. He added that the idea that we could just delegate the main validation out to DTPs is very problematic. Tobias said that DTPs are usually not operated for the purpose of performing domain validation so the requirements would not be considered at every step along the way. He said their usage for other purposes may also make them vulnerable to a wider range of attacks. He concluded that we would need a very complicated framework to determine when these are acceptable which he does not believe would be worthwhile.
  *   Mads said a risk assessment is something that we could use to help draw that line.
  *   Aaron said for the sake of being able to continue the discussion past the end of the meeting, Aaron sent a very simple clarification as a starting point on how to clarify this language as a reply to Dimitris’ thread.
  *   Dimitris forwarded the thread to the server cert working group for IP reasons among others.
  *   Corey said the language that Aaron sent out could be considered as a treatment to a symptom and that the underlying issue is that there is a lack of clarity of when a DTP is acceptable or not. Corey said that a risk assessment exercise would help identify the larger set of threats and potential resolutions.
  *   Clint said addressing the symptom is worthwhile since it is currently an open wound and recommended that we also bring 3.2.2.5 into scope. Tearing this apart for other purposes will have diminishing returns and would be very challenging.
  *   Aaron said he is unopposed to a two-prong approach but does not think the clarification should wait on the security assessment.
  *   Corey asked if there is value in performing a risk assessment.
  *   Dimitris said that once the experts start talking about a given topic like e-mail validation then it will lead to some useful productive discussion about the risks, threats and appropriate mitigations which is in essence part of a risk assessment.
  *   Corey concluded that we will spend some time on the next call and open the floor up to how we want to do the risk assessment.

From: "Slaughter, Michael" <slghtr at amazon.com>
Date: Monday, January 22, 2024 at 22:08
To: "validation at cabforum.org" <validation at cabforum.org>
Subject: 2024-01-11 Validation-sc draft minutes

Validation Subcommittee – 11 January 2024
Minute Taker: Michael Slaughter (Amazon)

Attendees: Aaron Gable (Let's Encrypt), Aaron Poulsen (Amazon), Andrea Holland (VikingCloud), Aneta Wojtczak-Iwanicka (Microsoft), Ben Wilson (Mozilla), Bruce Morton (Entrust), Cade Cairns (Google), Clint Wilson (Apple), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), David Kluge (Google), Dimitris Zacharopoulos (HARICA), Doug Beattie (GlobalSign), Dustin Hollenback (Microsoft), Eva Vansteenberge (GlobalSign), Gregory Tomko (GlobalSign), Inigo Barreira (Sectigo), Janet Hines (VikingCloud), Johnny Reading (GoDaddy), Mads Henriksveen (Buypass AS), Martijn Katerbarg (Sectigo), Michael Slaughter (Amazon), Michelle Coon (OATI), Nate Smith (GoDaddy), Paul van Brouwershaven (Entrust), Pedro Fuentes (OISTE Foundation), Rebecca Kelley (Apple), Rollin Yu (TrustAsia), Scott Rea (eMudhra), Sissel Hoel (Buypass AS), Stephen Davidson (DigiCert), Thomas Zermeno (SSL.com<http://ssl.com/>), Tobias Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Wayne Thayer (Fastly), Wendy Brown (US Federal PKI Management Authority)
Note: Paris = David Kluge (GTS)

Corey read the note well statement.
Agenda

  1.  Status update for the MPIC
  2.  Status update on Method 7 ballot
  3.  Delegated Third-Parties and Domain Validation
MPIC Update
Chris and Ryan will provide an update at the next meeting.

Aaron provided a link to the ballot and explained that the flurry of activity that has happened in the last 2 weeks is related to a single comment thread about the phrasing of a single sentence and that the majority of the ballot is stable.

Doug emphasized that time is of the essence since the dates start in the December and CAs will need time to perform planning and implementation.

Clint explained that delays were due to ongoing IPR agreement challenges with Princeton research team.

Aaron said that both the Google and the LE general consuls are working on this effort. The Princeton legal team has made a statement that it will never be appropriate for the Princeton team to sign the IPR agreement and join as an interested party

Trev said that we should talk about how we can handle future security researchers in a way that doesn’t require them to sign an IPR agreement when they are share findings rather than solutions.

Ben explained that the IPR agreement is mainly for protecting the CAs.

Dimitris clarified that the Princeton team did not just present findings, they also contributed to the solution. Dimitris said that the rules are not intended to protect CAs but rather the entire eco-system. If the forum requires MPIC but then someone implements royalties then that will have a negative impact on the eco-system.

Trev said that we are not going to raise the security bar unless we continue to receive feedback from researchers. We have to be able to engage with them without the expectation of an IPR. We should put together more forum level guidance so that we don’t run into this in the future.

Ben said historically, there was the Navy SSL patent which someone got a hold of that was used to extract money from multiple parities. Ben then agreed with Dimitris’ point about protecting the eco-system.
Method 7 Ballot Update
Slaughter provided background on the ballot and explained that he was able to capture the feedback from the previous discussion 30/11/2024 and it has been incorporated it into a new revision:  https://github.com/slghtr-says/servercert/pull/1/files.

Slaughter requested feedback on the updated language in the form of comments on the PR.
Delegated Third-Parties and Domain Validation
Corey introduced the 3rd topic of the meeting by explaining that the BRs are unclear about which aspects of the domain validation process are allowed to be performed by third-party services such as Google’s public DNS resolver. The purpose of this discussion is to try and build some consensus about what is appropriate and what is not.

Dimitris recalled the discussion to forbid delegated third parties from performing domain validation tasks and that it was his understanding is that the discussion was centered around the complete process of domain validation. He didn’t think the expectation of the forum was to deny any third-party component used as part on the process but rather who makes the final decision.

David Kluge said that the definition is relatively simple but not straightforward and explained that 3.2.2.4 clearly prohibits the use delegated third parties in main validation process and that delegated third party is defined as a different personal or legal entity that fulfills one or more of the CA’s requirements. David explained that this definition in the broadest interpretation could extend to Internet Service Providers (ISPs), Data Center Providers etc... at which point section 3.2.4 “collapses in on itself”. David then suggested that we look at a few examples and determine where it makes sense to draw the line between appropriate and inappropriate use of delegated third parties.

Trev said what confuses her about this is that there seems to be a consistent definition and that we expect the CA to exercise authority over the decision-making process. She added that when she thinks of delegating domain validation, she considers that as delegating the decision rather than the mechanism to get the information. The CA is responsible for exercising judgment over the data it receives.

Clint agreed that this is a pretty complex area of concern but thinks that the conclusion of the bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1872371) is correct. Clint said that CAs have to get data from the right sources which is why QIS and QGIS exist. For DNS data, third parties have to be involved based on how the internet works. In the process of validating a domain the CA may rely on third parties but the he would expect the protocol to be verified directly by the CA. For example, ensuring that DNS lookups are authoritative by directly connecting to the root zone and going down the DNS hierarchy. Clint said using 3rd party DNS resolver for example steps over that of being a “necessary” third party. Clint said we can come to an agreement on where that line exists and that it would be really good to add that clarity to the BRs.

Tobias: agreed with Clint and said there are two DNS protocols. 1) Between the client and stub resolver. 2) Between the resolver and the authoritative resolver and the only one’s worth checking are the authoritative ones. Tobias then asked if there was actual disagreement about whether or not using a third-party service for DNS resolution is acceptable if the language just needs to be improved.

David replied that at this point, the language is not as specific as it should be since it doesn’t distinguish between the different parts of the domain name system leaves it open for interpretation.

Tobias asked if there is agreement that using a 3rd-party DNS resolver should only be allowed if it is a dedicated 3rd party that is in the scope of audits.

David answered that he doesn’t know and that establishing what the concerns are might help.

Martijn said that we can look at the WHO-IS language as an example of where the language says the information has to be retrieved directly from the domain register or registry operator. The DNS language does not have that kind of specificity. Martijn agrees that we should only be using third-parties to request authoritative answers from browsers or registries directly and that we should make the text more around that.

Mads said that he will not argue about what is allowed and not allowed but as a CA that missed recently, I think there is some missing language in the BRs that is missing. Currently there is some practice that is accepted by the industry and some that are not but it is not obvious what is and what isn’t. Mads added that he hopes that we can add some language that helps clarify this for all of the domain validation methods.

Aaron said that he fundamentally agrees with Client that DNS lookups need to be made to an authoritative resolver. There were actually two issues with using Google DNS 1) They are a third-party which are forbidden and 2) Google Public DNS doesn’t commit to adhering to satisfying all of the requirements such as always performing DNS-SEC lookups. I think the second issue is why contacting the authoritative name server is the thing that is required and what needs to be clarified as the requirement. Aaron said that we need to be talking about this in the context of multiple domain validation methods including the File and CAA record-based methods that also rely on DNS lookups. DNS is required for 95% of the domain validation methods so we need to talk about this holistically. The second concern is how many CAs are using third-parties such as MailChimp to send e-mails for e-mail validation and does that count as a delegated 3rd party?

Dimitris said he tried to highlight some of those issues in the e-mail to the forum list on December 28th. Dimitris said Aaron mentioned an indirect requirement that comes from DNS SEC. and added that there are other requirements that come from other sources such as 5280 that have caused problems. Dimitris said we are talking about repeated incidents that is outside of domain validation which is a strong indication that something is wrong that we need to clarify or make more explicit. Dimitris added that there is no rule or requirement that an authoritative need to be queried as that indirectly comes from the DNS checks that CAs must perform.

Corey said there are two themes emerging: 1) Why is the use of a third-party problematic 2) the discussion on DNSSEC. Corey asked if anyone could provide an explanation on why there is a problem with delegating to third parties.

Dimitris clarified that we are talking about delegated third-parties as part of some component or function executed in the BRs but we don’t have any tools to create a lighter-weight audit for delegated 3rd parties. Dimitris added that it doesn’t really make sense from a security standpoint to required delegated third parties to be audited against the entirety of the BRs when they are only performing some function. He continued that this was part of the MPIC proposal for the remote vantage points.

David said he thinks it may helpful to frame the problem as a data quality concern. The delegated third-party discussion is about a legal-entity distinction but that is not what really matters for the quality of the validation. So, it may help to really focus on the reliability expectations of the third party.

Tobias said that it’s also about responsibility and that the CAs are responsible to the root programs and have oversight and the ability to react. He expressed the concern that if we just allow the usage of DTPs, we will not have the same degree of oversight.

Dimitris suggested to David that we bring in some risk analysis to the different components that could participate in the validation process. For example, a public DNS resolver and analyze if we can trust Google to not return wrong data and examine the probabilities.

Tobias responded that the problem is really difficult and that some of the big public resolvers are way more trust worthy. Specifying this out in a way that makes it acceptable is going to be really hard.

Trev said I think that Dimitris’ suggestion is right and we need to do a risk assessment or else we will continue to go round and round in fear circles.

Mads said that even if we found a DTP that is 100% reliable it’s still not allowed because it’s a DTP so he doesn’t believe that measuring the quality of the data is the way to go.

David said he things we could do an analysis to get a better understanding of the likelihood of these occurring because at this moment I think the discussion is purely conceptual since we don’t have any quantification for these scenarios.

Dimitris said a risk assessment that covers all DTPs including those for sending e-mails would be helpful.

Tobias said he thinks there is solid reason to draw the line where it is and that the idea that we could delegate the main validation out to DTPs is very problematic. Tobias said that DTPs are usually not operated to the level required, the requirements around validation would not be considered at every step along the way and their usage would make them vulnerable to attacks. He concluded that we would need a very complicated framework to determine when these are acceptable which he does not believe is worthwhile.

Mads said a risk assessment is something that we could use to help draw that line.

Aaron said for the sake of being able to continue the discussion, I sent a very simple clarification on how to clarify this language as a reply to Dimitris’ thread.

Dimitris asked for the thread to be forwarded to the server cert working group.

Corey said the language that Aaron sent out was treatment to a symptom and that we would also need a risk assessment exercise to identify the larger set of threats and potential resolutions.

Clint said addressing the symptom is worthwhile since it is currently an open wound and recommended that we also address 3.2.2.5. Tearing this apart for other purposes will have diminishing returns and would be challenging.

Aaron said he is fine with a two-prong approach but does not think the clarification should wait on the security assessment. I think the clarification should proceed at full steam ahead.

Corey asked if there is value in performing a risk assessment.

Dimitris said that once the experts start talking about a given topic like e-mail validation then it will lead to some useful productive discussion about the risks. threats and appropriate mitigations.

Corey concluded that we will spend some time on the next call and open the floor up to how we want to do the risk assessment.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20240124/8d0eeb5b/attachment-0001.html>