<div dir="ltr"># Attendees<br>Andrea Holland, Aneta Wojtczak, Ben Wilson, Bruce Morton, Christy Berghoff, Clint Wilson, Corey Bonnell, Daniela Hood, Doug Beattie, Dimitris Zacharopolous, Dean Coclin, Janet Hines, Johnny Reading, Michelle Coon, Niko Carpenter, Paul van Brouwershaven, Rebecca Kelley, Rich Smith, Ryan Sleevi, Shelly Brewer, Stephen Davidson, Thomas Zermeno, Tim Hollebeek, Trevoli Ponds-White, Wayne Thayer<br><br># Antitrust Statement<br>The Antitrust Statement was read by Tim.<br><br># Agenda<br>  * Redirect improvements<br>  * OU Proposal<br>  * Format of Certificate Profiles<br>    <br>## Redirect Improvements<br>Niko described how the BRs refer to RFC 7231 for status codes for redirects, but this overlooks 308, which is RFC 7238, which also seems like it should be acceptable. Based on discussion on the list in the past, it seemed like an approach of enumerating the desired redirects was the right approach. Niko's proposal based on that narrowed down to 301, 302, 307, and 308 for 3.2.2.4.18 and 3.2.2.4.19 in domain validation.<br><br>Ryan indicated he hadn't read Niko's latest mail on the language, but suspects that Google would be able to support in principle, since those four codes do sound correct. Niko mentioned there hadn't been many comments on the mail regarding the language.<br><br>Tim suspected there might be more comments on the language, but the best path forward is to start working on a ballot, as folks may not read until it's in voting.<br><br>## OU Proposal<br>Paul shared a risk register on the list, and had received feedback from Ryan. He indicated he's looking for more feedback, and still continuing to explore the contents of the draft.<br><br>## Format of Certificate Profiles<br>Stephen Davidson was invited to the call, given the potential overlap of use case for the S/MIME Work Group. This topic was discussed at the F2F, and the high level strategy sounds like there will be one table for each of the different certificate types, so they can have their own independent list of allowed/disallowed fields, just like there is presently in the spreadsheet that was started.<br><br>When it comes to some of the complicated fields, like Subject DN, have break out into sub-tables that capture the allowed forms, to avoid needing to have a bunch of conditionality within the table or in the requirements.<br><br>Stephen indicated he was interested in understanding how the table approach would work for different variants of certificate types. For example, in the S/MIME case, you can have different groups of key usages involved. Tim mentioned it doesn't show up as much in the TLS world, but if there were multiple use cases and different profiles, split out the tables by use case (e.g. by EKU) to address the different requirements, to keep it simple.<br><br>Corey suggested that some of the common fields in the subject DN might be in the same table, such as countryName or locality, but that those RDNs that change based on policy, such as organization name, might be in different tables depending on the type. For example, if it's IV, put this value in the O field, if it's OV, put this other value of the O field.<br><br>Ryan said the suggestion was that instead of having clusters of common fields, that we'd group a table for the whole DN. For example, this is what a DN looks like for an IV, this is what a DN looks like for an OV without a recognized country (the 'XX' problem), this is what a DN looks like for OV with a recognized country. Something somewhat similar to how we've done in the sheet, with columns for the field, the attribute, and then a reference to the section describing the validation for the attribute. The references for a number of attributes will be similar, but for some situations (e.g. IV w/o using givenName), fields might refer to a more specific section. The idea being that we have a set of clear tables, and all DNs must be able to be matched against exactly one of those tables, to avoid having to have folks pick and choose "some from this table, a little from that table". <br><br>Corey was concerned about the possible duplication, if we changed the validation rules for a field, we'd need to make sure to update all the references, and it would introduce the potential to miss updating a field. But he also acknowledged this may not change often and may not be in practice.<br><br>Tim mentioned he's not normally a fan of duplication, but having the information duplicated in this case makes sense, because it makes the profiles flat, simple, and non-conditional. He suggested we might want a worksheet to help remind folks to update relevant sections, particularly if other WG copy the approach, but the benefits of the flat approach seem worth it.<br><br>Dimitris raised a question about how we explore other attributes. Some certificate profiles allow additional, arbitrary RDN attributes, and how would that be represented? Ryan explained that just like we did with 3.2.2.4, we would add a row at the bottom of the tables that allowed arbitrary attributes, and then a reference to the section describing the (generic) validation requirements for these fields. If we then take an approach like 3.2.2.4 of removing "any other method", we can add new rows for the relevant certificate types detailing the additional DN fields that are allowed and sections for how to validate them.<br><br>Tim asked what the next steps were? There was agreement that we just needed to go heads down and make a draft to get discussion.<br><br>Ryan raised a matter of keyUsage tied to the subjectPublicKeyInfo, and suggested that we might need to have a few small clusters, like we suggest for distinguishedName/certificatePolicy, where we indicate in the profile which fields are required, but leave their value to breakout tables (e.g. RSA vs ECDSA). Tim agreed that sounded reasonable, and would be great if folks could put together a strawman before the next call.<br><br>Corey asked which profile we should begin with. The validation WG originally began with a root certificate, would we start there? Tim suggested we might want to begin with the complicated case first to make sure it works out. Ryan agreed that it makes sense to start with the end-entity certificates, since we have many variants. Subordinates have some interesting interactions with cross-signed certificates, so there are some edges. Root Certificates should be the easiest, and should probably last.<br><br>Wayne asked if we had a plan for making sure that this approach would work in Markdown and how our documents are produced. Ryan mentioned that he hadn't started this yet, as he's been focused on the GitHub migration. Ryan has been working with Jos to enable some automation and cleanup of our templates, mentioned at the F2F, so that we can have an easy edit/preview cycle, including in members' forks. Tim asked what the timeline, and Ryan mentioned that having the automation was the goal before the next call. At the F2F, he mentioned there's one security issue he wants to make sure is good. He also wanted to try to make this generic, for other WGs to be able to use, but the focus first would be on the servercert repository. Tim agreed this would be very useful, and suggested we begin this work in Markdown to make sure it works.<br><br>Wayne pointed out that there's a few WYSIWYG Markdown table editors, and wasn't sure if that made sense to use. Tim agreed that'd be useful, to avoid editing Markdown on the calls themselves. Wayne didn't have a specific recommendation for a tool, but there was agreement this would be useful.<br></div>