<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;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.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>Amanda Mendieta<o:p></o:p></p><p class=MsoNormal>Andrea Holland<o:p></o:p></p><p class=MsoNormal>Aneta Wojtczak<o:p></o:p></p><p class=MsoNormal>Ben Wilson<o:p></o:p></p><p class=MsoNormal>Brittany Randall<o:p></o:p></p><p class=MsoNormal>Bruce Morton<o:p></o:p></p><p class=MsoNormal>Clint Wilson<o:p></o:p></p><p class=MsoNormal>Corey Bonnell<o:p></o:p></p><p class=MsoNormal>Curt Spann<o:p></o:p></p><p class=MsoNormal>Dean Coclin<o:p></o:p></p><p class=MsoNormal>Dimitris Zacharopoulos<o:p></o:p></p><p class=MsoNormal>Douglas Beattie<o:p></o:p></p><p class=MsoNormal>Janet Hines<o:p></o:p></p><p class=MsoNormal>Johnny Reading<o:p></o:p></p><p class=MsoNormal>Kati Davids<o:p></o:p></p><p class=MsoNormal>Maileen Del Rosario<o:p></o:p></p><p class=MsoNormal>Niko Carpenter<o:p></o:p></p><p class=MsoNormal>Paul van Brouwershaven<o:p></o:p></p><p class=MsoNormal>Rebecca Kelley<o:p></o:p></p><p class=MsoNormal>Shelley Brewer<o:p></o:p></p><p class=MsoNormal>Stephen Davidson<o:p></o:p></p><p class=MsoNormal>Thomas Zermeno<o:p></o:p></p><p class=MsoNormal>Tobias Josefowitz<o:p></o:p></p><p class=MsoNormal>Trevoli Ponds-White<o:p></o:p></p><p class=MsoNormal>Wayne Thayer<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Minute-taker: Corey<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The antitrust statement was read by Wayne.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The minutes from the last meeting were reviewed.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Dimitris: I'd be happy to discuss about changes to wildcard validation, especially regarding Tor .onion domain name validation.<o:p></o:p></p><p class=MsoNormal>Corey: Perhaps I missed it, but it sounds like we are now looking to prohibit validation of other FQDNs using method 18/19 even if the validation is performed on the .onion Domain Name with exactly two labels.<o:p></o:p></p><p class=MsoNormal>Dimitris: Yes, we did further analysis and it turns out that the security risks for allowing the two-label .onion Domain Name is exactly the same as validation against any Base Domain Name. For example, a customer may want to have a load balancer set up with more than two nodes, and they could not control the domain namespace, as they would just serve a specific domain name. In that case, the only reasonable method to validate control of the entire namespace is by using the Tor private key. If an operator controls a single domain name, they can still use method 18/19 to validate that specific domain name.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Wayne asked if there's any additional discussion on back-dating/forward-dating certificates.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Doug: I believe there are two cases of backdating: one where the certificate may be backdated for a small period and may be validated after the notBefore date of the certificate slightly. Another case is backdating farther back, where it may be necessary to reuse a previous validation. We need to define what exactly the "short period of time" exactly is.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Dimitris: I think forward-issuing was more problematic. I believe there was previous agreement than backdating CA certificates is allowed.<o:p></o:p></p><p class=MsoNormal>Corey: There is a potential use case for forward-dating where if you have short-lived certificates (on the order of weeks) and the webserver operator wants to issue in advance several of these certificates in the event they will be unable to renew quickly to ensure high availability.<o:p></o:p></p><p class=MsoNormal>Dimitris: You could issue them with a notBefore of the current time and extend the validity period.<o:p></o:p></p><p class=MsoNormal>Corey: Extending the validity period would allow for the keypair lifetime to be longer than desired. A few years ago, prior to the SHA-1 sunset, we saw CAs forward-date OCSP responder certificates well into the future but logged pre-certificates to CT and embedded SCTs in the final certificate to attest to the actual issuance time. This allowed them to minimize the validity period of the responder certificates. This is like the use case for the web server.<o:p></o:p></p><p class=MsoNormal>Trev: I'm having trouble understanding the security benefit of these two cases. Having a collection of these certificates decreases security, especially in the OCSP case. I don't see how having several pre-issued week-long certificates is better than having just one month-long certificate.<o:p></o:p></p><p class=MsoNormal>Corey: The idea is that you change the key pair in each week-long certificate. Whereas with the month-long certificate, you must use the same key for the entire month.<o:p></o:p></p><p class=MsoNormal>Wayne: I struggle to see the threat model and how that makes things more secure. For OCSP responder certificates, this makes sense since they cannot be revoked.<o:p></o:p></p><p class=MsoNormal>Trev: I'm also struggling to understand the threat model. It sounds like this would be used for pinning.<o:p></o:p></p><p class=MsoNormal>Corey: The intent is not to facilitate pinning, but rather to account for outages or other availability issues that may make it infeasible to renew prior to expiry of the current certificate.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>There was discussion on a security-related topic.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>There was no other business.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Meeting adjourned.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Corey<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>