[cabf_validation] Meeting Minutes for Subcommittee Teleconference - 2021-Apr-22

[Ben Wilson]

Here are the draft minutes.

*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/files

BRs 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210427/82db0acb/attachment.html>