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: