<div dir="ltr">Wayne Thayer read the antitrust statement.<br><br>Attendance: Amanda Mendieta, Andrea Holland, Aneta Wojtczak, Ben Wilson, Bruce Morton, Corey Bonnell, Doug Beattie, Clint Wilson, Janet Hines, Joanna Fox, Johnny Reading, Kati Davids, Michelle Coon, Mike Min, Nico Carpenter, Natalia Kotilarsky, Rebecca Kelley, Ryan Sleevi, Shelley Brewer, Steven Deitte, Tobias Josefowitz, Trevoli Ponds-White, Wayne Thayer<br><br>** Minute Takers: **<br>Wayne said that he is up this week, and Ryan Sleevi is next up.<br><br>** Agenda: **<br>Wayne said that the only existing agenda topic is certificate profiles.<br><br>Wayne suggested that the email to the Mozilla dev-security-policy list titled “DNS authorization delegation through non-ADN delegated records” was worthy of some discussion.<br><br>** Certificate Profiles **<br>Ryan began by reviewing the list of commits to the profiles from August 20th at <a href="https://github.com/sleevi/cabforum-docs/commits/profiles">https://github.com/sleevi/cabforum-docs/commits/profiles</a>, including:<br><br>* Corey Bonnell called out the technically constrained non-TLS subCA profile and the practice by NetLock and SecureTrust of using precertificate signing subCAs. Another profile will be added to cover this specific EKU.<br>* Corey submitted a PR to reorder the street address and postal code fields in the profiles to reflect the proper hierarchical order.<br>* Name constraints are a MAY for TLS subCAs.<br>* cRLDP MUST NOT for for OCSP responder certificates.<br><br><br>Work in progress changes are at <a href="https://github.com/sleevi/cabforum-docs/pull/36#issuecomment-902878975">https://github.com/sleevi/cabforum-docs/pull/36#issuecomment-902878975</a>, including:<br><br>* Validity periods for all profiles as discussed in prior calls. Make it clear that test certificates can be issued with an expired validity period.<br><div>* Doug Beattie asked about “any other value” - including other extensions or values than what is listed. Arbitrary extensions will be permitted, Ryan will clearly denote places where an arbitrary value is allowed, and conditions for doing so.</div><div>* Corey raised a point about additional extensions that can be included, such as signed exchange and delegated credentials. They have additional restrictions in other fields such as key usages, so these probably make sense as additional subscriber certificate profiles. </div>* Ryan will try to clarify the language around precertificates being the presumption that a corresponding certificate exists.<br>* Corey mentioned the CABF identifier for EV, TLS Features, and QCStatements extensions.  QCStatements is messier. Ryan plans to leave it as SHOULD NOT. It’s not a goal to try to fold all the ETSI requirements into these profiles. This will not prohibit the issuance of qualified certificates. There is also the onion v2 certificate extension. v2 has been sunset as of July 15 and is being removed from Tor later this year, so the v2 rules can be cleaned up.<br>* SRVNames and nameConstraints language is buggy<br><br>Corey said that he will respond to Ryan’s comments soon.<br><br>Ryan said that there is some ongoing discussion around Subject Key Identifier (SKI) and Authority Key Identifier (AKI) and how Windows 10 and macOS verify certificates. Windows prioritizes AKI/SKI in path building, and Windows 10 introduces logic that causes certificate validation to fail after some number of failed signature validations. The requirement resulting from this behavior is that unique public keys should have distinct SKIs. macOS enforces that SKI and AKI must match, despite RFC 5280 discouraging this. So you can use multiple SKIs  for a single public key, but you probably shouldn’t.<br><br>Another area of ongoing discussion is that the cross-certificate profile should not be used for root certificates (subject matches issuer).<br><br>Also discussing cross certifying certificates when the root doesn’t comply with the current requirements. The Intention is to allow this.<br><br>Finally, discussion is ongoing to allow domain name in organization fields when appropriate, e.g. SSL.com.<br><br>Wayne asked everyone to review the profiles and comment on GitHub.<br><br>**DNS authorization delegation through non-ADN delegated records **<br>Wayne said that the email from Matthias (<a href="https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mMyBFRyQdw4/m/IMtOrMNOAQAJ">https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/mMyBFRyQdw4/m/IMtOrMNOAQAJ</a>) was originally asking if it was permissible to follow CNAMEs under method 7, and this is know to be permitted. Ryan responded stating that it is not permitted to delegate the CNAME to the CA. Wayne said that this might be an area for the subcommittee to clarify.<br><br>Corey said that the conclusions are not readily apparent from a reading of the BRs.<br><br>Ryan said that there was discussion around Subscriber/Applicant relationship to the CA on a CAB Forum list around 2 years ago. The Applicant has to provide the random value. Discussion was with Jeremy at DigiCert and in part about account security controls.<br><br>Corey said the discussion was on the mozilla.dev.security.policy.list.<br><br>Ryan said that the issue goes back to the Validation Summit in Virginia.<br><br>Corey said there was some conversation in 2018 and the conclusion seemed to indicate that consensus was the delegation would be permitted.<br><br>Doug posted the following link into the chat: <a href="https://groups.google.com/g/mozilla.dev.security.policy/c/lT0Dd9XkPwI/m/TRFhrX52AAAJ">https://groups.google.com/g/mozilla.dev.security.policy/c/lT0Dd9XkPwI/m/TRFhrX52AAAJ</a><br><br>Doug said that it was unclear that a conclusion had been reached, but there needed to be some security tying the random value to the Applicant.<br><br>Ryan said there was another thread with Jeremy Rowley going back to 2016.<br><br>Corey said that the thread Doug posted is the one he was referring to.<br><br>Wayne asked if this was something we should take up in the Validation Subcommittee. Corey said yes, to ensure that if it is being done, it is being done securely. Clint and Trev also agreed.<br><br>Wayne said that he’d add this work to the Trello board.<br><br>The call ended.<br></div>