<div dir="ltr">Validation Sub-committee draft minutes for 2021-03-11<div><br></div><div>## Attendees<br><br>  * Douglas Beattie<br>  * Corey Bonell<br>  * Niko Carpenter<br>  * Michelle Coon<br>  * Janet Hines<br>  * Andrea Holland<br>  * Tim Hollebeek<br>  * Daniela Hood<br>  * Rebecca Kelley<br>  * Bruce Morton<br>  * Trevoli Ponds-White<br>  * Ryan Sleevi<br>  * Curt Spann<br>  * Wayne Thayer<br>  * Paul van Brouwershaven<br>  * Ben Wilson<br>  * Clint Wilson<br>  * Dimitris Zacharopoulos<br><br>## Agenda<br><br>* Profiles<br>  * Naming<br>  * Key Usage<br>  * Subordinate CAs<br>  * End-Entity Certs<br>  * Country validation<br>  * Formatting<br>  * Multiple attributes within names<br>* 398-day proposal<br><br>## Profiles<br><br>Ryan began with presenting his current work in progress converting the profiles work into Markdown and the BRs, as well as sharing some of the challenges or open-questions.<br><br>### Naming<br><br>The first was the area of naming, in terms of what attributes can be included in certificates, what their permitted values are, and how those requirements should be expressed. The BRs today currently have a variety of permutations that can vary. For example, Root CAs and Subordinate CAs aren't permitted to use "XX" for country, where Subscriber certificates can. Another oddity is that for Root and Subordinates refer to Section 3.2.2.3 for countryName validation, but 3.2.2.3 is an extension of 3.2.2.1 that permits using the country associated with the domain or IP, which CAs don't necessarily have.<br><br>Another situation was today the BRs only require certain fields for Root/Subordinate CAs, but permit other fields. Names are hierarchical, and so wanted to try to express requirements in terms of the order of how those names are expressed. Tim pointed out that the order of postalCode is probably sorted incorrectly, as it's a larger area than the streetAddress field.<br><br>Ryan then showed how the requirements for fields and their encoding are expressed, which is in a separate section, and tried to incorporate feedback from previous calls in capturing requirements like field lengths and where the relevant definition of the field is (e.g. X.520 vs RFC 5280)<br><br>He described introducing a requirement for how names are encoded, to ensure only one attribute is encoded in each RelativeDistinguishedName.<br><br>### Key Usage<br><br>The next area Ryan discussed was how we handle options and permutations. He showed the example of Key Usage, which has two variations for a Root CA, depending on whether or not the Root CA issues OCSP responses. The general problem is trying to figure out which options make sense as a distinct certificate profile, and which may make sense as just an option within a section. Ryan opted for an approach for Root CAs to keep it just in key usage, but could also be convinced to split into separate profiles.<br><br>Tim pointed to the current draft text, highlighting that the requirement, based on what the CA will or won't do in the future, is tricky. Ryan was mixed: at time of creation, the issuing CA is making a declaration about what they will or won't do, so there's some requirement there. He highlighted another example with Sub CAs, in terms of whether or not they will issue TLS certificates, so that's where the language was borrowed.<br><br>Tim suggested an alternative approach, which would be "If the digitalSignature bit is set, the CA will issue OCSP responses. If the digitalSignature bit is not yet, the CA SHALL NOT issue OCSP responses." Dimitris was not sure about this proposal, highlighting that the CA may set the digitalSignature bit, but then decide not to issue OCSP responses, and that should be fine. Tim modified the "will" to "MAY" to address this. Trevoli was concerned the current approach makes the section seem more like a recommendation: "Don't include this if you don't want to use OCSP".<br><br>Ryan agreed with these concerns, and this language wasn't final. The example of OCSP issuance based on the digitalSignature bit may fit better in the OCSP Profile section, which wasn't something we'd planned to start yet.<br><br>Quite a bit of this was just trying to get feedback on the approach. For example, an alternative would have been displaying key usages in a table, rather than a bulleted list. If we do that, do we list every key usage and say "Don't include", or do we just list what's permitted? Curt said he had a light preference for tables, even though that can be tricky to format nicely, so could live with the bulleted list. Ryan said he'd convert to a table to get folks' feedback on the approach.<br><br>Curt asked for further clarifications on what approach Ryan was suggesting. Ryan said there were several ways we could structure this section. The least ambiguous, most programatic way would be to express the extension as an exact byte sequence, since there are only two permissible encodings. This is what we did for SPKI, but is probably the least accessible to read. Another approach is the approach he currently took, which was displaying requirements as a bulleted list of what MUST be set, with everything MUST NOT be set. Another alternative would be a table, but with just a single column, of what key usage bits MUST be set, with a requirement to MUST NOT anything not mentioned. The last alternative is a two-column table that lists each keyUsage bit, along with a second column that indicates whether or not it's permitted.<br><br>Curt suggested the last option was perhaps most clear, and so preferred that. Ryan indicated these were just placeholder ideas, and would update this section.<br><br>### Subordinate CAs<br><br>Another area that Ryan had been struggling with is how many permutations of sub-CAs we have. One dimension is whether or not the sub-CA is an Affiliate of the issuing CA or not, since this can affect extensions like certificatePolicies and extendedKeyUsage. Another dimension is whether or not this is a cross-cert of an existing root or not, since this also affects EKU, but also affects subject naming, which is something Doug Beattie had raised in the past. That is, if you have a root that complied with the BRs when it was issued, can a CA cross-certify that if the name no longer complies with the sub-CA naming rules? These seem important issues to sort out now, especially as we talk about profile changes, even something like organizationUnit.<br><br>Ryan described the scenarios he'd identified:<br><br>  - Cross-Certified CA<br>    - Same Organization/Affiliate<br>    - Different Organization<br>  - Technically Constrained Sub-CA<br>  - TLS Sub-CA (which can vary based on Affiliate status)<br>  - Non-TLS Sub-CA (which can vary based on Affiliate status)<br>  <br>An example of complexity is a field like nameConstraints, which may be REQUIRED for some profiles, or MAY for other profiles, and how the content is validated should be the same across these profiles. Ryan's continuing to try to explore different approaches for how to best capture this information.<br><br>Dimitris mentioned this was something he's been interested in since he joined the Forum, and is interested in working through the permutations. He was familiar with certificatePolicies, but wasn't familiar with the EKU changes. Ryan mentioned that it's a special case where it's both a cross-certificate and affiliated, which would allow anyEKU, which might otherwise be restricted.<br><br>Dimitris asked whether it would make sense to have a separate section for cross-certificates by separating from sub-CAs. Ryan mentioned it's not just cross-certificates, but he is exploring making it clear that cross-certificates are a type of sub-CA. He was nervous about suggesting cross-certificates were different from roots or sub-CAs, especially because the requirements we have in other sections are all based on Root CA or subordinate CA. There was some discussion with Doug Beattie on the list a year or two ago about this problem, and Ryan is attempting to try to explore options for clarifying that. Doug agreed that different types of subclasses make sense, since it helps keep our other sections, like audits, simple.<br><br>Bruce asked about the proposed language for cross-certificates, and whether the idea is that the name of the cross-certificate needs to be identical to the root certificate, rather than having rules on the name for that specific class. Ryan said that he was trying to work through this: you want to make sure the name is identical, but you want to make sure someone can't just create a self-signed root and use that to get around sub-CA naming requirements. So the idea is that if you have a root that was compliant with the BRs or a previous version of the BRs, it'd be fine, but wanting to make sure the name was created subject to the BRs at some point. Ryan said this would be easier if we'd resolved the audit lifecycle issues we'd talked about previously, but since we haven't done yet, he's still working through how to solve this.<br><br>Curt mentioned that an approach to handling these classes might be to have one table that is common to all the requirements for such sub-CAs, and then have additional tables that introduce specific requirements for each type that are above-and-beyond. He wasn't sure if that made more sense than fully enumerating all of the requirements for each type, since that could end up repetitive. Ryan agreed that this is the problem he's been struggling with, and is exploring options.<br><br>One option he was exploring was having full tables for each profile, but have the requirements column refer to a common section for where the requirements are shared between multiple profiles. Another option was similar to what Curt was suggesting, which would be multiple tables within a section covering each permutation, with a table label, and each table only has 2-3 rows for what's different.<br><br>### End-Entity<br><br>Ryan hasn't yet finished end-entity certificates yet, and so doesn't have a demo to show. However, the problems are similar to what we just discussed for sub-CAs. We have variations between DV, IV, OV, and EV. DV varies on how the country is validated, both from CAs, and because it allows Section 3.2.2.3. IV allows additional attributes, but some of them don't make sense. For example, streetAddress is required to be validated against Section 3.2.2.1, which is for organizations, rather than 3.2.3, which is for individuals. While you probably don't want to include a streetAddress for an IV cert, we should fix up the validation requirement, which is right now inconsistent with the Certificate Policies section that said validated against 3.2.3.<br><br>Similar to sub-CAs, he's exploring how to express these requirements in a way that makes sense.<br><br>### Country validation<br><br>The last situation was where the country name doesn't have an ISO 3166-2 country code assigned, and so we use XX. He had examined CT, and saw it was only Sectigo and DigiCert that had issued such certificates. With our current requirements in 7.1.4.2.2, we have a number of permutations, in which the countryName contains XX, but then the stateOrProvince may be absent, may contain the state or province, or may contain the country. Locality is the same, and this results in 8 different permutations for the contents of the field here.<br><br>The discussions seemed to reach consensus that stateOrProvince should be state or province and locality should be locality. Whether we introduce a new attribute, and whether that attribute is optional or required, has different tradeoffs, and probably needs further discussion. But this would be a change to try to simplify the requirements between all these permutations by having consistent field contents. At most, the permutation would be the naming for XX names and the naming for non-XX names.<br><br>### Formatting<br><br>Trevoli pointed out that, on the topic of readability, have we given any thought to changing the font? Ryan said yes, that's totally something we can do, and wouldn't necessarily require a ballot. A big part of the infrastructure work was, in fact, in getting fonts working, since the EV Guidelines have some CJK fonts and getting everything working was a pain. However, we can change the fonts to whatever we want. Ryan just used the fonts from our existing word template at the time. The only real requirement is for freely distributable fonts.<br><br>Trevoli suggested she could join the infrastructure group to discuss further, but was keen to find a font that was readable. Ryan mentioned he used Google Fonts for these, but any foundry or freely distributable font should work.<br><br>### Multiple values within names<br><br>Ryan said the current draft language attempts to restrict there to being one instance of a given attribute within a subject name. For example, a certificate with multiple country names doesn't make sense. However, there was one exception, with streetAddress, which has a 128 character limit. If CAs are including the streetAddress, and the address is longer than 128 characters, should they be able to include multiple streetAddresses?<br><br>Ryan said it's no secret that Google would like to see identity information moved out of TLS certificates, into a separate set of certificates. However, since that's not yet required, he wanted to provide guidance for CAs on what to do in the interim. He wanted to get feedback from folks on whether or not folks agreed that streetAddress was the only field that made sense.<br><br>Tim said he recalls it being discussed internally at DigiCert, but doesn't recall beyond that, and would need to look for further details. Ryan mentioned Sectigo recently announced they were removing streetAddress, in part to resolve ambiguities like this, which is good. Ryan continues to look through for these sorts of exceptional situations to try and flag for discussion, as well as see if folks had strong feedback.<br><br>Dimitris said he thinks folks probably have strong feelings on what fields should only have one instance. But perhaps for fields not listed, it can be left only as a SHOULD. Ryan was concerned with this, because he wasn't sure if the current BRs language could be read as being permissive, and there's also a host of challenges in properly encoding multiple fields, so he was keen to be more explicit for when multiple fields are allowed.<br><br>Tim said if CAs looked through their systems, they'd probably find they don't actually support multiple fields, except for perhaps streetAddress. Ryan shared some of the existing proposed language, which includes a carve-out to explicitly permit multiple fields when we want to be explicit about it. It might be OK to allow for custom attributes, such as a customer-specific OID, for as long as we allow customer-specific OIDs. However, including multiple attributes within one SET is silliness he wants to prohibit.<br><br>### Closing<br><br>Ryan indicates he continues to work through these edge cases, and reaching out to CAs that might be affected by different situations. He's not trying to cut folks out of discussion, but trying to make sure to minimize impact in the proposals, before we get to the broader discussion. He hopes to have a version before the next call, so that it can be more closely reviewed.<br><br>## 398-day domain validation requirement<br><br>Daniela had a question about the draft ballot Ben Wilson had circulated regarding changing the domain validation requirement. It sounded that during the F2F discussion, but perhaps this was a misunderstanding, there had been a proposal from Dimitris to change section 4.2.1 to change everything to 398 days, including data reuse.<br><br>Ben and Dimitris clarified this was just for domain and IP address, while leaving the other information at 825 days.<br></div></div>