
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Apologies for the delay in providing these minutes.<div class=""><br class=""></div><div class="">Validation Subcommittee | July 29, 2021<br class=""><br class="">Attendees:<br class="">Andrea Holland <br class="">Aneta Wojtczak <br class="">Ben Wilson<br class="">Clint Wilson<br class="">Corey Bonnell<br class="">Dean Coclin<br class="">Dimitris Zacharopoulos<br class="">Doug Beattie<br class="">Iñigo Barreira<br class="">Johnny Reading<br class="">Kati Davids<br class="">Paul van Brouwershaven<br class="">Ryan Sleevi<br class="">Rebecca Kelley<br class="">Shelley Brewer<br class="">Tim Hollebeek<br class="">Trevoli Ponds-White<br class="">Tyler Myers<br class=""><br class="">Antitrust Statement was read.<br class=""><br class="">Agenda Items:<br class="">Update on Certificate Profile work and review that’s occurring, have lots of comments that they’d like to get out soon.<br class="">Ryan pulled together some data and shared with the mailing list around crlDistributionPoints that we’d like to look at.<br class=""><br class=""><u class="">Feedback</u><br class="">Ryan: Giving a bunch of feedback all at once is probably the least productive way to give feedback. Incremental feedback works with incremental improvement. Batching feedback will just make everything take longer. Share what you’ve got and make it a dialogue so we can discuss sooner.<br class="">Tim: We are trying to collect a large amount of feedback from a very broad audience and trying to present it comprehensibly.<br class="">Ryan: Dimitris is great about raising feedback as it comes up, and it allows us to close out a lot of concerns and make improvements.<br class=""><br class=""><u class="">crlDistributionPoints</u><br class="">Tim: Let’s discuss crlDistributionPoints.<br class="">> Ryan provided a summary of points made in his email titled “crlDistributionPoints Encoding” (<a href="https://lists.cabforum.org/pipermail/validation/2021-July/001675.html" class="">https://lists.cabforum.org/pipermail/validation/2021-July/001675.html</a>)<br class="">Ryan: The proposed next steps for profiles v1 is to allow both and make sure that’s unambiguously clear (that both are allowed). For profiles v2, we’d like to allign on a canonical form, however if CAs that are most impacted want to do that in v1, that would be great. Then a few CAs have interpreted it to allow LDAP/non-HTTP, which doesn’t happen much at all, that we’d like to clarify. DigiCert folks, why are you using multiple crlDistributionPoints instead of multiple full-names?<br class="">Tim: It’s not clear to me, so definitely something we can have an internal discussion on it.<br class="">Ben: There was a time that multiple CDNs were in use, and each CDN had one URL. Does that help clarify?<br class="">Ryan: Yeah, and that’s definitely a use-case for that, e.g. with a CDN located in China. In my personal ideal world, I’d love to see just one URL.<br class="">Tim: I understand that and the multiple URLs does help with our scale, but Ryan’s question is legitimate in that we could encode multiple URLs in a different way — scheme A v scheme B.<br class="">Corey: Out of curiosity, did you fetch the URLs as part of this?<br class="">Ryan: Nope, I was trying to over-capture if anything, so it overcounts. This isn’t a perfect representation, but it gives us an idea of the problem, scale, and diversity. And again, nothing is wrong with what DigiCert is doing with their crlDistributionPoints. There are a lot of ways to trim down the data set, but I intentionally did not to ensure that I wasn’t overlooking anything.<br class="">Corey: There is a semantic difference to the different schemes. So it could be that one distribution point is pointing to a full CRL and another to a shard.<br class="">Ryan: I did look at that, so you could have a CRL that’s only keyCompromise for example. So I looked at whether CAs are sharding the CRLs by reasons, and didn’t find anyone that was doing that. There are various equivalent encodings that could have been represented.<br class="">Paul: Have you looked at implementations, how they interact with different encodings?<br class="">Ryan: Yes, that’s explained some in the email. I’m not aware of any implementation that treats the different encodings as semantic differences, or that has trouble with the different encodings. That’s part of the question, is to see if anyone is aware of any issues.<br class="">Paul: I was looking at the Go implementation, where it will default to encoding as multiple distribution points.<br class="">Ryan: I haven’t looked in depth at all of the various default encoding behaviors. The goal here is provide guidance where there are multiple options, and if we can save four bytes on this as well, that’s worth doing. There’s also the question of whether there are use-cases which necessitate using multiple URIs.<br class="">Corey: There are more partitioning strategies than just by reasonCode, for example a CA could shard by expiry date or the size of the expected certificate. The approach would be to encode a crlDistributionPoint with a specific URL for the sharded CRL, and within that CRL they would include the criticalIssuingDistributionPoints extension to ensure a substitution attack couldn’t occur. Given the many sharding strategies available, fetching the CRLs, and ensuring whenever there are multiple URIs listed that they’re binary equal, but still allowing for that flexibility where you could still point to the full CRL for the issuing CA or you could have that sharding, because those would necessarily have to be encoded as different crlDistributionPoints.<br class="">Ryan: Only the sharding by reasonCode would require multiple crlDistributionPoints. If you are sharding by reason, you have to include that in the certificate itself. Sharding by anything else (e.g. expiration date) you can encode that within the CRL. Is there a scenario where there are two URIs where the first URI is a sharded CRL, and the second is the full CRL? That’s likely not a great idea since the whole point of sharding CRLs that way is because clients don’t need to know about the full CRL. I’m happy to dump a CSV of all these URIs if that’s interesting, but I question that it’s a legitimate use-case.<br class="">Corey: The use-case is that the IDP extension has to be encoded as critical, but client support is optional. It’s a theoretical use-case, but maybe it could explain what we’re seeing here.<br class="">Ryan: Yeah, that’s technically valid, though I’m not aware of clients having issues with critical IDP extensions. I’d like to get data on that if that’s a real-world use-case.<br class="">Tim: One issue that’s come up with doing it with DNS on the backend is you lose whether the URL behaves the same for every user.<br class="">Ryan: Totally hear you, it’s a tradeoff, but multiple URIs does tend to push complexity to the client.<br class="">Tim: Any other comments?<br class="">Dimitris: I’m worried that I’m not entirely sure about the goal. We can reduce the size of certificates, but we are supposed to support 5280 in more than one way. Should we only support what browsers are wanting, like one CRL?<br class="">Ryan: I think the goal here is to have an established happy path. No one really supports all of 5280. So there’s a desire to end up with a profile that makes it easier for both clients and servers, that someone writing a new browser can have reduced risk. If you want to compare subject name to issuer name in CRLs, for example, there’s a lot of complexity added. You’ll eventually end up reading T61 and some scanned paper from the 60s. So reducing some of the complexity, defining the happy path, that’s a goal. Then another side is what can we do to make things more efficient, smaller. Yes, it’s targeting browsers a bit, but new browsers could join at any point and the Web PKI is, unfortunately, still used outside of browsers. Security bugs always hide where there’s complexity.<br class="">Dimitris: Yes, that’s satisfactory. Making a decision to have a more specific profile will still be compliant with 5280 and it won’t impact other implementations that do want to use more of the encoding options.<br class="">Aneta: OCSP Responder profiles currently points to the CA section, but it has its own section so we should fix it.<br class="">Ryan: There are several base profiles, that we reference when another profile has the same rules. I do have some changes to the OCSP section is related to basicConstraints, so that’s one change I’m planning on making.<br class="">Aneta: There is a separate section 7.1.2.7 for OCSP Responders, it’s pointing to the extension for the CA, but they don’t match. There is a section for OCSP Responder extensions though.<br class="">Ryan: Got it, yeah I may have a bad link there. The reference to extensions in <a href="https://github.com/sleevi/cabforum-docs/blob/profiles/docs/BR.md#7127-ocsp-responder-certificate-profile" class="">https://github.com/sleevi/cabforum-docs/blob/profiles/docs/BR.md#7127-ocsp-responder-certificate-profile</a> is a typo and I’ll fix that.<br class="">Aneta: Will we have a discussion around the validity period of OCSP Responders.<br class="">Ryan: That’s why I haven’t pushed some of these changes up yet, trying to sort out the validity question. There was discussion in the past to get to 90 days. Some CAs were having issues with that, not saying they’re doing anything wrong. I’m not thrilled with 1-year validity OCSP Responders, but that was the current thinking for v1 and then to update it to <=90 days in v2.<br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""><br class=""></div></body></html>