<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=iso-8859-1"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:Aptos;}
@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#467886;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#467886" vlink="#96607D" style='word-wrap:break-word'><div class=WordSection1><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>These are the Final Minutes of the Teleconference described in the subject of this message as prepared by Chris Clements and approved on the 2024-09-19 meeting of the Validation sub-committee.</span><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p style='margin:0in'><b><span style='font-family:"Arial",sans-serif'>Meeting Date: </span></b><span style='font-family:"Arial",sans-serif'>2024-09-05</span><o:p></o:p></p><p style='margin:0in'><o:p> </o:p></p><p style='margin:0in'><b><span style='font-family:"Arial",sans-serif'>Attendees:</span></b><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>Aaron Gable (Let's Encrypt), Aaron Poulsen (Amazon), Ben Wilson (Mozilla), Bruce Morton (Entrust), Chris Clements (Google), Clint Wilson (Apple), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), Doug Beattie (GlobalSign), Dustin Hollenback (Microsoft), Gurleen Grewal (Google), Iņigo Barreira (Sectigo), Johnny Reading (GoDaddy), Joseph Ramm (OATI), Kiran Tummala (Microsoft), Mads Henriksveen (Buypass AS), Mahua Chaudhuri (Microsoft), Martijn Katerbarg (Sectigo), Michelle Coon (OATI), Nargis Mannan (VikingCloud), Nate Smith (GoDaddy), Paul van Brouwershaven (Entrust), Puja Sehgal (Microsoft), Rebecca Kelly (SSL.com), Rollin Yu (TrustAsia), Ryan Dickson (Google), Scott Rea (eMudhra), Stephen Davidson (DigiCert), Steven Deitte (GoDaddy), Sven Rajala (Keyfactor), Thomas Zermeno (SSL.com), Tobias Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Wayne Thayer (Fastly), Wendy Brown (US Federal PKI Management Authority)</span><o:p></o:p></p><p style='margin:0in'><o:p> </o:p></p><p style='margin:0in'><b><span style='font-family:"Arial",sans-serif;color:black'>1. Meeting Open:</span></b><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Corey Bonnell opened the meeting, read the note-well, and completed the roll call. </span><o:p></o:p></p><p style='margin:0in'><o:p> </o:p></p><p style='margin:0in'><b><span style='font-family:"Arial",sans-serif;color:black'>2. Minutes:</span></b><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Minutes from the last meeting (August 22, 2024) were approved.</span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Corey shared the current list of minute takers and asked for any additions or removals. One person was added.</span><o:p></o:p></p><p style='margin:0in'><o:p> </o:p></p><p style='margin:0in'><b><span style='font-family:"Arial",sans-serif;color:black'>3. Next Meeting:</span></b><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- We’ll discuss F2F planning in the next meeting.</span><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p style='margin:0in'><b><span style='font-family:"Arial",sans-serif;color:black'>4. Agenda:</span></b><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Only one topic planned for today, which continues the development of the STRIDE model for method #7.</span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Paul van Brouwershaven sent a message to the Validation distribution before the meeting: </span><a href="https://lists.cabforum.org/pipermail/validation/2024-September/002028.html"><span style='font-family:"Arial",sans-serif'>https://lists.cabforum.org/pipermail/validation/2024-September/002028.html</span></a><span style='font-family:"Arial",sans-serif;color:black'> </span><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p style='margin:0in'><b><span style='font-family:"Arial",sans-serif;color:black'>5. Section 7.1.2.10.5 CA Certificate Certificate Policies for cross signing certificates:</span></b><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Paul introduced the topic where “[...] at least one Reserved Certificate Policy Identifier” is stated in section 7.1.2.10.5 of the TLS BRs and RFC 5280 says “Object Identifier”, possibly implying only one Identifier. Further, under the Policy Restricted table in 7.1.2.10.5 there is language that states: “[...] the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier.” This statement makes sense if referencing an Issuing CA, but in the context of a Cross-Certified CA it is not specified. His interpretation is that you cannot create a Cross-Certified CA that is constrained on TLS DV, OV, and EV policies. Is this interpretation correct and if so, was that the original intention of this language?</span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Martijn Katerbarg previously identified this contradiction and created an issue in GitHub (</span><a href="https://github.com/cabforum/servercert/issues/539"><span style='font-family:"Arial",sans-serif'>https://github.com/cabforum/servercert/issues/539</span></a><span style='font-family:"Arial",sans-serif;color:black'>). He suggested that the language in the table be updated because minimally this is confusing.</span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Paul stated there are a few CAs issuing these certificates. Based on recent discussions nobody can issue Cross-Certified CAs at the moment and those that are already issued may be misissued. Is this an error in the document? It seems like the only approach is to cut multiple Cross-Certified certificates to avoid this problem, but there are people out there that have this problem. </span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'> - Martijn clarified this is only true if the CAs are Non-Affiliated. Affiliated CAs can use the anyPolicy. </span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'> - Paul suggested even if it is an Affiliated CA you may want to use the policy restricted cross-sign. </span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Corey also identified this when writing the profiles cleanup ballot last summer. In his opinion, restricting Cross-Signed certificates or CA certificates in general to just one Reserved Policy Identifier was not intended. He believes this language is a copy/paste error from the Subscriber Certificate section, where it makes more sense. </span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Paul suggested he draft a ballot to correct the language. Does this mean for the time being you cannot issue Cross-Certified CA certificates?</span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'> - Wayne Thayer asked for clarity that you can issue a Cross-Signed CA certificate but it can only include one Reserved Policy Identifier. Paul confirmed this is correct.</span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Clint Wilson agreed with Corey and believes the sentence was supposed to say something like “the Policy Qualifiers field must contain exactly one Reserved Certificate Policy Identifier”, since that is also what RFC 5280 states. It seems as if new Cross-Certified CAs are issued right now with multiple Policy Identifiers then that would be not compliant with the way this is stated, unless you can use the no policy restrictions for Affiliated CAs. It seems like we should pass a ballot to correct this. He suggested reviewing historical conversation to try and determine original intent. The specific sentence of “[...] MUST contain exactly one Reserved Certificate Policy Identifier.” doesn’t seem appropriate in its context.</span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Aaron Gable referenced the PR description (</span><a href="https://github.com/cabforum/servercert/pull/373"><span style='font-family:"Arial",sans-serif'>https://github.com/cabforum/servercert/pull/373</span></a><span style='font-family:"Arial",sans-serif;color:black'>) calling attention to: “For CA Certificates, a new requirement that the Reserved Certificate Policy Identifier be the first policy identifier present. Although this is not required by RFC 5280, multiple applications have implemented logic that extracts the first matching/known policy identifier from a certificate, when computing special policies (e.g. EV treatment). Ensuring the Reserved Policy Identifier is first reduces the risk of improper classification of a certificate. As this only applies to new CA Certificates going forward, it's phased in with immediate effect.” There does appear to be some intent here that there be only one Reserved Policy Identifier and it be the first of the Policy Identifiers in the certificate. He suggested “should only have one Reserved Policy Identifier" because clearly there are existing CA certificates that have DV, OV, and EV Identifiers in them and he doesn't think there is anything particularly wrong about this. He is less convinced the existing language is a typo. </span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'> - Corey believes the summary language was a bit out of date compared to what was actually in SC-62, because originally it was a hard requirement that the first Policy Identifier be a Reserved ID, but that got relaxed to a “should” in the final language. </span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'> - Trevoli Ponds-White suggested Ryan Sleevi previously said Chrome ignores all Object Identifiers after the first one, so if you wanted EV treatment the EV OID had to be first. Ryan Dickson stated that is incorrect. Ben Willson suggested this was actually a Mozilla issue that they resolved and might have been the reason the requirement was relaxed. </span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'> - Clint suggested that it makes sense to issue separate Sub CAs for each type of certificate being issued, at which point this requirement does not prevent the issuance of those Sub CAs, but either way we need to get clarity on the intent and how that's supposed to be handled by CAs. Trev suggested the intention was driven by what Browsers do. Clint confirmed that ordering might have been a driver, but whether or not you could have more than one Reserved Policy Identifier was not. He could see this being useful to have separate certificate types issued per CA. Paul suggested that maybe the intent was directed towards dedicated Issuing CAs. Trev stated the intent of the ballot was to make things more clear and if we introduced something that creates confusion, then we should clean it up. Clint stated the intent was also to ensure that there were clear boundaries for what each type of certificate was and that every certificate type that could be relevant to the TLS BRs was present. </span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Martijn does not see an issue with the language if it relates to normal Subordinate CAs and limiting them to just one Reserved Policy Identifier, but Cross-Signed CAs is an exception case and he suggested copying 7.1.2.10.5 to a new section called Cross-Signed CA Certificate Policies and have slightly relaxed text there. </span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Clint suggested that Subordinate CAs only have one Reserved Policy Identifier. It's not clear as to why a Subordinate CA between the Root and Issuing CA would need to have multiple Reserved Policy Identifiers. Paul reiterated his focus is on the Cross-Signed CA.</span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Ben stated he would support a ballot that treats this language as a mistake and allows a CA certificate to have multiple Reserved Policy Identifiers. Clint clarified that there are reasons why this might not make sense for all CA certificates, but it does for Cross-Signed CAs. Ben suggested otherwise CAs have to create multiple Sub CAs.</span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Doug Beattie highlighted that there is already a section for Cross-Certified Subordinate CA Certificate Profile in 7.1.2.2. Maybe we just add a Certificate Policy subsection there to indicate a special role. </span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Corey stated we already allow anyPolicy for CAs and if we wanted specific Reserved Policy Identifiers per CA we would need a prohibition on anyPolicy, which would be a pretty big change for the ecosystem. </span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Clint stated removing anyPolicy was slated for Profiles v2.0 and retaining it in the profiles was more of a compromise at the time. This does need to be removed if we want to have fully clean profiles.</span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Corey suggested proposing a ballot that only addresses the Cross-Signed CAs case. When we review profiles more holistically we can potentially have a ballot that addresses all Sub CAs. Clint suggested in the meantime, multiple Cross-Signed Sub CAs could be created. One with each policy. The current language does not block this, it's just less convenient. </span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Paul suggested the easiest approach would be to adjust the language in section 7.1.2.10.5, rather than copying and creating a new section. </span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Corey preferred duplicating the content because that is what is done throughout other sections. One thing that comes to mind is basicConstraints for CA certificates. It’s largely duplicative text for the root CA versus every other type of CA certificate, where basically one element is different, but the rest of the text is the same. Clint leans towards copying and pasting.</span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Paul will draft a ballot that adjusts the Cross-Signed CA Profile Policy OIDs and circulate that on the list.</span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Clint referenced a commit (<a href="https://github.com/cabforum/servercert/commit/a0360b61e73476959220dc328e3b68d0224fa0b3">https://github.com/cabforum/servercert/commit/a0360b61e73476959220dc328e3b68d0224fa0b3</a>) calling attention to: “Make PolicyIdentifier ordering optional. This makes the requirement for the Reserved Policy Identifier to be the first policyIdentifier optional, while explaining with a note the basis for that logic. To avoid confusion, it makes it clear that only one instance of a Reserved Policy Identifier may be present (e.g. can't be simultaneously OV and EV)". The intent seems clear for the general case of CA certificates. Generating multiple Cross-Signed CA certificates also seems appropriate. </span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Martijn thought multiple Sub CA cross signings is prevented by the subject naming which has to be byte-for-byte identical both in Issuing CA and Subject CA. It depends on interpretation. Paul suggested it would mean you could have multiple signing certificates with the same key and the same subject but only different policies, which would be really hard to identify. Corey’s recollection of SC-62 was that Microsoft Windows had some type of Sub CA cacher and it used the key ID as the identifier for that cache. If you have multiple Cross-Signed CAs floating around, same subject DN, same key identifier, and differentiated solely on policy, whether or not that would confuse the cache. It seems like this could introduce potential complications and operational issues for some environments. </span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'> - Clint stated there are a lot of CAs with the same key and name with minor differences. There is one pattern where a large number of CAs are duplicated with only the AIA being different between the two CAs. We have not seen any issues with those. If CAs have seen any issues, that would be interesting to know. </span><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- Corey summarized that the next step is a ballot to allow multiple Reserved Policy Identifiers for Cross-Signed CAs and we’ll look holistically at all Sub CAs at a later time. </span><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p style='margin:0in'><b><span style='font-family:"Arial",sans-serif;color:black'>6. Any Other Business:</span></b><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif'>- None.</span><o:p></o:p></p><p style='margin:0in'><o:p> </o:p></p><p style='margin:0in'><b><span style='font-family:"Arial",sans-serif;color:black'>6. Next call:</span></b><o:p></o:p></p><p style='margin:0in'><span style='font-family:"Arial",sans-serif;color:black'>- September 19, 2024</span><o:p></o:p></p><p style='margin:0in'><o:p> </o:p></p><p style='margin:0in'><b><span style='font-family:"Arial",sans-serif;color:black'>7. Adjourn</span></b><o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt'><o:p> </o:p></span></p></div></body></html>