[cabf_validation] 2021-05-06 Meeting minutes

[Corey Bonnell]

Amanda Mendieta

Andrea Holland

Aneta Wojtczak

Ben Wilson

Brittany Randall

Bruce Morton

Clint Wilson

Corey Bonnell

Curt Spann

Dean Coclin

Dimitris Zacharopoulos

Douglas Beattie

Janet Hines

Johnny Reading

Kati Davids

Maileen Del Rosario

Niko Carpenter

Paul van Brouwershaven

Rebecca Kelley

Shelley Brewer

Stephen Davidson

Thomas Zermeno

Tobias Josefowitz

Trevoli Ponds-White

Wayne Thayer

 

Minute-taker: Corey

 

The antitrust statement was read by Wayne.

 

The minutes from the last meeting were reviewed.

 

Dimitris: I'd be happy to discuss about changes to wildcard validation,
especially regarding Tor .onion domain name validation.

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.

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.

 

Wayne asked if there's any additional discussion on
back-dating/forward-dating certificates.

 

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.

 

Dimitris: I think forward-issuing was more problematic. I believe there was
previous agreement than backdating CA certificates is allowed.

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.

Dimitris: You could issue them with a notBefore of the current time and
extend the validity period.

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.

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.

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.

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.

Trev: I'm also struggling to understand the threat model. It sounds like
this would be used for pinning.

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.

 

There was discussion on a security-related topic.

 

There was no other business.

 

Meeting adjourned.

 

Thanks,

Corey

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210507/ab98f8bf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4990 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20210507/ab98f8bf/attachment.p7s>