From Corey.Bonnell at digicert.com Tue Apr 2 19:11:40 2024 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Tue, 2 Apr 2024 19:11:40 +0000 Subject: [cabf_validation] 2024-04-04 Meeting Agenda Message-ID: Hello, Proposed agenda for this Thursday's meeting: 1. Status update on EV automation improvement ballot led by Eva (if needed) 2. Status update on 3.2.4.4 7 "CA-assisted DNS validation" ballot led by Michael (if needed) 3. Identification of DTPs in the domain validation process a. Begin identification for methods 7, 18-20 b. Tackle #7 first then move on to 18-20 in order? Minute-taker: Trev If you have any additional agenda items, please reply to this email. Thanks, Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5231 bytes Desc: not available URL: From Corey.Bonnell at digicert.com Thu Apr 4 16:11:41 2024 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Thu, 4 Apr 2024 16:11:41 +0000 Subject: [cabf_validation] Approved minutes of the validation-sc meeting at F2F 62 2024-02-28 Message-ID: Here are the approved minutes from the February 28 Validation Subcommittee meeting. Thanks to Ben for taking these! Feb 28th, 2024 - Face-to-Face Validation Subcommittee Meeting Corey Bonnell ran the meeting. Notewell read by Corey. Feb. 8, 2024, Meeting Minutes were unanimously approved. Progress Summary - "Progress since Fall 2023 F2F" Corey reviewed: . BR section 3.2.2.4 (7) improvements . MPDV/MPIC effort led by Chris and Ryan . Automation of EV certificate issuance - GlobalSign will continue its presentation today . Identifying DTP in context of Domain and IP address validation (discussion postponed until 3/7/2024) Automation of EV Certificate Issuance - Eva Van Steenberge Slide 1: Introduction Context - The EVGs were not written with automation in mind. Allowed practices are not clear, and there is ambiguity. Some methods are easily automated while others are not, e.g., looking up a phone number in a QGIS and then calling it and then hoping that you get in touch with the right person. Goals - Automation of domain validation exists, but improvements could be made to clarify how processing of certificate requests could be automated. Main Themes for This Round We want to keep a narrow scope without rewriting the entire EVGs. The group has looked at "due diligence" and "cross-correlation" and to reduce the amount of work being done. GlobalSign and others looked at what these two concepts mean. Eva then reviewed how these topics were addressed by proposed changes to the EVGs. Due Diligence and Domain Validation (EVG 11.13) Eva - we moved away from requiring it for every certificate or certificate request and focused on the fact that the CA has to do the procedure as a whole, but that it has to have been done, and it's not something that can be done after the fact. Roman Fischer asked whether mention of "the Certificate" meant "each certificate". Eva said that wasn't their intent. Tim H. said that is how we typically write the requirements-in terms of a single certificate, which is what may cause this confusion, but it is implied that you may be doing multiple certificates. Eva said that after her presentation it should be clear that things don't need to be done on a certificate-by-certificate basis. Clint said it should be understood that the CA has to "ensure" that the requirement is being done, but that an individual does not need to review every single certificate issued. Ben asked why "due diligence" is tied together here with "domain validation"? From his perspective, "due diligence" doesn't need to be performed on domain validation, but it is mainly for confirming subject identity information. Eva - we tried to define "due diligence" (next slide) and we looked at whether all things have been done correctly. Then, if it is automated, due diligence doesn't apply, but if manual, then it needs to have been done correctly and someone else needs to double-check it, but we didn't want to out-scope it entirely. This proposes a definition for "due diligence", any questions or comments? Clint - I don't think it's absolutely necessary that it be capitalized and defined, but it looks fine. Ben - the definition is too narrow - it focuses too much on the processes/procedures and not enough on the contents of the certificates. Eva - that's not how we see it, not everything we do ends up in the contents of the certificate (e.g. company age, authorization of requester and signer, etc.) Clint - I agree with Ben, you can't put the legal name of an organization into the certificate unless it meets the requirements that all the steps have been performed. The concepts are very similar, the processes and procedures lead to what is included in the certificate. Eva - Are we hinting at the difference between due diligence and cross-correlation? All the different elements have to be done correctly, and those individual elements are subject to due diligence, and then everything combined goes into the certificate. That feels like cross-correlation. Clint - It might. Those terms are not currently well-defined in the EVGs. Ben - I wouldn't lump them together like that even though they are part of the same phrase. I'd like something that says, "verification of certificate contents is done with due diligence". I can hold my comments about "cross-correlation" until later. Scott R. -- Can you clarify the scope of what you have for "due diligence" and "cross-correlation"? Because if you say it is automated and not subject to due diligence, but then with cross-correlation if you have to tie everything together, there might be a domain that is not related to the organization. Paul - With this definition we say, "due diligence is the process of ..." we might be able to re-word that section to say that the due diligence process must confirm that each verification process and procedure ., but that would no longer be a definition, it's more contextual. Eva - that sounds good. Paul - And you could create sub-items by indenting and bulleting parts of it. Eva - We wanted to split them out because of the different treatment for domain validation. Cross-Correlation We started work on cross-correlation with something that is like a definition. We don't mention the whole of certificate contents, but we do mention certificate contents. Cross-correlation confirms that there are no discrepancies when everything is combined. We could consider whether to make it more explicit that it needs to support all of the information that goes into the certificate. During our review process, we considered that maybe we take verification of domain names out of the EVGs altogether, since they mainly refer to the BRs. When things were manual, it made sense, but it no longer makes sense to require cross-correlation for the domain control. Historically, there was the lawyer's letter, but it required that you verify the lawyer's signature and license to practice. But then when exclusive control of the domain dropped off, it no longer made sense to require cross-correlation of domain ownership. Do people have opinions about this? Toby - I don't know if I have an opinion, but I have questions. let's say we have a domain name of a well-known bank, but it is clearly not the bank, how would that factor in under cross-correlation? In the past, when we had signals like the green bar, it would be very unfortunate to display those. Tim - Yes. That's the purpose of section 3.2.5, Verification of Authority. The CA is required to verify that the applicant actually legitimately represents the organization. So, in that case the section 3.2.5 checks should fail. Eva - All of the processes should stop that, but I'm not sure that it needs to be cross-correlation that stops that. Clint - Section 3.2.5 is part of the domain validation process, even if it is not part of the domain control validation process. If we're going to scope things out of the EVGs, then we ought to be clear that we're scoping section 3.2.2.4 out of the due diligence and cross-correlation requirements. What is the intent of having the certificate go through an extended verification? Perhaps it is handled by section 3.2.5, but we want to make sure that we're backing up the claim that they are "Extended Validation". Having an extra EV component for domain validation would make sense. Eva - The EVGs have procedures not just for the domain and identity, but also the things to flesh out section 3.2.5. For example, the signer and the approver requirements, but I don't know what added value is adding domain control in due diligence and cross-correlation. Tim - Great point of Clint. We need to be more specific. We need to clarify for other CAs who are not doing things properly, e.g. they are not aware that they need to verify that the requester of the certificate works for the organization requesting the certificate. So adding clarification and specificity in this area would be good. Eva - Is that related to due diligence and cross-correlation, or is it that sections 11.8 and 11.9 of the EVGs are just more specific versions of BR section 3.2.5? Tim - I'm just saying that we need to make it clear that DCV has been performed. Eva - So we should make it clear that domain validation is to be performed according to these specific sections. Toby - I'm not sure about the explanation of section 3.2.5. For example, if I control a domain, but it is an impersonating domain, like if I registered globalsignCA.com as a domain I own. And then I get an EV certificate for an entity that doesn't even claim to be GlobalSign. Eva - but is that a problem? Toby - In the past it would have been a signal to relying parties for banking sites, e-commerce sites, etc., and it might become relevant again with QWACs. Tim - If the verification works correctly, then the confirmed identity will be accurate and portrayed correctly. That is how the process is supposed to work. The domain might say globalsignca.com, but the identity information won't say GlobalSign, it will say something like "Hollebeek Enterprises". If the process correctly identifies the right subject organization, then that's how it's supposed to work. Toby - But according to research, this will expose people to fraud. Eva - We as CAs don't control what is on these pages, but we provide a very thorough and reliable verification process, so you can complain to this legal person who we verified. So I don't think that matching the domain name to the organization was ever within scope. Paul - This issue is not part of this section we're discussing. Toby - We cannot separate the discussion of how these are issued and how browsers display the information. Dimitris - The purpose of Eva's discussion is to focus on the barriers to automation. Toby - I'll step back, but I am skeptical about automation because of this reason. Dimitris - The cross-correlation step will continue to be done as it is done today, but we're also looking at what information can be reused after that has been done. Paul - Cross-correlation and due diligence are done and you need to have the authorization from the organization and that domain and organization entities can be combined. And those validation processes happen before any certificate request is processed or certificate is issued. Let's assume we reopen the discussion about phishing and misleading domains - because both have been verified before issuance. As soon as the applicant authorizes the domain name to be used in combination with that organization, the CA could say, "we have a process to verify it and we don't allow that combination," but that should not be involved at the actual time of issuance because the domain and the organization both are being verified in advance for issuance. Clint - I agree with Toby, but the way that we have been considering the EVGs for years is changing because they are being incorporated into other standards and procedures, e.g. eIDAS legislation. It will change how relying parties have to interact with the EVGs going forward. Mads - I agree the focus of this proposal is due diligence, cross-correlation, and automating issuance, but let's address EVG 11.7, too, which talks about domain validation. It is related and needs to be fixed, even if it is not part of this proposal. Eva - Thanks. The reason we decided not to is because there are things in EVG 11.7 and the BRs and we don't want to be locked down because we are waiting for some changes to be made in the BRs. But we don't mind, either way. . I will skip through some of the slides. Corey - Let's skip the Delegated-Third-Party topic until next week and continue through with this topic. Eva - OK. We removed delegation of due diligence and cross-correlation by Enterprise RAs. We felt like it didn't add value. So we are not delegating due diligence and cross-correlation to Enterprise RAs. Re-use of Existing Documentation from Due Diligence and Cross-Correlation Eva - We want to make sure the due diligence and cross-correlation can be reused in a safe and secure manner We changed EVG section 11.14, the main body content, because it's not all about age, and because some are about conditions, so we changed it to be about "conditions". We added reliance on previously performed due diligence. It has to have been done, but not just before certificate issuance. We didn't like to use the word "reuse" but things that we continuously rely upon. If the age has expired, then it has to be re-performed. Approval must have been given in an appropriate way. Manual processes should still be reviewed with due diligence and cross-correlation. But if you have used automated processes, then you should be allowed to rely on previously performed steps. For example, if you have a portal where certificate approvers have already been verified, then they can approve certificates without cross-correlation and due diligence. Tim - We have some concerns that you were too restrictive in choosing which methods to keep and which to remove. There are some methods that could be automated and not removed. Eva - Do you have any suggestions to make now? Tim - Yes. EVG section 11.10.2, option 2, and section 11.9.2, option 3. There are potentially options that could be automated. Eva - If this needs to be broader, then we can look at those. We can discuss further when people have had a chance to review this. Separation of Duties (EVG 14.1.3) Eva - We replaced language that suggested that steps needed to be done for every separate certificate issuance with "complete all verification processes and procedures." Are there any questions? Mads - I posted a comment about the last sentence - collecting the information by one person and reviewing it by another person for due diligence and cross-correlation. We collect a lot of information today using automated means. Do we mean that one person reviews all of the information we collect to make sure that it is correct? Eva - Got it. Thank you. Any other comments? Approval of EV Certificate Request (EVG 11.10) Eva - The CA must verify that the certificate request has been approved. "Verifying" sounds very much like after the fact. We replaced this with "ensure" to capture the fact that this could be done automated, without a manual process. A pre-authorized approver can give their approval in an automated way. Tim - I still owe more explicit language on this so that we can have something better than "ensure". Clint - Isn't it pretty clear from the EVGs that the certificate requester can also be the certificate approver as well? Eva - If people think it is clear enough today, then great. We just wanted to add additional clarity that approval can be given in an automated way and you don't have to verify the approval after it has been given. Trev - I am in favor of removing derivatives of verification and validation wherever possible throughout the EVGs where it's not the thing that we intend, but instead where we mean to process and check something. Clint - This approval can be automated if they are both the same. We're looking to make sure that a thing happens. Clint will add a sentence to this section. Verification of Signature on Subscriber Agreement (EVG 11.9) Eva - EVG 11.9 has a reference to 11.8.4 (pre-authorized approver). Clint - One of the "gotchas" in the EVGs is where it says the Contract Signer needs to authorize certificate approvers. There are other places like this in the EVGs, so any clarifications like this will help. Eva -We've discussed requester and approvers being the same person, but we did not explore that topic in depth. Still, we had to fix this section. Clint - The interactions among the three EV roles are interesting and documentation could be added. Tim - We will help with additional rounds on this topic, too. Data Security (EVG section16) Eva - There is a requirement that two trusted persons need to be involved. This is removed because we have enough language elsewhere in the EVGs. Clint - I'm not opposed to removing this, but I'm not positive that removal of this would not have unintended consequences, depending on how this is implemented by CAs. This discussion of trusted persons could be subject to different interpretations. They could be validation specialists, and it may have some impact on due diligence and cross correlation. We should just make sure we're not removing something important. Eva - We previously talked about removing Enterprise RA role. I suppose this neutral language for due diligence and cross-correlation for Enterprise RAs. Brittany - I've seen due diligence and cross-correlation as a systematic control as opposed to a procedural control. Eva - The whole due diligence and cross-correlation process is system agnostic. It just says that it needs to be done, and that could be seen as systematic. Thoughts? Mads - This is a step towards helping with automating EV issuance processes. Eva - Maybe we can remove the reference to "certificate request" and add systematic control. Clint - This section could be moved into the due diligence and cross-correlation section. Eva - That's it. We've come to the end of this presentation. Corey - Should folks provide feedback in GitHub or on the list? Eva - We prefer GitHub. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5231 bytes Desc: not available URL: From wthayer at gmail.com Fri Apr 5 23:12:12 2024 From: wthayer at gmail.com (Wayne Thayer) Date: Fri, 5 Apr 2024 16:12:12 -0700 Subject: [cabf_validation] Adding Support for ACME Scoped DNS Challenges In-Reply-To: References: <0100018dd234634b-08962895-d8cd-44fe-a64d-108348293dc5-000000@email.amazonses.com> <0100018dd24d527a-7c81b2cf-4c3a-4300-8b9c-bbd08a7fca6b-000000@email.amazonses.com> Message-ID: My assessment of the current dns-account-01 draft [1] is that it is not yet stable enough to reference directly in the BRs. In particular, the approach to specifying scope appears likely to change [2]. The good news is that the use of two prepended labels isn't being debated, so we could update TLS BR 3.2.2.4.7 to allow that in the short term, then go back and add the fully specified dns-account-01 method by reference once it becomes an RFC. The CNAME delegation issue addressed by this proposal is a significant barrier to ACME adoption for some Subscribers, so I think there is value in proceeding with an interim solution. Would there be objections to a ballot to modify 3.2.2.4.7 to clearly permit one or two prepended labels in the Authorization Domain Name? Thanks, Wayne [1] https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/ [2] https://mailarchive.ietf.org/arch/browse/acme/?q=dns-account-01 On Mon, Mar 4, 2024 at 10:00?AM Aaron Gable wrote: > Thanks Wayne, I think the approach in your PR makes sense and looks good > to me. The only change that springs to mind is around the phrasing of the > "domain" and "wildcard" scopes in the last paragraph: I believe that the > method should be suitable for validation Wildcard Domain Names if the scope > of the challenge is either "wildcard" *or* "domain", since the dnsop draft > > defines the "domain" scope as a superset of the "wildcard" scope. > > DNS-02 is an interesting question. On the one hand, it structurally falls > under the existing 3.2.2.4.7 "DNS Change" (since it only uses a single > underscore-prefixed label) and doesn't strictly need a new validation > method to be defined in order to be used. On the other hand, it allows > scoping down the validation to just host validation, or scoping it up to > wildcard, and so ideally should have a paragraph at the bottom similar to > the one you've included for dns-account-01. On the whole, I think it is > preferable to include a new validation method for dns-02, but could be > swayed either way. > > Aaron > > On Thu, Feb 29, 2024 at 9:05?AM Wayne Thayer wrote: > >> Thanks Tim and Aaron for the feedback. I've drafted a PR for a new >> dns-account-01 validation method: >> https://github.com/wthayer/servercert/pull/2/files. >> >> Do either of you (or anyone else) have an opinion about including the >> dns-02 challenge from the draft RFC in the scope of this work? I don't have >> a particular need for it, but I don't mind including it for completeness. >> >> - Wayne >> >> On Mon, Feb 26, 2024 at 11:31?AM Aaron Gable >> wrote: >> >>> I concur, I think Option #1 is preferable. Adding a new validation >>> method with reference to an existing document is a much easier and more >>> self-contained change to the BRs. >>> >>> The IETF draft ( >>> https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/) >>> has just been given a major overhaul and renamed, and the updated version >>> will be presented at IETF 119 in mid-March. We'll get a really good sense >>> of whether there will be additional major changes to the document at that >>> time, so I think it would be appropriate to draft a ballot adding this new >>> validation method now, but we should probably wait to vote until after that >>> meeting. >>> >>> Aaron >>> >>> On Thu, Feb 22, 2024 at 11:31?AM Tim Hollebeek via Validation < >>> validation at cabforum.org> wrote: >>> >>>> Yeah, I remember pointing out at the ACME working group a few times >>>> that the BRs would have to be changed to allow two labels (but also >>>> suggesting this is fine, I think two labels is actually superior and >>>> advocated that for the draft). >>>> >>>> >>>> >>>> The approach #2 that Wayne is suggesting here is the one I suggested at >>>> the mike line, but I think I like #1 better. It?s easier to just say ?do >>>> it the RFC way? instead of allowing two labels without any guidance on how >>>> or why. >>>> >>>> >>>> >>>> The question does come up whether the draft is mature enough to adopt >>>> right now ? IMO the answer might be yes, as I seem to recall the document >>>> was pretty close to working group last call. >>>> >>>> >>>> >>>> -Tim >>>> >>>> >>>> >>>> *From:* Validation *On Behalf Of *Wayne >>>> Thayer via Validation >>>> *Sent:* Thursday, February 22, 2024 2:04 PM >>>> *To:* CABforum3 >>>> *Subject:* [cabf_validation] Adding Support for ACME Scoped DNS >>>> Challenges >>>> >>>> >>>> >>>> There has been an effort underway for some time in the IETF ACME >>>> working group that resolves a significant hurdle to ACME adoption for some >>>> Applicants. The decision has been made to implement this in a way that >>>> requires a BR change. >>>> >>>> >>>> >>>> Background: >>>> >>>> It is common for Cloud Service Providers (CSPs) to ask their customers >>>> to delegate domain control to the CSP via a CNAME record that points to a >>>> domain name controlled by the CSP [1]. CSPs in general, and Fastly in >>>> particular, have found that Applicants often request certificates for the >>>> same domain name from multiple CAs. Because (unlike TXT records) only a >>>> single CNAME record is permitted for a particular FQDN, and because RFC >>>> 8555 requires the use of "_acme-challenge" as the DNS validation prefix, >>>> Applicants are unable to automate issuance via ACME dns-01 in this scenario. >>>> >>>> >>>> >>>> Solution: >>>> >>>> A new ACME challenge originally called dns-account-01 was proposed back >>>> in 2022. Last week, the fourth draft was published [2]. The scope of this >>>> draft has expanded to include two new challenges, but I believe that the >>>> more relevant change is that the Authorization Domain Name (ADN) is now >>>> prefixed with TWO labels instead of one. My understanding is that this >>>> change was made to align with the work being done to standardize domain >>>> verification techniques [3] in the dnsop working group. Unfortunately, I >>>> think it's reasonable to interpret BR 3.2.2.4.7 as only permitting a single >>>> label to be prepended to an ADN: "an Authorization Domain Name that is >>>> prefixed with a Domain Label that begins with an underscore character." >>>> >>>> >>>> >>>> Proposal: >>>> >>>> I would like to remove this barrier to automation as soon as possible, >>>> and prior to RFC publication. I can see two ways to accomplish this: >>>> >>>> 1. Add the current draft spec for dns-account-01 to the BRs as a new >>>> validation method. There is precedent for supporting draft versions of ACME >>>> validation methods in the BRs (3.2.2.5.6 originally referenced a draft RFC) >>>> >>>> 2. Tweak the existing 3.2.2.4.7 language to allow one or two labels to >>>> be prepended to an ADN. >>>> >>>> >>>> >>>> I would appreciate everyone's feedback on how best to approach this and >>>> any concerns that you may have. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> >>>> >>>> Wayne >>>> >>>> >>>> >>>> [1] Note that Michael Slaughter is working on a ballot that will >>>> clarify the requirements for DNS delegation to CAs: >>>> https://github.com/slghtr-says/servercert/pull/1 >>>> >>>> >>>> [2] >>>> https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/ >>>> >>>> >>>> [3] >>>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/ >>>> >>>> >>>> This is issue 486: https://github.com/cabforum/servercert/issues/486 >>>> >>>> _______________________________________________ >>>> Validation mailing list >>>> Validation at cabforum.org >>>> https://lists.cabforum.org/mailman/listinfo/validation >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.beattie at globalsign.com Mon Apr 8 11:32:29 2024 From: doug.beattie at globalsign.com (Doug Beattie) Date: Mon, 8 Apr 2024 11:32:29 +0000 Subject: [cabf_validation] Adding Support for ACME Scoped DNS Challenges In-Reply-To: <0100018eb0890c46-7a4120e7-8da3-44c3-ac78-aa5bd8e56b3f-000000@email.amazonses.com> References: <0100018dd234634b-08962895-d8cd-44fe-a64d-108348293dc5-000000@email.amazonses.com> <0100018dd24d527a-7c81b2cf-4c3a-4300-8b9c-bbd08a7fca6b-000000@email.amazonses.com> <0100018eb0890c46-7a4120e7-8da3-44c3-ac78-aa5bd8e56b3f-000000@email.amazonses.com> Message-ID: Hi Wayne, I think that?s a great idea and would be willing to endorse if/when we get to that stage. Doug From: Validation On Behalf Of Wayne Thayer via Validation Sent: Friday, April 5, 2024 7:13 PM To: CA/Browser Forum Validation SC List Subject: Re: [cabf_validation] Adding Support for ACME Scoped DNS Challenges My assessment of the current dns-account-01 draft [1] is that it is not yet stable enough to reference directly in the BRs. In particular, the approach to specifying scope appears likely to change [2]. The good news is that the use of two prepended labels isn't being debated, so we could update TLS BR 3.2.2.4.7 to allow that in the short term, then go back and add the fully specified dns-account-01 method by reference once it becomes an RFC. The CNAME delegation issue addressed by this proposal is a significant barrier to ACME adoption for some Subscribers, so I think there is value in proceeding with an interim solution. Would there be objections to a ballot to modify 3.2.2.4.7 to clearly permit one or two prepended labels in the Authorization Domain Name? Thanks, Wayne [1] https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/ [2] https://mailarchive.ietf.org/arch/browse/acme/?q=dns-account-01 On Mon, Mar 4, 2024 at 10:00?AM Aaron Gable > wrote: Thanks Wayne, I think the approach in your PR makes sense and looks good to me. The only change that springs to mind is around the phrasing of the "domain" and "wildcard" scopes in the last paragraph: I believe that the method should be suitable for validation Wildcard Domain Names if the scope of the challenge is either "wildcard" or "domain", since the dnsop draft defines the "domain" scope as a superset of the "wildcard" scope. DNS-02 is an interesting question. On the one hand, it structurally falls under the existing 3.2.2.4.7 "DNS Change" (since it only uses a single underscore-prefixed label) and doesn't strictly need a new validation method to be defined in order to be used. On the other hand, it allows scoping down the validation to just host validation, or scoping it up to wildcard, and so ideally should have a paragraph at the bottom similar to the one you've included for dns-account-01. On the whole, I think it is preferable to include a new validation method for dns-02, but could be swayed either way. Aaron On Thu, Feb 29, 2024 at 9:05?AM Wayne Thayer > wrote: Thanks Tim and Aaron for the feedback. I've drafted a PR for a new dns-account-01 validation method: https://github.com/wthayer/servercert/pull/2/files. Do either of you (or anyone else) have an opinion about including the dns-02 challenge from the draft RFC in the scope of this work? I don't have a particular need for it, but I don't mind including it for completeness. - Wayne On Mon, Feb 26, 2024 at 11:31?AM Aaron Gable > wrote: I concur, I think Option #1 is preferable. Adding a new validation method with reference to an existing document is a much easier and more self-contained change to the BRs. The IETF draft (https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/) has just been given a major overhaul and renamed, and the updated version will be presented at IETF 119 in mid-March. We'll get a really good sense of whether there will be additional major changes to the document at that time, so I think it would be appropriate to draft a ballot adding this new validation method now, but we should probably wait to vote until after that meeting. Aaron On Thu, Feb 22, 2024 at 11:31?AM Tim Hollebeek via Validation > wrote: Yeah, I remember pointing out at the ACME working group a few times that the BRs would have to be changed to allow two labels (but also suggesting this is fine, I think two labels is actually superior and advocated that for the draft). The approach #2 that Wayne is suggesting here is the one I suggested at the mike line, but I think I like #1 better. It?s easier to just say ?do it the RFC way? instead of allowing two labels without any guidance on how or why. The question does come up whether the draft is mature enough to adopt right now ? IMO the answer might be yes, as I seem to recall the document was pretty close to working group last call. -Tim From: Validation > On Behalf Of Wayne Thayer via Validation Sent: Thursday, February 22, 2024 2:04 PM To: CABforum3 > Subject: [cabf_validation] Adding Support for ACME Scoped DNS Challenges There has been an effort underway for some time in the IETF ACME working group that resolves a significant hurdle to ACME adoption for some Applicants. The decision has been made to implement this in a way that requires a BR change. Background: It is common for Cloud Service Providers (CSPs) to ask their customers to delegate domain control to the CSP via a CNAME record that points to a domain name controlled by the CSP [1]. CSPs in general, and Fastly in particular, have found that Applicants often request certificates for the same domain name from multiple CAs. Because (unlike TXT records) only a single CNAME record is permitted for a particular FQDN, and because RFC 8555 requires the use of "_acme-challenge" as the DNS validation prefix, Applicants are unable to automate issuance via ACME dns-01 in this scenario. Solution: A new ACME challenge originally called dns-account-01 was proposed back in 2022. Last week, the fourth draft was published [2]. The scope of this draft has expanded to include two new challenges, but I believe that the more relevant change is that the Authorization Domain Name (ADN) is now prefixed with TWO labels instead of one. My understanding is that this change was made to align with the work being done to standardize domain verification techniques [3] in the dnsop working group. Unfortunately, I think it's reasonable to interpret BR 3.2.2.4.7 as only permitting a single label to be prepended to an ADN: "an Authorization Domain Name that is prefixed with a Domain Label that begins with an underscore character." Proposal: I would like to remove this barrier to automation as soon as possible, and prior to RFC publication. I can see two ways to accomplish this: 1. Add the current draft spec for dns-account-01 to the BRs as a new validation method. There is precedent for supporting draft versions of ACME validation methods in the BRs (3.2.2.5.6 originally referenced a draft RFC) 2. Tweak the existing 3.2.2.4.7 language to allow one or two labels to be prepended to an ADN. I would appreciate everyone's feedback on how best to approach this and any concerns that you may have. Thanks, Wayne [1] Note that Michael Slaughter is working on a ballot that will clarify the requirements for DNS delegation to CAs: https://github.com/slghtr-says/servercert/pull/1 [2] https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/ [3] https://datatracker.ietf.org/doc/draft-ietf-dnsop-domain-verification-techniques/ This is issue 486: https://github.com/cabforum/servercert/issues/486 _______________________________________________ Validation mailing list Validation at cabforum.org https://lists.cabforum.org/mailman/listinfo/validation -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 8445 bytes Desc: not available URL: From Corey.Bonnell at digicert.com Tue Apr 16 16:24:01 2024 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Tue, 16 Apr 2024 16:24:01 +0000 Subject: [cabf_validation] 2024-04-18 Meeting Agenda Message-ID: Hello, Proposed agenda for this Thursday's validation-sc meeting is as follows: 1. Status update on EVG automation improvement ballot 2. Status update on 3.2.2.4 (7) improvement ballot 3. Discussion on dns-account-01 draft (https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/00/) 4. Identifying DTPs in the context of domain validation a. Continuing with method 19 Scheduled minute-taker: Andrea As always, if you have any additional agenda items, please reply to this email. Thanks, Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5231 bytes Desc: not available URL: From anetaw at microsoft.com Sun Apr 21 14:05:26 2024 From: anetaw at microsoft.com (Aneta Wojtczak-Iwanicka) Date: Sun, 21 Apr 2024 14:05:26 +0000 Subject: [cabf_validation] 2024-03-21 Minutes of the Validation Subcommittee [DRAFT] Message-ID: Hi All, Below DRAFT minutes from the March 21st meeting of the Validation WG. Meeting Notes: Validation Subcommittee Call Participants: * Tephen Davidson (DigiCert) * Aaron Poulsen - Amazon Trust Services * Clint Wilson * Aggie Wang-TrustAsia * David Kluge * Scott Rea ? eMudhra * Thomas Zermeno - SSL.com * Wayne Thayer * Bhat Abhishek ? eMudhra * Cade Cairns - Google Trust Services * Jay Wilson ? Sectigo * Michael Slaughter Amazon Trust Services * Chris Clements - Google Chrome * Rollin Yu ? TrustAsia * Martijn Katerbarg ? Sectigo * Miguel Sanchez GTS * Pekka Lahtiharju / Telia * Keshava N ? eMudhra * Tobias Josefowitz Opera * Roman Fischer ? SwissSign * Trevoli Ponds-White - Amazon Trust Services * Ben Wilson ? Mozilla * Corey Rasmussen OATI * Greg Tomko ? GlobalSign * Dimitris Zacharopoulos (HARICA) * Nome Huang-TrustAsia * Nargis Mannan - Viking Cloud * Eva Van Steenberge - GlobalSign * Nate Smith ? GoDaddy * Ryan Dickson Google Chrome * Inigo Barreira * Michelle Coon (OATI) * Joe Ramm OATI * Aneta Wojtczak - Microsoft Meeting Agenda: 1. Wayne Thayer read the note well statement 2. Approval of Previous Minutes * Approval of minutes from March 7th, which were sent out by Janet on March 17th, was approved without objections. 3. Status update for MPIC * Chris Clements (Google Chrome) reported on the recent initiation of the public discussion regarding the MPIC ballot, which started on a Monday (March 18th , 2024). He noted that feedback from Dimitris suggested extending the original discussion period. As a result, the discussion period was extended from 21 days to at least 30 days to allow ample time for stakeholders to consult with their legal teams concerning related to the IP disclosure commitments. The current public discussion period was scheduled to conclude in the second half of April, followed by any subsequent periods necessary for further deliberations. * Wayne Thayer expressed enthusiasm about the progress of the MPIC ballot and encourage everyone to take a look at it. 4. Status update for EVG automation language improvements (Comparing cabforum:main...chrisbn:improve-evg-automation-issue-467 ? cabforum/servercert ? GitHub) * Eva Van Steenberge (GlobalSign) detailed the structural changes made to the automation language, focusing on the differentiation between text revisions from the last face-to-face meeting and the current version. Significant emphasis was placed on aligning the text with practical requirements and making it more user-friendly by simplifying the language and restructuring content for clarity. * Reference to due diligence and cross-correlation: Eva Van Steenberge explained the necessity of ensuring all validation steps not only comply with EV guidelines but also consistently support the issuance of certificates. The language there was adjusted to make it less like definition and more like a requirement. There was a reference added what was out-scoped (rather than verification of ?Domain Name(s)). * Dimitris Zacharopoulos recommended to leave is with a reference to 11.7. (Due diligence and domain validation 11.13 slide) * In regards to domain validation and cross-correlation - there was a discussion between Eva, Tobias, Dimitris and Ben about linking between the organization name and the domain name. Group decided to leave it out for now and come back to this discussion later if required. * Requirements for Re-use of existing Documentation (11.14) ? Eva added references in this section. Minor tweaks. There was some feedback received about too restrictive language but they have not received a proposal for alternative language, so Eva encouraged to provide the feedback. * Separation of Duties (14.1.3) ? Eva Van Steenberge mentioned that there were a few small changes. The refence was included and some language changes were made. * Detailed feedback was provided by Ben Wilson regarding the interpretation and implications of due diligence definitions. The discussion emphasized the need for clarity to prevent future misunderstandings. 5. DNS Validation Improvements (3.2.2.4.7) (Proposal: Modify section 3.2.2.4.7 to allow CA Assisted DNS Validation by slghtr-says ? Pull Request #1 ? slghtr-says/servercert ? GitHub) * Michael Slaughter (Amazon Trust Services) provided updates on the feedback incorporated into DNS validation improvements. He detailed the upcoming steps for introducing these changes to the Certificate Server working group and mentioned a timeline for further review and finalization. * Michael put out a last call for additional feedback, with a plan to introduce the revised language by April 4th. 6. Identifying DTPs in the context of domain validation * Wayne Thayer led a discussion on identifying delegated third parties in the context of domain and IP address validation. The group discussed methods to evaluate and prioritize based on usage and importance, with an emphasis on those required by Apple first (Clint Wilson: as of August 15th this year Apple will require all TLS providers to support at least 1 of 4 specific methods 7, 18, 19, 20). * Dimitris Zacharopoulos suggested that after discussing those 4 methods (7, 18,19, 20), the one where email is sent should be prioritized (method 2 and 4). * Michael Slaughter suggested that method 13 and 14 should be included in the next set suggested by Dimitris. * Wayne Thayer asked if group wants to evaluate a method when a phone call is in use. * Dimitris Zacharopoulos responded that for the consistency group should evaluate those ones as well and asked if we are allow to use SMS providers that are sending messages to cell phones. * Wayne Thayer responded that this would encompass method 2 as well since it includes fax and SMS. * Wayne Thayer said next methods to discuss will 15 and 16 this will covers pretty much all the methods. * Dimitris Zacharopoulos stated that there is 3.2.2.4.8 (Confirming the Applicant?s control over the FQDN by confirming that the Applicant controls an IP * address returned from a DNS lookup for A or AAAA records for the FQDN in accordance with Section 3.2.2.5). * Wayne Thayer noticed that the one method that the group has not covered is method 12 validating the applicant as a domain contact and this is a special method where the is also a domain name register. Wayne Thayer stated: It's not immediately apparent to me that delegated 3rd parties play much of a role in that method. * Dimitris Zacharopoulos agreed. * Wayne Thayer: summarized the prioritization: the 4 methods that Apple is going to require. The methods that require email validation, the methods that require telephone or SMS validation and then anything else that?s remaining. 7. Identifying DTPs in the context of IP address validation * Wayne Thayer listed the methods: agreed upon change to a website, email fax SMS or postal mail to IP address contact, reverse address lookup, phone contact and ACME. * Wayne Thayer asked whether we are going to cover some of those methods as we do the review for domain names. It seems like change to website and two ACME methods. Do we think we need to do a separate analysis of these in the context of IP addresses? It looks like delegated 3rd parties would not be any different whether it's a domain name or an IP address. * Michael Slaughter said that he does not see the difference. * Wayne Thayer stated that it makes sense to group those methods in with the domain name reviews. When we review the Acme methods for domain names we will also consider IP addresses, so that would put the 2 ACME methods in the 1st group as well agreed upon change to website. And then it would put the email fax SMS or postal mail and the 2nd group. Then there's a phone contact, which would be in the 3rd group. Then the only thing that's left is the reverse address lookup mechanism which could fall in the final group. 8. Meeting adjourned. Thanks, Aneta -------------- next part -------------- An HTML attachment was scrubbed... URL: From Corey.Bonnell at digicert.com Tue Apr 30 14:53:35 2024 From: Corey.Bonnell at digicert.com (Corey Bonnell) Date: Tue, 30 Apr 2024 14:53:35 +0000 Subject: [cabf_validation] 2024-05-02 Meeting Agenda Message-ID: Hello, Proposed meeting agenda for this week: 1. Discussion on identifying DTPs in domain validation a. Methods 2 & 4 Scheduled minute-taker: Dimitris As always, if you have any additional agenda items, please reply to this email. Thanks, Corey -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5231 bytes Desc: not available URL: