[cabf_validation] Meeting Minutes for Subcommittee Teleconference - 2021-Apr-22
Ben Wilson
Validation Subcommittee Meeting April 22, 2021
Antitrust statement: Read by Tim
Attendees: Ben Wilson, Andrea Holland, Clint Wilson, Aneta Wojtczak, Tim Hollebeek, Corey Bonnell, Bruce Morton, Curt Spann, Enrico Entschew, Doug Beattie, Iñigo Barreira, Janet Hines, Johnny Reading, Ryan Sleevi, Michelle Coon, Niko Carpenter, Paul van Brouwershaven, and Wayne Thayer
Agenda: Wildcards, CAA and Certificate Profile Updates
Wildcards & ADNs (SC45): Ryan worked with Dimitris re: how work relates to appendix B (.onion validation rules) and whether a host-based control actually demonstrates control over the whole domain name space.
Sites that use .onion certificates have a Tor daemon on one server that is doing proxying for different subdomains. Subdomains don’t go over the Tor network, they are conveyed by the host header if you’re using http. The daemon runs on one server and inspects the SNI to dispatch to other servers.
Control over one of these destination servers doesn’t mean you have control over the onion private key or the entire domain namespace. Control over the destination server doesn’t mean you control the proxy server. Purpose of the ballot is to make it clear that the validation of a subdomain is not validation of the domain namespace or of subdomains beneath it.
The implementation requirement date is being moved from October 2021 to December 2021.
Corey – ACME IP address validation discussion at IETF is making some security assumptions – concerns about passive proxying and whether use of SNI is sufficient demonstration of control.
Ryan – for this ballot, we are not making such assumptions - control over private key doesn’t assume authorization for the namespace. The primary method for demonstrating control would be the CSR method using the private key. The well-known URI cannot be used to demonstrate control of the whole namespace.
CAA ballot (SC46): Purpose of the ballot is to remove DNS operator exception from the CAA-checking requirements. You always check CAA. That ballot is ready to go.
Certificate Profiles: Ryan announced items to resolve or to call out or to pay attention to.
Name Constraints and BR section 7.1.2.4.2: PDFs circulated on the list, there is dif file you can look at – https://github.com/sleevi/cabforum-docs/pull/36/filesBRs talk about the three constraints – DNS constraints, IP address constraints, and Directory Name constraints. The idea is to transition SHOULD NOTs (profiles phase 1) to MUST NOTs (profiles phase 2). In Mozilla policy, it doesn’t address RFC 822 and SRV names. You could be exempt from audits, but still subject to Mozilla’s policy and CCADB disclosure would be required. The proposed profile would illustrate how to handle constraints for RFC 822 and SRV names. Under Mozilla Policy, the domain part of the RFC822 name must be validated per BR § 3.2.2.4. For SRV names, the name portion must be validated. The goal is to provide guidance for CAs trying to technically constrain intermediate CAs.
If SRV names were supported in browsers, all of these SRV names would not be technically supported and it would create a security risk. Clients can introduce support for the new name types, but the security gap needs to be closed first. There needs to be a transition as CAs issue newer intermediate CAs. Clients/browsers won’t support SRV until CAs have technically constrained their intermediate CAs by SRV names. Ryan will create an issue in the servercert GitHub repository to track steps and conclusions.
With regard to non-critical name constraints, Ryan had a question for Apple. In the profiles v.1 phase, it was decided to go with non-critical name constraints because of Apple and OpenSSL098. What about a 2022 sunset for non-critical name constraints (requiring that they be marked critical)? This would apply to any new sub CAs. Dimitris noted that there are relying parties still using old mobile phones that we need to look at. For example, it is hard to get relying party data because they are customers of customers (e.g. Bank Customers). Ryan noted that there are these issues and he’ll file an issue in the GitHub repository and kick off a discussion on the validation list.
Cross certificates. Ryan noted that in the profiles he was trying to clarify when you issue a cross-certificate to a sub CA. Now it will be called a cross-certified subordinate CA certificate. See BR § 7.1.2.6.
Another related issue is that today we don’t consistently use “subscriber certificates” and “server certificates”. In section 7.1.2.6, the word “server” is added in parenthesis – (Server) – to clarify that is the end entity certificate profile because there is a language issue in the BRs today.
Ryan asked whether his current approach in sections 7.1.2.6.1 – 7.1.2.6.5 (IV, DV, OV, EV) was acceptable. Then, there are two other types of end entity certificates (not to be tackled in the profiles v1 phase) – (a) signed-exchange certificates with extensions and issues with EKU compatibility and they are 90-day certificates. Intent is that they authenticate the domain name just like TLS certificates and they want to be treated like TLS certificates, and (b) delegated credential certificates – that are server certificates that indicate the server supports delegated credentials by protecting keys used in Cloudflare and Facebook, and Mozilla has been supporting these. Neither of these have been finalized yet in IETF (but they need references and runnable code).
Ryan has also updated the pull request description for WIP pull request #36 to explain why things are changing. The next step is to move this to a CABF pull request.
Validity Periods
These are TBD in every certificate profile. There has been concern about backdating (pre-dating, too) server certificates. E.g. strawman proposal is to prohibit back dating past 30 days and only if the information was valid at that time. Thus, you would be prohibited from back dating a server certificate if you verified the domain only today. Also, there would be no pre-dating – you cannot issue a certificate in the future.
Tim – last time we talked about this, we were not going to allow backdating more than 7 days, but there was still debate about that because there was still an unresolved clock-skew issue. We couldn’t get consistent information. One issue, for example, is that customers want their certificates as quickly as possible, so certificates are issued as soon as validation is performed. So the second part of the requirement (only if the information was validated), presents a problem because the reason for backdating is to account for clock skew.
Ryan – what is the right balance?
Tim – We need two rules- one for short backdating and one for long backdating.
Iñigo – what about CAs trying to avoid requirements?
Ryan – yes, we need to make sure that the BR addresses this, and validity periods would still need to be observed.
Backdating CAs – the effect on optimal path-building necessitates some degree of backdating. The rules for CAs needs to be more permissive, but with a caveat. Let’s say you have an existing CA with a given SPKI, and you are trying to replace it. If you are transitioning to a new certificate from an existing certificate, backdating is fine.
Curt: Does there need to be a tie to the audit window?
Ryan: Look at section 7.1.2.2.1 of the document. I think your question relates to the replacement of a CA with a cross certificate. Thus, if the certificate was audited according to the then-existing requirements, and everything was good, then you can still backdate. In other words, if you have all of the audits, then you can backdate to that period. But if you created the root or sub CA and it was not audited for a period of time, then you cannot backdate.
Adjourned.