From sleevi at google.com Thu Jan 14 16:43:05 2021 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 14 Jan 2021 11:43:05 -0500 Subject: [cabf_validation] Validation methods used for Wildcards/ADNs In-Reply-To: <01000176764fd8e8-cdc08798-1f8f-4a80-bff5-504f6fd1f229-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> <01000176764fd8e8-cdc08798-1f8f-4a80-bff5-504f6fd1f229-000000@email.amazonses.com> Message-ID: Just resurrecting this for the new year, and hoping people have had a chance to look at data. We'll work on circulating a concrete draft for the next call to accomplish this, but would love to have data to inform the timelines. On Fri, Dec 18, 2020 at 9:45 AM Ryan Sleevi via Validation < validation at cabforum.org> wrote: > 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 >> > _______________________________________________ > Validation mailing list > Validation at cabforum.org > https://lists.cabforum.org/mailman/listinfo/validation > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wthayer at gmail.com Thu Jan 14 18:17:53 2021 From: wthayer at gmail.com (Wayne Thayer) Date: Thu, 14 Jan 2021 11:17:53 -0700 Subject: [cabf_validation] Minutes of the Validation Subcommittee - January 14, 2021 Message-ID: Minutes of the Validation Subcommittee - January 14, 2021 Tim said that the list of minute takers is now on the wiki, so that volunteers can determine where they are in line. Clint agreed to take minutes at the next meeting. Tim read the antitrust statement. Attendance: Tim Hollebeek, Wayne Thayer, Clint Wilson, Enrico Entschew, Corey Bonnell, Shelley Brewer, Bruce Morton, Aneta Wojtczak, Ben Wilson, Dimitris Zacharopoulos, Daniela Hood, Paul VanBrouwershaven, Johnny Reading, Rebecca Kelley, Stephen Davidson, Trevoli Ponds-White, Janet Hines, Ryan Sleevi, Wendy Brown, Amanda Mendieta, Dean Coclin Tim began a discussion of the agenda by stating that Cory is working on tooling to display certificate profiles. Corey said he has it working locally - TLS profile output to PDF. Ryan has also been working on the tooling. Ryan said that his latest fixes haven?t landed but he?s looking at ways to make table management easier, with good results in PDF, HTML, and DOCX formats. Corey presented section 7 of the BR PDF file he?s been creating from the markdown he?s been working with. Some of the HTML formatting won?t work. Ryan said that HTML formatting doesn?t render in PDFs. He?s working on the ability to use markdown formatting within tables and will have that ready for the next call. Ryan said that different tables have different column widths. The PDF is currently formatted to A4 page size. We could change to A3 to get significantly more space for these tables. How important is printing? Dean said people in the US don?t have A3 paper. Dimitris said that people do print the BRs. Ryan said that people have large screens so the A3 format makes tables more readable. We can also reduce the font size. Corey asked if we can also produce HTML output? Ryan said yes, and of course the HTML will scale and the goal is to have HTML output. Tim suggested that a sans-serif font may be more readable in smaller sizes. Ryan said that he thinks we?re using a mix of serif and sans-serif fonts - we can mix and match. We are using sans-serif for section heads. He will add that change to the list of things to try. Tim: where are we at on the content of the profiles sections? Corey said that we were deciding how much indirection there would be - duplicating content versus referencing other tables. Ryan sent a mail on November 17th ( https://lists.cabforum.org/pipermail/validation/2020-November/001592.html). Ryan shared his screen. For 7.2.3, what are the relevant columns and how do we structure? Current columns are ?extensions ID?, ?required?, ?critical, ?permitted value(s)?, and ?references?. Ryan suggested we move references to a footnote, or make the ID a link to the reference. There is a lot of text in ?permitted value(s)?. Suggested that requirements be separated into rows and reference the relevant section for validation requirements. Corey said linking ?references? from the ?extension ID? is a good idea. Others agreed. Stephen said that there?s an issue when there is more than one reference. Trev said that footnotes are difficult because tables span multiple pages. Dimitris suggested changing these pages to landscape. Trev agreed. Ryan said that?s not possible for individual pages. He said that Jacob Hoffman-Andrews suggested splitting the doc into multiple markdown files. We could create section 7 in a separate file in landscape mode and then concatenate with the other sections. Ryan will provide examples of a few different options that we?ve discussed. Trev suggested also moving references to the name column under the name. Tim said that we could use references when a cell is complicated. The number of places we?d need to do this is small. Corey said that the references for the keyUsage field are the most complicated. Ryan said that we might break that out to a separate section, split out by RSA and EC keys. The idea is to give people fewer branches to follow within the document. Ryan said that next steps are to create some iterations and to make some structural suggestions (referencing Nov 17th email) Tim suggested that more people could get the tooling set up and play with this. Ryan said that the goal is that you can just go to the CAB Forum repo and it?s all set up for you to generate a PDF. Meanwhile, reach out to Ryan and he can help to get you set up to create PDFs from any markdown file. Corey said he is open to moving his work from DigiCert?s repo to CAB Forum. Tim said that we should migrate it if others want to offer suggestions. No one spoke up, so Ryan suggested that they wire up the GitHub actions to the DigiCert repo. Ryan raised another topic: 3.2.2.4.6 and wildcard certificates. Ryan is looking for data to determine how impactful banning this method for wildcard certs would be. This will inform phase-in timing. No one volunteered any data, so Ryan said that he would ask on the list again, and would put together a draft ballot. Tim added one more topic: there has been discussion of OUs on the list, and a ballot to ban them. Ryan said that he would support a ban and be happy to propose a ballot. Wayne said that he recalled a lot of discussion on the list and would like to review and revive that before moving forward. Ryan recapped the discussion on the list. OATI objected based on specific industry requirements for the use of that field. Entrust circulated a ballot (https://github.com/cabforum/servercert/pull/225) that didn?t address Ryan?s concerns. Paul said that there are some revisions in the GitHub comments, and another that was circulated via email. Paul has the sense that the ballot was headed in the right direction, but arguments for the topic are shut down. Paul said that he will circulate the latest ballot. He?s also willing to go down the path of forbidding the OU and see if that ballot passes. Ryan noted that this was discussed and suggested that members review the minutes of meeting 44 in London. It was on the working group day so the discussion may not be captured in the minutes. Corey said that it was also discussed in Bratislava. Tim said that we?d continue discussion of these last two items on the next call and asked if there are any other topics for today or next time. The call ended without further discussion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Paul.vanBrouwershaven at entrust.com Thu Jan 14 19:12:35 2021 From: Paul.vanBrouwershaven at entrust.com (Paul van Brouwershaven) Date: Thu, 14 Jan 2021 19:12:35 +0000 Subject: [cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements In-Reply-To: References: , Message-ID: This is the latest version of the proposed ballot to strengthen the validation requirements of the OU field: #### 3.2.2.1.1 Organizational Unit If the Subject Identity Information is to include an organizational unit, then it MUST be preceded or followed by a whitespace and one of the words ?unit?, ?department?, ?division?, ?group?, ?service", "system", "center", "office", ?school?, ?faculty?, "administration", "operations? in singular or plural form; or an unambiguous certified translation of the equivalent in a language other than English. The CA MUST verify the existence of the organizational unit using an Organizational Chart provided by the human resource offices of the Applicant or that is signed by a listed officer of Applicant. If a word in the value holds an active registration in the ?WIPO Global Brand Database? or a local business register the CA MUST only include these registered values when the CA has verified the right of usage in relation to the Applicant in accordance with Section 3.2. The value SHALL not be abbreviated unless this would exceed the maximum length of the `subject:organizationalUnitName` field, in which case it SHALL only use locally accepted abbreviation. i. __Certificate Field:__ `subject:organizationalUnitName` (OID: 2.5.4.11) __Required/Optional:__ __Optional__ if the `subject:organizationName` field is present. __Prohibited__ if the `subject:organizationName` is absent. __Contents:__ If present, the `subject:organizationalUnitName` field MUST contain the Subject's organizational unit name as verified under Section 3.2.2.1.1. ________________________________ From: Validation on behalf of Dimitris Zacharopoulos (HARICA) via Validation Sent: Monday, November 23, 2020 21:11 To: Ryan Sleevi Cc: CA/Browser Forum Validation SC List Subject: Re: [cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements Thank for the detailed response. It summarizes Google's viewpoint on several issues, including Identity. On 23/11/2020 8:45 ?.?., Ryan Sleevi wrote: The Baseline Requirements do not, nor have they ever, permitted CAs to include unverified, self-attested information. Every piece of information included in a certificate has a requirement to be validated by the CA, as captured by 7.1.2.4 of the BRs, as well as more specific individual requirements. It is unfortunate that a CA needs to be reminded of this, or of the principles and motivations, and this applies equally to LEI, OU, or any other field or data the CA might imagine here. The validation rules for OU are already in the BRs (7.1.4.2.2 i). They have been there for years. It has always been self-attested information. The CA had to "implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with Section 3.2 and the Certificate also contains subject:organizationName, subject:givenName, subject:surname, subject:localityName, and subject:countryName attributes, also verified in accordance with Section 3.2.2.1." I would like to highlight that 7.1.2.4 allows for "other fields and extensions" but during the organizationIdentifier discussion, you had expressed a preference that if this validated information were to be included, it should be in an extension rather than the subjectDN. Regarding the LEI, of course the CA would need to verify/validate the information included in the extension; I never implied that information would not be validated. In my previous post, I mentioned that "BRs allow custom extensions to be defined by CAs (and how CAs validate this information)", so I hope we're in agreement that this is still currently allowed, if a CA meets everything listed in 7.1.2.4. To use an example, if a CA were to define in its CP/CPS an extension that follows exactly the description of the cabfOrganizationIdentifier as described in section 9.8.2 of the EV Guidelines (my previous example was flawed), describe the same EVG validation rules for that extension and include this extension in an OV Certificate, wouldn't that be compliant with the BRs? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Thu Jan 14 19:16:35 2021 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 14 Jan 2021 14:16:35 -0500 Subject: [cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements In-Reply-To: References: Message-ID: I'll note the latest draft still suffers the same basic issues we've been discussing for years, without meaningful improvement. For example, it still relies on ambiguous, subjective interpretations, which has shown to result in a number of incidents for CAs. "Local business register" and "locally accepted abbreviation" are exactly the sort of issues that the Validation WG sought to meaningfully address, and which Entrust here has failed to do. Equally, the presumption of trust in the Applicant data is the very antithesis of validation, yet remains a core component of this proposal. As stated, we do not see a viable path forward for this, not (as it has been unfortunately stated) as an attempt to shut down discussion, but precisely because this fails to meet the bare minimum of addressing the systemic issues, and is thus not a remotely viable or acceptable "solution" to the problems identified and, unfortunately, practiced by CAs. On Thu, Jan 14, 2021 at 2:12 PM Paul van Brouwershaven < Paul.vanBrouwershaven at entrust.com> wrote: > This is the latest version of the proposed ballot to strengthen the > validation requirements of the OU field: > > *#### 3.2.2.1.1 Organizational Unit* > If the Subject Identity Information is to include an organizational unit, > then it MUST be preceded or followed by a whitespace and one of the words > ?unit?, ?department?, ?division?, ?group?, ?service", "system", "center", > "office", ?school?, ?faculty?, "administration", "operations? in singular > or plural form; or an unambiguous certified translation of the equivalent > in a language other than English. > > The CA MUST verify the existence of the organizational unit using an > Organizational Chart provided by the human resource offices of the > Applicant or that is signed by a listed officer of Applicant. > > If a word in the value holds an active registration in the ?WIPO Global > Brand Database? or a local business register the CA MUST only include these > registered values when the CA has verified the right of usage in relation > to the Applicant in accordance with Section 3.2. > > The value SHALL not be abbreviated unless this would exceed the maximum > length of the `subject:organizationalUnitName` field, in which case it > SHALL only use locally accepted abbreviation. > > i. *__Certificate Field:__* `subject:organizationalUnitName` (OID: > 2.5.4.11) > * __Required/Optional:__ * > *__Optional__* if the `subject:organizationName` field is present. > *__Prohibited__* if the `subject:organizationName` is absent. > *__Contents:__* If present, the `subject:organizationalUnitName` field > MUST contain the Subject's organizational unit name as verified under > Section 3.2.2.1.1. > > > ------------------------------ > *From:* Validation on behalf of > Dimitris Zacharopoulos (HARICA) via Validation > *Sent:* Monday, November 23, 2020 21:11 > *To:* Ryan Sleevi > *Cc:* CA/Browser Forum Validation SC List > *Subject:* Re: [cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU > validation requirements > > > Thank for the detailed response. It summarizes Google's viewpoint on > several issues, including Identity. > > On 23/11/2020 8:45 ?.?., Ryan Sleevi wrote: > > The Baseline Requirements do not, nor have they ever, permitted CAs to > include unverified, self-attested information. Every piece of information > included in a certificate has a requirement to be validated by the CA, as > captured by 7.1.2.4 of the BRs, as well as more specific individual > requirements. It is unfortunate that a CA needs to be reminded of this, or > of the principles and motivations, and this applies equally to LEI, OU, or > any other field or data the CA might imagine here. > > > The validation rules for OU are already in the BRs (7.1.4.2.2 i). They > have been there for years. It has always been self-attested information. > The CA had to "implement a process that prevents an OU attribute from > including a name, DBA, tradename, trademark, address, location, or other > text that refers to a specific natural person or Legal Entity unless the CA > has verified this information in accordance with Section 3.2 and the > Certificate also contains subject:organizationName, subject:givenName, > subject:surname, subject:localityName, and subject:countryName attributes, > also verified in accordance with Section 3.2.2.1." > > I would like to highlight that 7.1.2.4 allows for "other fields and > extensions" but during the *organizationIdentifier *discussion, you had > expressed a preference that if this *validated* *information *were to be > included, it should be in an extension rather than the subjectDN. > > Regarding the LEI, of course the CA would need to verify/validate the > information included in the extension; I never implied that information > would not be validated. In my previous post, I mentioned that "BRs allow > custom extensions to be defined by CAs (and how CAs validate this > information)", so I hope we're in agreement that this is still currently > allowed, if a CA meets everything listed in 7.1.2.4. > > To use an example, if a CA were to define in its CP/CPS an extension that > follows exactly the description of the *cabfOrganizationIdentifier* as > described in section 9.8.2 of the EV Guidelines (my previous example was > flawed), describe the same EVG validation rules for that extension and > include this extension in an OV Certificate, wouldn't that be compliant > with the BRs? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Paul.vanBrouwershaven at entrust.com Thu Jan 14 20:10:30 2021 From: Paul.vanBrouwershaven at entrust.com (Paul van Brouwershaven) Date: Thu, 14 Jan 2021 20:10:30 +0000 Subject: [cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements In-Reply-To: References: , Message-ID: I'll note the latest draft still suffers the same basic issues we've been discussing for years, without meaningful improvement. For example, it still relies on ambiguous, subjective interpretations, which has shown to result in a number of incidents for CAs. "Local business register" and "locally accepted abbreviation" are exactly the sort of issues that the Validation WG sought to meaningfully address, and which Entrust here has failed to do. Equally, the presumption of trust in the Applicant data is the very antithesis of validation, yet remains a core component of this proposal. In the initial version we proposed the same language as currently used in section 3.2 of the BR, this version is trying to address your comments to that version. I'm happy to create a definition for "Local business register" or you can suggest another term for official business registers. I don't think it's fair to argue that this proposal 'suffers the same basic issues' based on language that is currently accepted in other sections and not easily to replace without forbidding identity information in general. While I agree we should try to address all issues in the current requirements, but let's start that process instead of removing/blocking improvements based on the same principles. Another example, we also allow locally accepted abbreviations for the subject organization name, why would this not be accepted for the OU field? As stated, we do not see a viable path forward for this, not (as it has been unfortunately stated) as an attempt to shut down discussion, but precisely because this fails to meet the bare minimum of addressing the systemic issues, and is thus not a remotely viable or acceptable "solution" to the problems identified and, unfortunately, practiced by CAs. Personally, I think that the strong opinionated position from Google and the negativity towards any attempt to strengthen the requirements has prevented participation in a progressive discussion on improving the requirements on this list. I suggest that the validation working group starts to address the existing language in the requirements (and as proposed for this ballot) prior to any decision about the OU field removal. ________________________________ From: Ryan Sleevi Sent: Thursday, January 14, 2021 20:16 To: Paul van Brouwershaven Cc: Dimitris Zacharopoulos (HARICA) ; CA/Browser Forum Validation SC List Subject: Re: [cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements I'll note the latest draft still suffers the same basic issues we've been discussing for years, without meaningful improvement. For example, it still relies on ambiguous, subjective interpretations, which has shown to result in a number of incidents for CAs. "Local business register" and "locally accepted abbreviation" are exactly the sort of issues that the Validation WG sought to meaningfully address, and which Entrust here has failed to do. Equally, the presumption of trust in the Applicant data is the very antithesis of validation, yet remains a core component of this proposal. As stated, we do not see a viable path forward for this, not (as it has been unfortunately stated) as an attempt to shut down discussion, but precisely because this fails to meet the bare minimum of addressing the systemic issues, and is thus not a remotely viable or acceptable "solution" to the problems identified and, unfortunately, practiced by CAs. On Thu, Jan 14, 2021 at 2:12 PM Paul van Brouwershaven > wrote: This is the latest version of the proposed ballot to strengthen the validation requirements of the OU field: #### 3.2.2.1.1 Organizational Unit If the Subject Identity Information is to include an organizational unit, then it MUST be preceded or followed by a whitespace and one of the words ?unit?, ?department?, ?division?, ?group?, ?service", "system", "center", "office", ?school?, ?faculty?, "administration", "operations? in singular or plural form; or an unambiguous certified translation of the equivalent in a language other than English. The CA MUST verify the existence of the organizational unit using an Organizational Chart provided by the human resource offices of the Applicant or that is signed by a listed officer of Applicant. If a word in the value holds an active registration in the ?WIPO Global Brand Database? or a local business register the CA MUST only include these registered values when the CA has verified the right of usage in relation to the Applicant in accordance with Section 3.2. The value SHALL not be abbreviated unless this would exceed the maximum length of the `subject:organizationalUnitName` field, in which case it SHALL only use locally accepted abbreviation. i. __Certificate Field:__ `subject:organizationalUnitName` (OID: 2.5.4.11) __Required/Optional:__ __Optional__ if the `subject:organizationName` field is present. __Prohibited__ if the `subject:organizationName` is absent. __Contents:__ If present, the `subject:organizationalUnitName` field MUST contain the Subject's organizational unit name as verified under Section 3.2.2.1.1. ________________________________ From: Validation > on behalf of Dimitris Zacharopoulos (HARICA) via Validation > Sent: Monday, November 23, 2020 21:11 To: Ryan Sleevi > Cc: CA/Browser Forum Validation SC List > Subject: Re: [cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements Thank for the detailed response. It summarizes Google's viewpoint on several issues, including Identity. On 23/11/2020 8:45 ?.?., Ryan Sleevi wrote: The Baseline Requirements do not, nor have they ever, permitted CAs to include unverified, self-attested information. Every piece of information included in a certificate has a requirement to be validated by the CA, as captured by 7.1.2.4 of the BRs, as well as more specific individual requirements. It is unfortunate that a CA needs to be reminded of this, or of the principles and motivations, and this applies equally to LEI, OU, or any other field or data the CA might imagine here. The validation rules for OU are already in the BRs (7.1.4.2.2 i). They have been there for years. It has always been self-attested information. The CA had to "implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with Section 3.2 and the Certificate also contains subject:organizationName, subject:givenName, subject:surname, subject:localityName, and subject:countryName attributes, also verified in accordance with Section 3.2.2.1." I would like to highlight that 7.1.2.4 allows for "other fields and extensions" but during the organizationIdentifier discussion, you had expressed a preference that if this validated information were to be included, it should be in an extension rather than the subjectDN. Regarding the LEI, of course the CA would need to verify/validate the information included in the extension; I never implied that information would not be validated. In my previous post, I mentioned that "BRs allow custom extensions to be defined by CAs (and how CAs validate this information)", so I hope we're in agreement that this is still currently allowed, if a CA meets everything listed in 7.1.2.4. To use an example, if a CA were to define in its CP/CPS an extension that follows exactly the description of the cabfOrganizationIdentifier as described in section 9.8.2 of the EV Guidelines (my previous example was flawed), describe the same EVG validation rules for that extension and include this extension in an OV Certificate, wouldn't that be compliant with the BRs? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Thu Jan 14 20:34:31 2021 From: sleevi at google.com (Ryan Sleevi) Date: Thu, 14 Jan 2021 15:34:31 -0500 Subject: [cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements In-Reply-To: References: Message-ID: On Thu, Jan 14, 2021 at 3:10 PM Paul van Brouwershaven < Paul.vanBrouwershaven at entrust.com> wrote: > I'll note the latest draft still suffers the same basic issues we've been > discussing for years, without meaningful improvement. > > For example, it still relies on ambiguous, subjective interpretations, > which has shown to result in a number of incidents for CAs. "Local business > register" and "locally accepted abbreviation" are exactly the sort of > issues that the Validation WG sought to meaningfully address, and which > Entrust here has failed to do. Equally, the presumption of trust in the > Applicant data is the very antithesis of validation, yet remains a core > component of this proposal. > > In the initial version we proposed the same language as currently used in > section 3.2 of the BR, this version is trying to address your comments to > that version. I'm happy to create a definition for "Local business > register" or you can suggest another term for official business registers. > I don't think it's fair to argue that this proposal 'suffers the same basic > issues' based on language that is currently accepted in other sections and > not easily to replace without forbidding identity information in general. > Paul, I'm sure you're aware of the considerable effort here to ensure consistency on these points, such as Ballot SC30, so surely you're aware that there are explorations. However, as has already been addressed previously, with respect to _this_ specific field, those assumptions even valid for SC30 don't hold. Just because we've got a broken process (with demonstrable CA incidents) doesn't mean it's a solid foundation here. > While I agree we should try to address all issues in the current > requirements, but let's start that process instead of removing/blocking > improvements based on the same principles. > I believe we'll likely have to simply agree to disagree: this is not a meaningful improvement, compared to the issues identified. Arguing that we should "do something" rather than doing nothing is compelling, and that's exactly why it's relevant to remove this field, and ensure that any further introduction is sound from first principles. Another example, we also allow locally accepted abbreviations for the > subject organization name, why would this not be accepted for the OU field? > > As stated, we do not see a viable path forward for this, not (as it has > been unfortunately stated) as an attempt to shut down discussion, but > precisely because this fails to meet the bare minimum of addressing the > systemic issues, and is thus not a remotely viable or acceptable "solution" > to the problems identified and, unfortunately, practiced by CAs. > > Personally, I think that the strong opinionated position from Google and > the negativity towards any attempt to strengthen the requirements has > prevented participation in a progressive discussion on improving the > requirements on this list. > We've been incredibly supportive and receptive towards proposals that meaningfully improve things. This does not. The attempt to position all feedback as negative is misguided at best, disingenous at worst, and reflects a clear misunderstanding about the issues to be solved and the principles behind these issues. I realize that there are more substantial disagreements here, with respect to identity information as it applies to TLS certificates used in browsers. In particular, it would seem as if your disagreement about the operational risks to servers, and the security risks to users, that such information would pose, somehow justifies ignoring or dismissing our concerns. However, it also demonstrates exactly why we're at the impasse: there's no meaningful progress on understanding and addressing the concerns we have and have raised. It's not negativity to suggest that "2+2 = 5" is wrong, nor is it negativity to point out that this continues to fail to address concerns, despite the good faith efforts in explaining them. > I suggest that the validation working group starts to address the existing > language in the requirements (and as proposed for this ballot) prior to any > decision about the OU field removal. > We've spent 2+ years discussing this. Entrust came in at quite literally the last second with the suggestion that somehow we'd failed to consider things, and yet, as has been shown throughout, these options have been thought through, and still fail to address the concerns. That's not a failure on the WG part to engage, but a reflection of the innate problem of introducing subscriber-attested, unverified, non-authoritative data. Similarly, throughout this ballot, it has equally failed to even acknowledger the second-order effects on the security of users such data has, whether it be through the display of such information to end users, or the operational deployment practices, as recently seen on the questions@ list, which introduce significant risk to agility and security. Treating this as "only" a validation problem is to disregard the years of discussion had, and however tempting that might be, it's not progress. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron at letsencrypt.org Fri Jan 15 18:33:46 2021 From: aaron at letsencrypt.org (Aaron Gable) Date: Fri, 15 Jan 2021 10:33:46 -0800 Subject: [cabf_validation] Validation methods used for Wildcards/ADNs In-Reply-To: <0100017701c80c18-f9484d08-9126-47c1-b71b-58632e6a1700-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> <01000176764fd8e8-cdc08798-1f8f-4a80-bff5-504f6fd1f229-000000@email.amazonses.com> <0100017701c80c18-f9484d08-9126-47c1-b71b-58632e6a1700-000000@email.amazonses.com> Message-ID: Of the validation methods in question here, Let's Encrypt only uses 3.2.2.4.19 (Agreed-upon Change to Website - ACME, a.k.a. RFC 8555's HTTP-01). Let's Encrypt does not allow this method of validation to be used for wildcard names, so 0% of our certificates would be affected. Additionally, we often receive enquiries as to why we do not allow HTTP-01 for wildcards, so I would support having this language in the BRs. Aaron On Thu, Jan 14, 2021 at 8:43 AM Ryan Sleevi via Validation < validation at cabforum.org> wrote: > Just resurrecting this for the new year, and hoping people have had a > chance to look at data. > > We'll work on circulating a concrete draft for the next call to accomplish > this, but would love to have data to inform the timelines. > > On Fri, Dec 18, 2020 at 9:45 AM Ryan Sleevi via Validation < > validation at cabforum.org> wrote: > >> 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 >>> >> _______________________________________________ >> Validation mailing list >> Validation at cabforum.org >> https://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: From Bruce.Morton at entrust.com Fri Jan 15 20:14:12 2021 From: Bruce.Morton at entrust.com (Bruce Morton) Date: Fri, 15 Jan 2021 20:14:12 +0000 Subject: [cabf_validation] [EXTERNAL]Re: Validation methods used for Wildcards/ADNs In-Reply-To: <0100017701c80df4-145965c8-6bb4-4064-b2b9-11b6250bcdea-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> <01000176764fd8e8-cdc08798-1f8f-4a80-bff5-504f6fd1f229-000000@email.amazonses.com> <0100017701c80df4-145965c8-6bb4-4064-b2b9-11b6250bcdea-000000@email.amazonses.com> Message-ID: We are in favor of the proposed change, but our issue will be the effectivity date and the reuse of domains which are currently verified. We have implemented a system which only uses domain validation methods which can be used for Wildcards and ADNs. However, we will still have demand to use Method 18. This will mean that we will need to change our domain verification management system to have 2 types of verified domains: 1) CAN be used for Wildcard/ADNs and 2) CANNOT be used for Wildcard/ADNs. This could be a complex change in our current system. In addition we will want time for customers and integration partners which use Method 18 will need to re-tool, especially if they have verified domains which they think can be reused for up to 825-days. Even if the customer decides that they will no longer use Method 18, they may still need time to change how they will get their domains verified. Thanks, Bruce. From: Validation On Behalf Of Ryan Sleevi via Validation Sent: Thursday, January 14, 2021 11:44 AM To: Ryan Sleevi ; CA/Browser Forum Validation SC List Subject: [EXTERNAL]Re: [cabf_validation] Validation methods used for Wildcards/ADNs WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. ________________________________ Just resurrecting this for the new year, and hoping people have had a chance to look at data. We'll work on circulating a concrete draft for the next call to accomplish this, but would love to have data to inform the timelines. On Fri, Dec 18, 2020 at 9:45 AM Ryan Sleevi via Validation > wrote: 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 > 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 list Validation at cabforum.org https://lists.cabforum.org/mailman/listinfo/validation _______________________________________________ Validation mailing list Validation at cabforum.org https://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: From Paul.vanBrouwershaven at entrust.com Wed Jan 27 15:05:51 2021 From: Paul.vanBrouwershaven at entrust.com (Paul van Brouwershaven) Date: Wed, 27 Jan 2021 15:05:51 +0000 Subject: [cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements In-Reply-To: References: , Message-ID: Ryan, is it correct to state that your opinion we can't trust a verified Legal representative of an organization to provide the name of an organizational unit within the constraints we have defined in this proposal? I'm asking this because at the end of the day, the Legal representative is the source of trust for many legal-entity attributes used for legal entity identity validation on which CAs and other society pillars (government agencies, banks, property authorities, justice system and so on) rely on. ________________________________ From: Ryan Sleevi Sent: Thursday, January 14, 2021 21:34 To: Paul van Brouwershaven Cc: Dimitris Zacharopoulos (HARICA) ; CA/Browser Forum Validation SC List Subject: Re: [cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements On Thu, Jan 14, 2021 at 3:10 PM Paul van Brouwershaven > wrote: I'll note the latest draft still suffers the same basic issues we've been discussing for years, without meaningful improvement. For example, it still relies on ambiguous, subjective interpretations, which has shown to result in a number of incidents for CAs. "Local business register" and "locally accepted abbreviation" are exactly the sort of issues that the Validation WG sought to meaningfully address, and which Entrust here has failed to do. Equally, the presumption of trust in the Applicant data is the very antithesis of validation, yet remains a core component of this proposal. In the initial version we proposed the same language as currently used in section 3.2 of the BR, this version is trying to address your comments to that version. I'm happy to create a definition for "Local business register" or you can suggest another term for official business registers. I don't think it's fair to argue that this proposal 'suffers the same basic issues' based on language that is currently accepted in other sections and not easily to replace without forbidding identity information in general. Paul, I'm sure you're aware of the considerable effort here to ensure consistency on these points, such as Ballot SC30, so surely you're aware that there are explorations. However, as has already been addressed previously, with respect to _this_ specific field, those assumptions even valid for SC30 don't hold. Just because we've got a broken process (with demonstrable CA incidents) doesn't mean it's a solid foundation here. While I agree we should try to address all issues in the current requirements, but let's start that process instead of removing/blocking improvements based on the same principles. I believe we'll likely have to simply agree to disagree: this is not a meaningful improvement, compared to the issues identified. Arguing that we should "do something" rather than doing nothing is compelling, and that's exactly why it's relevant to remove this field, and ensure that any further introduction is sound from first principles. Another example, we also allow locally accepted abbreviations for the subject organization name, why would this not be accepted for the OU field? As stated, we do not see a viable path forward for this, not (as it has been unfortunately stated) as an attempt to shut down discussion, but precisely because this fails to meet the bare minimum of addressing the systemic issues, and is thus not a remotely viable or acceptable "solution" to the problems identified and, unfortunately, practiced by CAs. Personally, I think that the strong opinionated position from Google and the negativity towards any attempt to strengthen the requirements has prevented participation in a progressive discussion on improving the requirements on this list. We've been incredibly supportive and receptive towards proposals that meaningfully improve things. This does not. The attempt to position all feedback as negative is misguided at best, disingenous at worst, and reflects a clear misunderstanding about the issues to be solved and the principles behind these issues. I realize that there are more substantial disagreements here, with respect to identity information as it applies to TLS certificates used in browsers. In particular, it would seem as if your disagreement about the operational risks to servers, and the security risks to users, that such information would pose, somehow justifies ignoring or dismissing our concerns. However, it also demonstrates exactly why we're at the impasse: there's no meaningful progress on understanding and addressing the concerns we have and have raised. It's not negativity to suggest that "2+2 = 5" is wrong, nor is it negativity to point out that this continues to fail to address concerns, despite the good faith efforts in explaining them. I suggest that the validation working group starts to address the existing language in the requirements (and as proposed for this ballot) prior to any decision about the OU field removal. We've spent 2+ years discussing this. Entrust came in at quite literally the last second with the suggestion that somehow we'd failed to consider things, and yet, as has been shown throughout, these options have been thought through, and still fail to address the concerns. That's not a failure on the WG part to engage, but a reflection of the innate problem of introducing subscriber-attested, unverified, non-authoritative data. Similarly, throughout this ballot, it has equally failed to even acknowledger the second-order effects on the security of users such data has, whether it be through the display of such information to end users, or the operational deployment practices, as recently seen on the questions@ list, which introduce significant risk to agility and security. Treating this as "only" a validation problem is to disregard the years of discussion had, and however tempting that might be, it's not progress. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleevi at google.com Wed Jan 27 17:08:10 2021 From: sleevi at google.com (Ryan Sleevi) Date: Wed, 27 Jan 2021 12:08:10 -0500 Subject: [cabf_validation] [EXTERNAL] Draft Ballot SCXX: Improve OU validation requirements In-Reply-To: References: Message-ID: On Wed, Jan 27, 2021 at 10:05 AM Paul van Brouwershaven < Paul.vanBrouwershaven at entrust.com> wrote: > Ryan, is it correct to state that your opinion we can't trust a verified > Legal representative of an organization to provide the name of an > organizational unit within the constraints we have defined in this proposal? > > I'm asking this because at the end of the day, the Legal representative is > the source of trust for many legal-entity attributes used for legal entity > identity validation on which CAs and other society pillars (government > agencies, banks, property authorities, justice system and so on) rely on. > Paul, That's an interesting way to frame the question, and seems to reflect some of the problematic practices CAs used to perform, which thankfully, the CA/Browser Forum has forbidden. You may recall, for example, that Domain Authorization Documents are no longer accepted as proof of domain, precisely because they lack the necessary validation assurance. If we accept the framing of your question, then it seems that you'd be arguing that any verified Legal representative should be able to attest to control any domain name, and that's a perfectly fine and secure system. For that matter, applying more generally, the assumption of Legal representation should be sufficient, by the logic of your question, to authorize any delegation of domain validation. Thankfully, we know that browsers, and the Forum at large, have resoundingly rejected this. The Forum forbids delegation of domain validation, and explicitly prohibited the use of Domain Authorization Documents, precisely because they don't meet the level of assurance necessary. This was, of course, readily obvious, when considering "What are the consequences or recourse available if a legal opinion, from a party authorized in some jurisdiction, claimed that a malicious party operated google.com, rather than Google Inc". It was plain to see, to nearly everyone, that the consequences of such a thing would be disastrous, that limited recourse would be available to Google (depending on the jurisdiction in which the entity operated), and the CA would inevitably claim they did everything right, because they followed the letter of the requirement. Certification Authorities exist for one task: to issue certificates that contain _validated_ attributes that relying parties can rely upon. We have documents like the Baseline Requirements to ensure consistency among those attributes, for the purposes of TLS authentication within Browser (Certificate Consumers) products. Setting aside the very fundamental flaws in your OU proposal, regarding the fact that these attributes are not used for the purpose of TLS authentication, it's very clear and obvious that a proposal that simply relies upon self-attestation is, fundamentally, not a validation process, and merely transposition. Consider that a secondary purpose of the Baseline Requirements is to provide assurance, to Relying Parties, about the processes used to validate the information. As we've seen over the past decade, the industry has lost significant confidence in the competence and operation of a number of Certification Authorities, in part, because despite claiming to follow consistent guidelines, they failed to do so in practice. This has been readily detectable by comparing the outputs of a CA - the certificates - with the inputs - the appropriate and authoritative data sources, whether they be DNS or the appropriate registry for the jurisidction in question. One of the main activities of the Forum, over the past number of years, has been to move requirements from "the CA has an opinion that" to "the CA followed a defined and verifiable process that". A good example of this is SC30, in which CAs are required to disclose the sources they consider acceptable for validating business information, rather than simply requiring that they maintain an (internal only) list of acceptable sources. This is with the explicit goal of moving the industry towards consistent and verifiable processes. I highlight this, because a process that depends on verified Legal opinions lacks the transparency, consistency, and independent verifiability necessary, at least as proposed. As we've seen with respect to audits for subordinate CAs, we know of ample situations in which CAs inappropriately rely on the judgement or opinion of an unqualified third party, but due to the subjectivity permitted by the Requirements at the time, argue that this is not a failure of their basic duties of a CA. For example, relying on audits for subordinates that lack the necessary and required information, overlooking aspects of reports due to the CA's unfamiliarity with the necessary audit standards, or from auditors not appropriately qualified. If we learn from this past experience, it seems obvious that a substantial risk here is a CA inappropriately relying upon such a verified Legal opinion, either from an entity not appropriately qualified (but the CA mistakenly subjectively believes they are), or as a way of attempting to dismiss responsibility for validation, by instead blaming the third-party for any issues. This is not an acceptable outcome. All of this is important context to highlight the unacceptable risks with outsourcing what is nominally the core competency and expectation of a CA, the danger to relying parties and browsers in permitting CAs to do this, and the challenges and legal complexities that exist for such a method. Of course, most of this is mooted by the simple fact that such fields are not necessary for the establishment of TLS connections by browsers, and thus, for whatever value they have in certificates used for other purposes, are not needed in the certificates used by browsers. The risks of accepting such certificates, however, and the fundamental and structural challenges to mitigating those risks appropriately, is, however, simply untenable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From clintw at apple.com Thu Jan 28 18:31:11 2021 From: clintw at apple.com (Clint Wilson) Date: Thu, 28 Jan 2021 10:31:11 -0800 Subject: [cabf_validation] Minutes of the Validation Subcommittee - 28 Jan 2021 Message-ID: <9D912E75-5202-4793-A76B-9F9285BA4A14@apple.com> Validation Subcommittee Meeting - 28 Jan 2021 Antitrust statement was read Attendance: Tim Hollebeek, Wayne Thayer, Clint Wilson, Corey Bonnell, Aneta Wojtczak, Ben Wilson, Dimitris Zacharopoulos, Daniela Hood, Paul VanBrouwershaven, Johnny Reading, Rebecca Kelley, Janet Hines, Ryan Sleevi, Natalia Kotliarsky, Michelle Coon, Niko Carpenter, Andrea Holland, Trevoli Ponds-White, Rich Smith, Dean Coclin Agenda OUs Wildcard for ADN .onion validation Refresh of issues in GitHub Certificate profiles and tooling OUs Clint: Apple has reached out to some of the CAs that aren't in the CA/BF and found a number of usages that are not in-line with expectations. We've invited them to share those here, but are still waiting for that. That's all to say, we're making an effort to really understand what use-cases exist out there, but really haven't found any that change the picture much. Dimitris: Academic usage, like having the department or administrative unit in there. Usually it helps when the cert's about to expire, and get some requests. We validate the OUs by mapping the OU to subdomains. Paul: AT&T has tried to join as an interested party specifically for this topic, haven't quite managed to get in yet. Dimitris: I have a comment on Ryan?s last on-list response. I understand where he?s coming from that everything needs to be independently validated. We know the bootstrapping process includes, in his terms, self-reported information from the applicant for a new legal entity; things like address, postal address, phone numbers, even the name of the company is something that?s applied for. The Registration agency or agency of incorporation, verifies the eligibility of the applicant. So what are we validating for identity? we need to have an anchor somewhere. Ryan: Issues with Identity Verified and Stripe Inc are great examples, and go to what are reliable data sources. Using the UK as an example, with Companies House, they had quality issues and now there are a number of legal regulations to try to tamp down on those issues and introduce consequences. We're anchoring legal identity on the legal systems and jurisdictions. When an applicant comes in, they provide a bunch of information, but it's the job of the CA to validate that against the authoritative source. WIth OU, the official data source is the company itself. The essence of Paul's proposal is that the company makes the assertion, so that's good enough. The CA asking "Are you telling me the truth" is really not good enough. An applicant can attest "I have an OU of Google inc", and Paul's done some work to try to prevent that. The problem with OU is the proposals aren't reliable, repeatable, and independently verifiable. The OU doesn't have an authoritative data source. Dimitris: The CA would just need to verify that they're in communication with a legal rep. The legal rep is also who would change legal records. Isn't that similar/sufficient? Ryan: No, and this is the issue GLEIF is running into. They remove entities from their RA source. We assume there's a legal system backing these 3rd party sources and that if data is misreported, there's a consequence. If nothing bad happens, then it's not really an acceptable data source. They removed the Mexican Business register because it didn't have consequences, while the Tax service did. It's difficult to have consistent, reliable, repeatable verification that the legal rep is stating the same information. But assuming that we do have that, the next question is what are the consequences for if they lie or mislead? That varies widely by jurisdiction. How do you verify the legal rep? It's hundreds of pages long probably to describe the full process. Have they been disbarred or similar? What are the consequences if they give a bad opinion? The goal is to get to a point where, regardless of which CA you use, you get a consistent result in the certificate. Paul: Now we're going from that reliable data source, finding the legal rep, and that's where we're checking it. That's the person that's filling the tax forms and has control of the data sources. We've added additional roles around pre/suffixes. We've required they provide a directory structure showing the organizational unit. If we don't trust that information on that level, where we've strongly validated the information, that OU and the data in there is similarly validated as other DN information coming from the same source. Ryan: Your ballot doesn't do what you state it does, specifically the legal rep verification. That might not be intentional. Paul: We're trying to find a workable solution. I don't want to go on and propose 20 versions. I want to find out what's reasonable. If the legal rep verification isn't viable, then where do we go. I think we need to focus on the OU and the values that can go in there. The domain name is something you can validate in a technically controlled way, but that's not true of address or other DN fields. Ryan: We don't trust the legal rep, we trust the jurisdiction of incorporation. How that information gets into the data source isn't important. We trust the government data source; the fact that a legal rep populates that is independent of that. What's proposed here is different from everything else here. There are use-cases for why someone would want something. But what hasn't come up, is why these use-cases are relevant for browsers. Yes, client facing companies want to give their customers what they ask for. But we need to show that the set of values and goals match what the browser product does. Paul: You mentioned that there are risks and that OUs are dangerous. Can you give an example? Ryan: Unverified information is a risk. Unless the CA is able to prove that the information is verified to a suitable level for our needs, there's inherent risk of displaying in a trusted location the information. Another risk is impact on revocation and replacement. Another risk is dependency on improper certificate usage that prevents ecosystem agility. When there are examples of companies using the OU for authorization or similar, it introduces a risk where the ecosystem can't improve because of the reliance on a field that's not validated to a level expected by browsers. As an example of poor validation practices, if CA X is issuing certificates improperly, and they need to migrate to CA Y, anything that blocks that (due to inconsistent validation or additional validation requirements) is a risk to the ecosystem. These are the most common issues in incident reports and shouldn't come as a surprise as the risks. Dimitris: We always start from the government agency, and that's where we receive the information about the legal rep. It's like getting authorization for EV Issuance in a lot of ways. Ryan: I know that's what Paul meant, but that's not what it says. Paul: If we would go for that process and define it in that way, would it be acceptable? Ryan: The fundamental problem with OUs, you have to describe the use-case and help us (browsers) understand how it addresses the concerns we've raised. Paul: We have shared the use-case, but you don't think it's valid. Ryan: Correct Paul: Communicating that you split your organization up into various units is a valid use-case. Ryan: That explains the disconnect. You have to provide and explain a use-case that's valid for our products and warrants acceptance of the risks I've outlined. Saying customer X wants this thing, that's insufficient. Tim: I think I'll cut this off here. Yes it's true that OUs exist in companies, but the vast majority of actual usage was mostly metadata and other information that arguably violated the current rules. It's important to realize that a lot of the current OU usage was improper anyway, so fixing the rules isn't going to help a ton of people. We've been mostly successful with helping customers migrating away from using OUs. Paul: You say you're successful, but those customers end up coming to us to ask for the certs. The majority of usage is not how they're supposed to be used. But there are usages that match the intent. Tim: You have to look at whether the current values even meet the current requirements, which many don't, which is very disappointing. Paul: I'm trying to implement something on what we expect today. We're trying to improve things without rewriting the BRs. Tim: The current reqs are so bad, so we need something that's clear. Paul: We tried to do this and to get the feedback from the group and get something that's workable. Wildcards in ADNs and HTTP Validation Ryan: The intent is to make progress on this, and it's important to make progress. We've asked for data, which Let's Encrypt has provided, but we need more CAs to do that. We want to make a decision based on data, but we have to make a product decision. We do want to remove Wildcards in HTTP validation. We want to and will consider the data. We monitor what's in CT and we're aware of valid use-cases, but we don't know how common they are, which is what we want to take into consideration. We'd like to make progress in the forum, but we can make progress in our root program. We'd prefer to partner with CAs on this. Paul: Can you share that data with the list. Ryan: I have. Paul: I haven't seen it. Ryan: We do see validating *.corp.com with HTTP. Validation corp.com at that level is a valid use-case. How many of the issued certs would need to use a new method if this change went into effect? If it's 1 customer with 10k certs using the same validations, we want to know those numbers vs 10k customers with 10k validations that would need to change. How many certs are using validation methods that need to change. The more CAs that can help provide data (# certs, # customers, # validations) would be helpful. We're thinking about the impact for when we pick the date. We want to make data driven timeline decisions. Paul: I do agree it's a good change, but don't have much data at this time. We're moving these checks to DNS, this could unintentionally cause more orgs to give more people more access to DNS, which could ultimately weaken security. Ryan: I agree that's a risk. I think there are bounds to the risks we can truly include in scope, but it's definitely a consideration. Understanding the scope of use of HTTP for wildcard validation would help us determine the risk as well, at least comparatively between e.g. a 7% and a 70% impact. We started asking for these data before the winter holidays, so I'm just wanting to emphasize that this is still needed and it's important. Tim: We're running out of time, but don't have next steps. Ryan: Next steps for wildcard/HTTP are for CAs to share data because we do need to make a decision soon. We're not going to continuously postpone as data trickles in. % of wildcard certs, which used X method vs Y method vs Z method, etc. Dimitris: A useful takeaway is there are no objections to moving forward with this change, so drafting the language of the ballot could help. Ryan: I'll send language. We'd like to move with a ballot in the forum, but if no data is provided we'll move forward with a root update. Rich: I don't have data yet. Our concern is not really the timeframe for using the method for future validations; that could almost be tomorrow (for example; it's not a huge challenge to turn it off). We don't allow many customers to reuse domain validations in general, the ones we do allow it for are larger enterprises. It's a matter of subdomain enumeration. Our concern is when we can't reuse currently-valid domain validations based on this method. Ryan: Absolutely, that's the concern we have. The data helps with this. We don't think it needs to happen tomorrow, but probably needs to happen sooner than a year from now, so finding the sweet spot in there is what we're after. Maybe the year IS justified if 98% of the wildcard certs out there are impacted. The data will drive that decision. .onion validation Ryan: There are a cluster of bugs related to this, related to v2 onions. There's a carveout in 3.2.2.4 pointing to the appendix, but in 3.2.2.8 we have a CAA req which will never pass for an .onion, but CAs would need to perform multiple (expectantly failed) lookups for a domain we know won't respond. So there are a few changes needed Dimitris: There's also the internal name issue, where the definition prohibits .onion since it doesn't exist in IANA's DB. Ryan: We carveout in 3.2.2.4 and appendix b that .onion aren't internal names. Dimitris: But then appendix B points you back to 3.2.2.4. Ryan: I hadn't seen that new comment, and might require some unpacking. Dimitris: I can try drafting a ballot and outlining the problems, maybe? Ryan: I was planning a cleanup ballot for some of these EV things, so we can work together on that. Tim: See everyone in two weeks! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3621 bytes Desc: not available URL: