<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=us-ascii"><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:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@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:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
p.gmail-msolistparagraph, li.gmail-msolistparagraph, div.gmail-msolistparagraph
{mso-style-name:gmail-msolistparagraph;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@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="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal style='line-height:105%'>Thanks Doug for taking these!<o:p></o:p></p><p class=MsoNormal style='line-height:105%'><b><o:p> </o:p></b></p><p class=MsoNormal style='line-height:105%'><b>Meeting of December 15, 2022</b><o:p></o:p></p><p class=MsoNormal style='line-height:105%'><b>Antitrust Statement:</b> Corey Bonnell read the Antitrust Statement<o:p></o:p></p><p class=MsoNormal style='line-height:105%'><b>Attendance:</b> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Aaron Poulsen - (Amazon), Andrea Holland - (SecureTrust), Aneta Wojtczak-Iwanicka - (Microsoft), Ben Wilson - (Mozilla), Bruce Morton - (Entrust), Clint Wilson - (Apple), Corey Bonnell - (DigiCert), Dimitris Zacharopoulos - (HARICA), Doug Beattie - (GlobalSign), Dustin Hollenback - (Microsoft), Enrico Entschew - (D-TRUST), Eva Vansteenberge - (GlobalSign), Inigo Barreira - (Sectigo), Jamie Mackey - (US Federal PKI Management Authority), Joanna Fox - (TrustCor Systems), Johnny Reading - (GoDaddy), Martijn Katerbarg - (Sectigo), Michelle Coon - (OATI), Nargis Mannan - (SecureTrust), Pekka Lahtiharju - (Telia Company), Rebecca Kelley - (Apple), Rollin Yu - (TrustAsia Technologies, Inc.), Ryan Dickson - (Google), Thomas Zermeno - (SSL.com), Tim Hollebeek - (DigiCert), Tobias Josefowitz - (Opera Software AS), Trevoli Ponds-White - (Amazon), Tyler Myers - (GoDaddy), Wayne Thayer - (Fastly)<o:p></o:p></p><p class=MsoNormal style='line-height:105%'><b>Minutes: </b>Minutes of previous meetings Nov. 17<sup>th</sup> and December 1st were both approved.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'><o:p> </o:p></p><p class=MsoNormal style='line-height:105%'><b>Agenda Topics<o:p></o:p></b></p><p class=MsoNormal style='line-height:105%'><b>1) Certificate Profiles<o:p></o:p></b></p><p class=MsoNormal style='line-height:105%'>Corey sent a new PR that includes SC 56 and SC 58. Please review and send feedback as you have time<o:p></o:p></p><p class=MsoNormal style='line-height:105%'><o:p> </o:p></p><p class=MsoNormal style='line-height:105%'><b>2) Profile ballot: </b>Subject Key Identifiers<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Cory said we’re looking for feedback from the root programs on the use of SKI in TLS certificates<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Ryan wants this to remain not recommended. We can see a reduction in TLS handshake bandwidth by 3% which is significant. Since SKI can be calculated via any method, it’s not a useful way to do public key lookups. But we could rely on SHA-256 hash of the subject public key info since that is standard. Not recommended is not a probation, even if some auditors take the other view. SKI is enabled by default in many CA products, but that does not mean we should not remove it.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Clint agrees with Ryan and the current draft as it stands.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Dimitris says that according to new revocation policy Mozilla, if a CA receives a key compromise with POP of private key, then the CA is forced to revoke all certs with that key. The “best” way is via SHA256 hash of SPKI of the key info (vs. SKI).<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Ryan agrees, the best way is via hash of subject public key info globally.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Dimitris said that CAs can use SKI internally since they know how it was created, so that is not an issue if CAs want to do that.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Tim said that in the longer term CAs should rely on a cert database vs. content of the certificate where you can have these additional “search” fields.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Ben supports the current ballot and said we should work to notify CAs that this is no longer suggested and may eventually want to prohibit the use of SKI.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Ryan said that both TLS and CA certificates should not include SKI.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Ben said that he’d prefer to keep SKI in the CA certificates<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Cory: Summary: Keep current language.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'><o:p> </o:p></p><p class=MsoNormal style='line-height:105%'><b>3) Profile ballot: </b>CPS Qualifiers<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>The current ballot said CPS URI Qualifiers is Not recommended<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>URI in ICA – OK with Ben, but does not see value in this in the TLS certificates<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Ryan said that very few people even open up cert details and nevertheless a URI for a CPS URI, what’s the value of including this in CA or TLS certificates. <o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Wayne thinks that most CA certificates carry a CPS UIR and as such, including in the TLS certificate is of little value (both TLS and CA certificates are provided in the handshake).<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Trev is a fan of removing this because she’s a fan of making things smaller. Whenever someone wants to find this, they generally go to the repository for the CA vs. looking in the certificates.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Clint said we should move away from this, so agrees with the current ballot.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>The current ballot says “not recommended” for CA certificates.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Cory: Paul was going to put together a PR for this with the position on this, so let’s proceed with the current language unless someone has further input.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'><o:p> </o:p></p><p class=MsoNormal style='line-height:105%'><b>4) Profile ballot: </b>Order of Subject DN attributes<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Doug asked the question on the mailing list about where the ordering requirement came from.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Tim said it comes from RFC 5280. Imposes partial ordering on subject info for location settings, but is OK with relaxing 5280 rules. As far as if this is important or not, the answer is generally “no”. Mostly imposes order on geographic fields to have them in a coherent order. For other fields it’s rather complicated to see there is an order specified. One the point of this ballot is to more clearly specify the requirements for order so we can all comply, but is also open to relaxing the 5280 rule.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Clint said that there were some reasons for ordering from prior discussions here: <a href="https://avanan.url-protection.com/v1/url?o=https%3A//github.com/sleevi/cabforum-docs/pull/36/files%23r872103477&g=ZDY2MDdhM2NmM2UyYWEzOQ==&h=ODI0ZWU3MWE5ZGY2NjhkYTc1NDZjZjU1YjliMDY0NGRhYjA2MGJmMDVlY2M5MjliM2ZiZjEwOTliY2ZiMzk5Zg==&p=YXAzOmRpZ2ljZXJ0OmE6bzpmZmNjOTUwNjNlZjIwOTAyNGM4NmQxMTg1MDFiZDcwNDp2MTpoOkY=" title="Protected by Avanan: https://github.com/sleevi/cabforum-docs/pull/36/files#r872103477">https://github.com/sleevi/cabforum-docs/pull/36/files#r872103477</a>. There is some value in specifying this more clearly. There is some flexibility we could put in, but it seems reasonable to set ordering so it can be consistent and relied upon.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Dimitris was OK with the ordering of the location fields, but what about custom OIDs (JOI OIDs for example)? Impose order on those that make sense, not for others. This may be problematic for CAs to implement.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Martijn said that the current proposal is that some fields need to be ordered and others do not. There are 2 tables in the ballot<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Tim: This only addresses order of some fields and not all, so not a huge fan of this since this ballot is only partially ordering the fields.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Corey pointed out that there are 2 tables of attributes in the profile ballot, the first one (location related) specifies the encoding and order and the other one does not specify any ordering requirements.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Wayne: Is there an implementation date for this specificity requirement?<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Yes, the global transition timeline is defined for all changes, so this is the same as all changes.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Clint: This portion of the ballot has been stable for a year, so hopefully people have had time to review and understand this requirement <o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Tim: Most CAs and certificate consumers don’t historically read ballots till they are up for discussions, unfortunately.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Clint: This is why we want to get this out as a draft ballot soon and into a formal discussion period<o:p></o:p></p><p class=MsoNormal style='line-height:105%'>Tim: This is why we should change discussion period to be longer (90 days perhaps) and this would help get the last set of good reviews by all.<o:p></o:p></p><p class=MsoNormal style='line-height:105%'><o:p> </o:p></p><p class=MsoNormal style='line-height:105%'><b>4) LEIs<o:p></o:p></b></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'>Eva said that LEIs area supported registry scheme by the ETSI but not by the EVGL. Can we add LEIs as a registration scheme to EVGL?<o:p></o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'><o:p> </o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'>Dimitris: Discussed a few meetings ago. S/MIME BR language can be used for EVGL and even the BRs.<o:p></o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'><o:p> </o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'>Tim: Same text “about” the same as a prior ballot.<o:p></o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'><o:p> </o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'>Tim suggested using the S/MIME version. What about certificate consumers, do they have any input?<o:p></o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'><o:p> </o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'>Ryan said that he has no blocking concerns but remains weary of including fields that result in mis issuances like misspelling names of locations. If this is important for customers, it’s not something he will stand in the way of.<o:p></o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'><o:p> </o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'>Tim: Hopefully this will improve that. This is a globally unique value which should disambiguate identities. LEIs is a path forward to getting rid of other unique identifiers.<o:p></o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'><o:p> </o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'>Clint, as a certificate consumer thanks the group for highlighting this early. Not supporting or pushing for this but not resistant to this either. Wants to see how this goes for S/MIME, but if CAs want to roll this out in EV TLS certs, that is acceptable. LEIs could play a role in fixing how we identity unique organizations globally.<o:p></o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'><o:p> </o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'>Tim: Also removes divergence between SMIME and TLS groups and also European requirements vs. BRs. So solves a few problems.<o:p></o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'><o:p> </o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'>Ryan: Once this is permitted in EVGL, is there a path that would limit or remove other JOI fields?<o:p></o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'><o:p> </o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'>Tim – yes, we can have those discussions.<o:p></o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'><o:p> </o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'>Tim said that 3-4 years ago did a draft ballot, but we should use a new ballot based on the S/MIME ballot.<o:p></o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'><o:p> </o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'>Doug asked if this should be limited to EVGL or if we should include in the BRs also.<o:p></o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'><o:p> </o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'>Eva: In theory you can include in OV, optimally in OV if you have the “info”. Is there an appetite to solve this?<o:p></o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'><o:p> </o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'>Dimitris said yes. If a CA wants to follow EV rules and issue an OV cert for some reason, then that would be acceptable.<o:p></o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'><o:p> </o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'>Consensus: is it to include other schemes as well, or just LEI?<o:p></o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'><o:p> </o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'>Dimitris – we can allow org identifier in OV (optionally). It’s not prohibited today, but it is more responsible to include rules for including that.<o:p></o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'><o:p> </o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'>Eva – let’s try that then. Dimitris and Eva to work on that.<o:p></o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'><o:p> </o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'>Final conclusion: Corey said we’ll have a concrete proposal to review soon<o:p></o:p></p><p class=gmail-msolistparagraph style='margin:0in;line-height:105%'><o:p> </o:p></p><p class=gmail-msolistparagraph style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:8.0pt;margin-left:0in;line-height:105%'><b>5) </b><b><span style='font-size:7.0pt;line-height:105%;font-family:"Times New Roman",serif'> </span>“Applicant” and “Applicant Representative related updates</b><b><span style='font-size:7.0pt;line-height:105%;font-family:"Times New Roman",serif'><o:p></o:p></span></b></p><p class=gmail-msolistparagraph style='mso-margin-top-alt:0in;margin-right:0in;margin-bottom:8.0pt;margin-left:0in;line-height:105%'>Next meeting we’ll continue discussion of “Applicant” and “Applicant Representative”, BR section 9.6.3<o:p></o:p></p></div></body></html>