From sleevi at google.com Thu Dec 3 01:31:05 2020 From: sleevi at google.com (Ryan Sleevi) Date: Wed, 2 Dec 2020 20:31:05 -0500 Subject: [cabf_validation] Validation methods used for Wildcards/ADNs Message-ID: Hey all, I know we're not quite done with the certificate profile work, and I'm not wanting to distract from that too much. However, one of the long-standing items we had from our Herndon, VA validation summit (from Meeting 43) was in harmonizing the rules around what 3.2.2.4 methods can be used for Authorization Domain Names / Wildcard Domain Names. I made an initial attempt at https://github.com/cabforum/servercert/compare/main...sleevi:2020-12-01_Wildcard_Rules to capture this. In effect, allowing validation as an ADN is conceptually "the same as" allowing a Wildcard Domain Name, since the ADN can authorize all children/grandchildren/etc of a domain, and a Wildcard is just a cert that works for all children of a domain. As we've become aware of some CAs having poorly evaluated the security risks in this space, we'd like to try to close this gap. Here's the TL;DR summary - 3.2.2.4.6: Agreed-upon Change to Website - Sunset 2020-06-03 for new validations - 3.2.2.4.18: Agreed-upon Change to Website v2 - 3.2.2.4.19: Agreed-upon Change to Website - ACME (The other bits are just aligning some of the language, so that "MAY NOT" becomes a clearer "MUST NOT", even though we mean the same) These methods are proposed to *only* authorize a single FQDN, because they only demonstrate control over a specific service/port on a specific FQDN, and not demonstration of control over the whole domain namespace. This aligns with 3.2.2.4.20 (TLS using ALPN), which also only demonstrates control over a single service/port on a single FQDN. This doesn't touch 3.2.2.4.4 (Constructed Email to Domain Contact), although we identified that one as potentially messy. However, hopefully we'll see that one fully sunset separately, in favor of the improved CAA methods (.13 - .17). It'd be useful to spend a few minutes on the call discussing folks initial reactions. The big question, as always, is going to be timelines for changes. If folks think more time is needed than "immediately", my request is that they'd share concrete data. Since Ballot 190 (2017-09-19), CAs have been required to maintain records of the validation methods they use, so this "should" be as easy as scanning all unexpired validations for these three methods and identifying cetrs which have a SAN that doesn't equal the validated FQDN (e.g. a cert with " www.example.com" when the method used was 3.2.2.4.6 for "example.com"). Just sharing those numbers is useful to understand any challenges CAs might face. For example: - 30% of our certificates used 3.2.2.4.6. Of that 30%: - 80% of our certificates had at least one FQDN validated by ADN, with 40% of that being "www.". - Of the 20% that had >1, we saw an average of 7.3 additional FQDNs validated by FDN. - 17% of our certificates used 3.2.2.4.18. of that 17% .... - 80% of the FQDNs validated by ADNs were for domains that did not resolve (e.g. "internal.corp.foo.example"), and thus would have to switch to a new validation method or expose those services publicly. This sort of concrete data helps understand the impact to CAs, and their customers, and thus indirectly, our users. It also helps figure out what reasonable time frames to phase in could be, in the unlikely event a phase-in became necessary. This sunset "should" be fairly simple and uncontroversial, but since there are edge cases (like internal servers), concrete data like the above is useful if folks have concerns. -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.beattie at globalsign.com Thu Dec 17 16:41:20 2020 From: doug.beattie at globalsign.com (Doug Beattie) Date: Thu, 17 Dec 2020 16:41:20 +0000 Subject: [cabf_validation] Minutes of the Validation Subcommittee call on 2020-12-17 Message-ID: Minutes of the CA/B Forum ServerCert WG Validation Subcommittee meeting Thursday, December 17, 2020 Antitrust statement was read. Attendees: Andrea Holland , Ben Wilson, Bruce Morton, Clint Wilson, Corey Bonnell, Daniela Hood, Dimitris Zacharopoulos, Doug Beattie, Janet Hines, Joanna Fox, Johnny Reading, Niko Carpenter, Paul van Brouwershaven, Rebecca Kelley, Ryan Sleevi, Tim Hollebeek, Wayne Thayer, Wendy Brown Agenda * Cert profile work: Everyone has been busy on other things and there is nothing to review this week. Ryan provide a status update: * Pandoc Integrations have landed * If you update the BRs then you?ll be able to get PDF generation for your document. * Ryan suggested that Cory check in the profile table work and verify that pdf gen works on the profile table section. * You should be able to do this for any markdown file, with some tricks, so Corey may take that approach Ryan, reminded us of the Google discussion to limit the use of the domain validation method 3.2.2.4.6 Agreed-Upon Change to Website: * Validation via this method should not be used for wildcard or subdomains, per previous discussions. In order to set an appropriate effective date, he asks that CAs examine the domain validation data (recording such data has been a requirement in 3.2.2.4 for some time) and provide feedback on how this change will impact them or their customers. * Ryan wants to require this in 2021, but the timeline should be data driven. Dimitris: Would like clarification on one section for prior minutes. Ryan to provide feedback shortly. Next meeting is January 14th If I missed anything, let me know. Doug -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5708 bytes Desc: not available URL: From sleevi at google.com Thu Dec 17 17:00:10 2020 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 17 Dec 2020 12:00:10 -0500 Subject: [cabf_validation] Minutes of the Validation Subcommittee call on 2020-12-17 In-Reply-To: <010001767193e1c3-18e16e1e-a37a-4717-aaf5-3b19c2d44dc3-000000@email.amazonses.com> References: <010001767193e1c3-18e16e1e-a37a-4717-aaf5-3b19c2d44dc3-000000@email.amazonses.com> Message-ID: On Thu, Dec 17, 2020 at 11:41 AM Doug Beattie via Validation < validation at cabforum.org> wrote: > Minutes of the CA/B Forum ServerCert WG Validation Subcommittee meeting > Thursday, December 17, 2020 > > Antitrust statement was read. > > Attendees: > Andrea Holland , Ben Wilson, Bruce Morton, Clint Wilson, Corey Bonnell, > Daniela Hood, Dimitris Zacharopoulos, Doug Beattie, Janet Hines, Joanna > Fox, Johnny Reading, Niko Carpenter, Paul van Brouwershaven, Rebecca > Kelley, Ryan Sleevi, Tim Hollebeek, Wayne Thayer, Wendy Brown > > Agenda > * Cert profile work: Everyone has been busy on other things and there is > nothing to review this week. > > > Ryan provide a status update: > > * Pandoc Integrations have landed > * If you update the BRs then you?ll be able to get PDF generation for your > document. > * Ryan suggested that Cory check in the profile table work and verify that > pdf gen works on the profile table section. > Typo: Corey :) > * You should be able to do this for any markdown file, with some tricks, > so Corey may take that approach > > Ryan, reminded us of the Google discussion to limit the use of the domain > validation method 3.2.2.4.6 Agreed-Upon Change to Website: > > * Validation via this method should not be used for wildcard or > subdomains, per previous discussions. In order to set an appropriate > effective date, he asks that CAs examine the domain validation data > (recording such data has been a requirement in 3.2.2.4 for some time) and > provide feedback on how this change will impact them or their customers. > * Ryan wants to require this in 2021, but the timeline should be data > driven. > > Dimitris: Would like clarification on one section for prior minutes. Ryan > to provide feedback shortly. > > Next meeting is January 14th > > If I missed anything, let me know. > > Doug > _______________________________________________ > Validation mailing list > Validation at cabforum.org > https://lists.cabforum.org/mailman/listinfo/validation > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dzacharo at harica.gr Fri Dec 18 06:59:09 2020 From: dzacharo at harica.gr (Dimitris Zacharopoulos (HARICA)) Date: Fri, 18 Dec 2020 08:59:09 +0200 Subject: [cabf_validation] CABF: Minutes from the Validation Subcommittee meeting at 2020-12-03 Message-ID: <815fcc11-b148-9ffc-bd01-cfa9e77c129c@harica.gr> - Antitrust statement The Antitrust Statement was read. - Attendence Amanda Mendieta (Apple), Aneta Wojtczak-Iwanicka (Microsoft), Ben Wilson (Mozilla), Bruce Morton (Entrust), Clint Wilson (Apple), Corey Bonnel (Digicert), Daniela Hood (GoDaddy), Dimitris Zacharopoulos (HARICA), Doug Beattie (GlobalSign), Janet Hines (SecureTrust), Johnny Reading (GoDaddy), Michelle Coon (OATI), Niko Carpenter (SecureTrust), Paul van Brouwershaven (Entrust), Rebecca Kelley (Apple), Rich Smith (Sectigo), Ryan Sleevi (Google), Shelley Brewer (Digicert), Stephen Davidson (Digicert), Tim Hollebeek (Digicert), Wayne Thayer (Mozilla). - Agenda Two items were added to the agenda: 1. Wildcard and ADN validation 2. Extensions based on BRs 7.1.2.4 - Wildcard and ADN validation Ryan sent a message on the list about concerns raised in meeting #43 around Domain Validation methods related to agreed-upon change to a website. These methods practically demonstrate control for a particular Domain Name, the Domain Name of the website and not for the Domain Namespace. Change agreed upon change to web sites should not validate ADNs and wildcard certificates. DNS are ok for ADNs and wildcards. Ryan would like to propose that it becomes effective immediately, around February 2021. If CAs anticipate problems with that timeline, they should send feedback with some useful data, since this is one of the automatable methods that doesn't really need human interaction. He is looking for initial reactions, challenges anticipated, any useful feedback would help during the preparation of the ballot. Doug mentioned that Globalsign uses this method for Enterprise accounts so they can validate their Domain and then issue Certificates to sub-domains. It can be typically automated but not all systems on these Enterprises can use ACME. This would be something GS would like to push down the road, more than February 2021 so they can let their customers know this is coming. Doug also mentioned that it is important to know how we will handle validation re-use for sub-domains that were validated using these methods after this change is made. Will they immediately expire or have a transition? Ryan said that this is where the email touches on, to trigger discussion on such challenges. For example, he expects not resolvable subdomain validations to be a challenge using these methods for these subdomain validations. Ryan describes in his email what sort of data would be useful for CAs to collect and present. He is not opposed to pushing the date down the road but we should do this based on actual data. He proposed CAs to collect statistics and useful data for a concrete discussion. This would help set a better timeframe. CAs could also indicate their timeline to get this data, if they decide to do so. He agrees that examination of data takes time but CAs can mention how much time they need to collect this data. We certainly need to understand the impact before going forward. Dimitris asked Ryan that in his email, the "www" label was mentioned separately when looking for statistics. It appeared as a "special case" and was curious if there were any plans for an exception. Ryan replied that there was no intention of having an exception or "special treatment" for the "www" label. If the "www" is in the same server as the bare domain, it should be easy for the CA to use the same validation challenge for both domains. Two connections would be required to the two Domain Names but they could use one random value. For example, today the CA can validate example.com connect to example.com and get authorization to issue for www.example.com. After this update, the CA would need to connect to example.com and to www.example.com to get the same random value to issue for www.example.com and example.com. Tim mentioned that the "www" label was used as a special case in the past because of how browsers treated this label, adding it automatically in some cases. He described a workaround for users that typed bare domain names in the address bar and browsers would historically do things like "let's see what happens if I add www to this". Ryan said this behavior has changed for the better and does not apply for almost a decade. Now you would need to do [CONTROL - ENTER] to "magically" add the www, and no one really knows about this behavior. Ryan suggested to use the mailing list for first reactions, possible gotchas and in case CAs need time to gather data, they should just mention how much time they would need, it would be very useful. Tim said that there should be some convergence and deadline on data feedback so this process doesn't go on forever. Wayne added that there is a combination of factors (notifying customers, validation systems need to be modified, what has to happen with previously validated data) that make this proposed change clearly not happening overnight. He wasn't sure why the initial proposal was from the perspective of "let's make this effective immediately" and request data to push this forward, instead of taking the historically and typical approach proposing it to be effective 6 months after the ballot is effective. The 6 month effective time seems more realistic with this ballot and would help us move more quickly than trying to get data from people. Ryan said that we set the standard to 3 months, not 6. The collection of data can help us tweak the effective dates. The goal is not to rush this through in February but get data to support informed decisions. We have a number of variables that need to be sorted out. Tim echoed Wayne's point and also recalled that the default was 6 months de-facto used, and Tim had proposed more than 3 years ago that 3 years should be the default for complicated ballots. Ryan replied that we said 90 days and he could dig up the archives. Tim said that he wouldn't be surprised if at different times, different people proposed different timelines but 6 months is the number he recalls as the agreed upon timeline. Ryan said that the goal is not to produce a big impact in February but rather get some concrete data so we can find the right timelines. Also, if CAs ask for specific time to gather information, that would be very reasonable and helpful. He is concerned about some CAs using these validation methods to issue wildcard certificates which exposes users at a greater risk. Some CAs have been conscientious about the discussion in Virginia and taking the right steps for not using these methods for wildcard certificates. - Extensions based on BRs 7.1.2.4 Dimitris asked why using the cabfOrganizationIdentifier extension with the validation rules described in the EV Guidelines would not be considered acceptable for the OV level. Ryan replied that there is no blanket "yes/no" answer because it is the CA's burden to demonstrate how it meets 7.1.2.4 a and b. Tha CA can't make up their own rules. Even using the same extension OID that is specifically designed for EV Certificates in an OV Certificate might be considered to fail b (misleading). In the email there was an example to use orgId and there was extensive discussion in the context of LEIs and why there has not been any acceptable method proposed that can demonstrate both that the Applicant is entitled to assert that information and that this information has been appropriately verified. The current proposed methods to verify the organization identifier do not meet 7.1.2.4 a or b. Some private EKUs have also been included and CAs have demonstrated how 7.1.2.4 a and b apply. It would be best to start from a position that this is not permitted and work to demonstrate how 7.1.2.4 a and b are fulfilled. Dimitris clarified that he had VAT in mind, because that's in the current EV Guidelines so it is used in the public Internet, with clear validation rules so why can't a CA use this in an OV Certificate. Ryan said that the link between the VAT number and an organization relies on the strong organization validation that is described in the EV Guidelines. The same level of assurance for organization validation does not apply in OV Certificates. If a CA uses this information in an OV Certificate, they have to demonstrate that that validation is the same but in the example Dimitris gave this is tied to an EV Certificate. You can't just take EV extension data and move it to an OV Certificate. Tim commented that what Ryan said means that using an EV validation method for an extension related to an OV certificate in an OV validated organization, the validation method used is "too good" for an OV Certificate. Ryan clarified that the ability to validate a VAT number is tied to the stronger validation method done for the organization. The same problem was with the LEI. How do you match that the LEI number is actually issued to the organization asserted in the subject and this is where LEI is messy because you need to figure out how to do that mapping. VAT is roughly the same. You have an organization validated to some level, OV, that doesn't give as strong validation as EV that you are actually dealing with the specific organization referenced in that VAT number. So you can't just add the VAT number because in order to validate that it assumes you have strongly validated data to match against which is the output of the EV Validation process. Tim disagreed. Validating an organization at the OV level means that the identity of that organization has been validated at that level. So we already have an organization there and we just need to validate the VAT number against that organization. The level of rigor is that of an OV level. Dimitris added to Tim's point that once an organization is validated at the OV level, the mapping between the organization and the VAT number is easy. Ryan responded that there are different levels of organization validation and the orgID and the corresponding extension relies on the higher assurance organization validation following the EV process. The specific example that Dimitris described is not allowed. In any case, he suggested that any CA should consider that something is not allowed and work on the 7.1.2.4 language to demonstrate that it meets the requirements. Fully copying an extension specifically designed for an EV Certificate described in the EV Guidelines and using it in the BRs does not automatically meet 7.1.2.4 requirements and Ryan believes it misleads Relying Parties about the information verified by the CA, because it?s an extension defined for EV certificates. The CA also needs to demonstrate that this extension is technically relevant in the context of the public Internet, which is not just ?it?s useful?. Alternatively, if it?s not technically relevant to TLS certificates, then you can include it as an extension OID that is specific to each Applicant, as discussed in 7.1.2.4(a)(i). However, you can?t just reuse existing extensions from other profiles, because of 7.1.2.4(b), and for something like VAT numbers, it doesn?t pass the sniff test for 7.1.2.4(a)(ii) - Certificate Profiles No specific progress on the certificate profiles. Ryan reported that automation landed in the servercert repository to automatically build docx, pdf versions. Ryan tested tables with "column span" and other formatting approaches trying to improve readability and preview how things look in the produced pdf, docx files. "Column span" is currently not supported as it does in the spreadsheet. Pandoc added support this past July/August but it's not yet integrated in the "pdf-writer" or "docx-writer". Everyone that syncs/forks the servercert repository should be in a position to see how PDFs are produced and tweak the markdown for better table representation. Tim asked Ryan how frequently do we use "Column span" on the produced docs. Ryan said the current documents don't support it but the Google spreadsheet uses it extensively. He is still working on these tables to find a good solution. The Subcommittee decided to cancel the call on December 31st. Next call is scheduled for the Dec 17th Adjurned -------------- next part -------------- An HTML attachment was scrubbed... URL: From adriano.santoni at staff.aruba.it Fri Dec 18 09:55:44 2020 From: adriano.santoni at staff.aruba.it (Adriano Santoni) Date: Fri, 18 Dec 2020 10:55:44 +0100 Subject: [cabf_validation] Validation methods used for Wildcards/ADNs In-Reply-To: <01000176263a0683-ff521ee9-a82d-4338-a8fd-7a80380cbe1b-000000@email.amazonses.com> References: <01000176263a0683-ff521ee9-a82d-4338-a8fd-7a80380cbe1b-000000@email.amazonses.com> Message-ID: <51a1f2f0-e1f9-3106-dae9-a0a393ec2aaa@staff.aruba.it> Ryan, do I understand correctly that your post below implies the following? (first bullet is just a typical example, of course it would be the same for all subdomains) * if domain validation is passed on (say) domain.tld by the website change method (?3.2.2.4.6), then a certificate containing www.domain.tld MUST NOT be issued * if domain validation is passed on (say) domain.tld by the website change method (?3.2.2.4.6), then a certificate containing *.domain.tld MUST NOT be issued Adriano Il 03/12/2020 02:31, Ryan Sleevi via Validation ha scritto: > Hey all, > > I know we're not quite done with the certificate profile work, and I'm > not wanting to distract from that too much. However, one of the > long-standing items we had from our Herndon, VA validation summit > (from Meeting 43) was in harmonizing the rules around what 3.2.2.4 > methods can be used for Authorization Domain Names / Wildcard Domain > Names. > > I made an initial attempt at > https://github.com/cabforum/servercert/compare/main...sleevi:2020-12-01_Wildcard_Rules > > to capture this. In effect, allowing validation as an ADN is > conceptually "the same as" allowing a Wildcard Domain Name, since the > ADN can authorize all children/grandchildren/etc of a domain, and a > Wildcard is just a cert that works for all children of a domain. > > As we've become aware of some CAs having poorly evaluated the security > risks in this space, we'd like to try to close this gap. Here's the > TL;DR summary > > * 3.2.2.4.6: Agreed-upon Change to Website > o Sunset 2020-06-03 for new validations > * 3.2.2.4.18: Agreed-upon Change to Website v2 > * 3.2.2.4.19: Agreed-upon Change to Website - ACME > > (The other bits are just aligning some of the language, so that "MAY > NOT" becomes a clearer "MUST NOT", even though we mean the same) > > These methods are proposed to *only* authorize a single FQDN, because > they only demonstrate control over a specific service/port on a > specific FQDN, and not demonstration of control over the whole domain > namespace. This aligns with 3.2.2.4.20 (TLS using ALPN), which also > only demonstrates control over a single service/port on a single FQDN. > > This doesn't touch 3.2.2.4.4 (Constructed Email to Domain Contact), > although we identified that one as potentially messy. However, > hopefully we'll see that one fully sunset separately, in favor of the > improved CAA methods (.13 - .17). > > It'd be useful to spend a few minutes on the call discussing folks > initial reactions. The big question, as always, is going to be > timelines for changes. If folks think more time is needed than > "immediately", my request is that they'd share concrete data. > > Since Ballot 190 (2017-09-19), CAs have been required to maintain > records of the validation methods they use, so this "should" be as > easy as scanning all unexpired validations for these three methods and > identifying cetrs which have a SAN that doesn't equal the validated > FQDN (e.g. a cert with "www.example.com " when > the method used was 3.2.2.4.6 for "example.com "). > Just sharing those numbers is useful to understand any challenges CAs > might face. > > For example: > > * 30% of our certificates used 3.2.2.4.6. Of that 30%: > o 80% of our certificates had at least one FQDN validated by > ADN, with 40% of that being "www.". > o Of the 20% that had >1, we saw an average of 7.3 additional > FQDNs validated by FDN. > * 17% of our certificates used 3.2.2.4.18. of that 17% .... > o 80% of the FQDNs validated by ADNs were for domains that did > not resolve (e.g. "internal.corp.foo.example"), and thus would > have to switch to a new validation method or expose those > services publicly. > > This sort of concrete data helps understand the impact to CAs, and > their customers, and thus indirectly, our users. It also helps figure > out what reasonable time frames to phase in could be, in the unlikely > event a phase-in became necessary. > > This sunset "should" be fairly simple and uncontroversial, but since > there are edge cases (like internal servers), concrete data like the > above is useful if folks have concerns. > > _______________________________________________ > 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: 4557 bytes Desc: Firma crittografica S/MIME URL: From sleevi at google.com Fri Dec 18 14:44:33 2020 From: sleevi at google.com (Ryan Sleevi) Date: Fri, 18 Dec 2020 09:44:33 -0500 Subject: [cabf_validation] Validation methods used for Wildcards/ADNs In-Reply-To: <010001767546e783-ad69e522-5a06-4701-a65f-59106fd09ad8-000000@email.amazonses.com> References: <01000176263a0683-ff521ee9-a82d-4338-a8fd-7a80380cbe1b-000000@email.amazonses.com> <010001767546e783-ad69e522-5a06-4701-a65f-59106fd09ad8-000000@email.amazonses.com> Message-ID: Yes, that is correct in how Authorization Domain Names and Wildcard Domain Names work, and precisely what this proposal sets forward to accomplish. This is because demonstrating the ability to edit a file on the web server is not equivalent to demonstrating you have controlver over DNS, as the other validation methods achieve, and is equivalent more to demonstrating control over an TLS handshake, where we have intentionally limited in the same way. On Fri, Dec 18, 2020 at 4:55 AM Adriano Santoni via Validation < validation at cabforum.org> wrote: > Ryan, > > do I understand correctly that your post below implies the following? > (first bullet is just a typical example, of course it would be the same for > all subdomains) > > - if domain validation is passed on (say) domain.tld by the website > change method (?3.2.2.4.6), then a certificate containing > www.domain.tld MUST NOT be issued > - if domain validation is passed on (say) domain.tld by the website > change method (?3.2.2.4.6), then a certificate containing *.domain.tld > MUST NOT be issued > > Adriano > > > Il 03/12/2020 02:31, Ryan Sleevi via Validation ha scritto: > > Hey all, > > I know we're not quite done with the certificate profile work, and I'm not > wanting to distract from that too much. However, one of the long-standing > items we had from our Herndon, VA validation summit (from Meeting 43) was > in harmonizing the rules around what 3.2.2.4 methods can be used for > Authorization Domain Names / Wildcard Domain Names. > > I made an initial attempt at > https://github.com/cabforum/servercert/compare/main...sleevi:2020-12-01_Wildcard_Rules > to capture this. In effect, allowing validation as an ADN is conceptually > "the same as" allowing a Wildcard Domain Name, since the ADN can authorize > all children/grandchildren/etc of a domain, and a Wildcard is just a cert > that works for all children of a domain. > > As we've become aware of some CAs having poorly evaluated the security > risks in this space, we'd like to try to close this gap. Here's the TL;DR > summary > > > - 3.2.2.4.6: Agreed-upon Change to Website > - Sunset 2020-06-03 for new validations > - 3.2.2.4.18: Agreed-upon Change to Website v2 > - 3.2.2.4.19: Agreed-upon Change to Website - ACME > > (The other bits are just aligning some of the language, so that "MAY NOT" > becomes a clearer "MUST NOT", even though we mean the same) > > These methods are proposed to *only* authorize a single FQDN, because they > only demonstrate control over a specific service/port on a specific FQDN, > and not demonstration of control over the whole domain namespace. This > aligns with 3.2.2.4.20 (TLS using ALPN), which also only demonstrates > control over a single service/port on a single FQDN. > > This doesn't touch 3.2.2.4.4 (Constructed Email to Domain Contact), > although we identified that one as potentially messy. However, hopefully > we'll see that one fully sunset separately, in favor of the improved CAA > methods (.13 - .17). > > It'd be useful to spend a few minutes on the call discussing folks initial > reactions. The big question, as always, is going to be timelines for > changes. If folks think more time is needed than "immediately", my request > is that they'd share concrete data. > > Since Ballot 190 (2017-09-19), CAs have been required to maintain records > of the validation methods they use, so this "should" be as easy as scanning > all unexpired validations for these three methods and identifying cetrs > which have a SAN that doesn't equal the validated FQDN (e.g. a cert with " > www.example.com" when the method used was 3.2.2.4.6 for "example.com"). > Just sharing those numbers is useful to understand any challenges CAs might > face. > > For example: > > - 30% of our certificates used 3.2.2.4.6. Of that 30%: > - 80% of our certificates had at least one FQDN validated by ADN, > with 40% of that being "www.". > - Of the 20% that had >1, we saw an average of 7.3 additional FQDNs > validated by FDN. > - 17% of our certificates used 3.2.2.4.18. of that 17% .... > - 80% of the FQDNs validated by ADNs were for domains that did not > resolve (e.g. "internal.corp.foo.example"), and thus would have to switch > to a new validation method or expose those services publicly. > > This sort of concrete data helps understand the impact to CAs, and their > customers, and thus indirectly, our users. It also helps figure out what > reasonable time frames to phase in could be, in the unlikely event a > phase-in became necessary. > > This sunset "should" be fairly simple and uncontroversial, but since there > are edge cases (like internal servers), concrete data like the above is > useful if folks have concerns. > > _______________________________________________ > Validation mailing listValidation at cabforum.orghttps://lists.cabforum.org/mailman/listinfo/validation > > _______________________________________________ > Validation mailing list > Validation at cabforum.org > https://lists.cabforum.org/mailman/listinfo/validation > -------------- next part -------------- An HTML attachment was scrubbed... URL: