[{"author": "Daniel Gillmor", "text": "

and yes, i welcome others pitching in, too

", "time": "2023-07-25T00:30:06Z"}, {"author": "Deb Cooley", "text": "

and we aren't looking for a transcription, just rough notes are fine.

", "time": "2023-07-25T00:30:20Z"}, {"author": "Yoav Nir", "text": "

I will also watch this chat, so if anyone wants something relayed to the room in a disembodied voice, please preface it with \"mic:\"

", "time": "2023-07-25T00:31:16Z"}, {"author": "Deb Cooley", "text": "

meetecho: can we turn up the volume?

", "time": "2023-07-25T00:32:28Z"}, {"author": "Samantha Frank", "text": "

Yes

", "time": "2023-07-25T00:33:04Z"}, {"author": "Amir Omidi", "text": "

Loud & Clear

", "time": "2023-07-25T00:33:07Z"}, {"author": "Lorenzo Miniero", "text": "

Is it a problem for local attendees or remote ones? Which volume is low?

", "time": "2023-07-25T00:33:31Z"}, {"author": "Daniel Gillmor", "text": "

@Lorenzo Miniero i think we're hearing Yoav (who is remote) fine now, thanks

", "time": "2023-07-25T00:34:07Z"}, {"author": "Lorenzo Miniero", "text": "

Ack!

", "time": "2023-07-25T00:34:13Z"}, {"author": "Brian Dickson", "text": "

This seems to heavily overlap with work in the dnsop wg.
\nTheir draft is well along the way, although not yet adopted as a WG item, I believe.

", "time": "2023-07-25T00:41:23Z"}, {"author": "Brian Dickson", "text": "

(Also, a functional ecosystem built on an expired draft: domainconnect - I plan on resurrecting the draft.)

", "time": "2023-07-25T00:42:33Z"}, {"author": "Jim Reid", "text": "

Which ID(s) Brian?

", "time": "2023-07-25T00:43:08Z"}, {"author": "Brian Dickson", "text": "

https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-domain-verification-techniques-02

", "time": "2023-07-25T00:46:05Z"}, {"author": "Brian Dickson", "text": "

(The one you just reviewed, Jim)

", "time": "2023-07-25T00:46:13Z"}, {"author": "Brian Dickson", "text": "

Domain Connect:
\nhttps://datatracker.ietf.org/doc/draft-carney-regext-domainconnect/

", "time": "2023-07-25T00:46:52Z"}, {"author": "Jim Reid", "text": "

I thought it was that one Brian - just wanted to be sure.:grinning:

", "time": "2023-07-25T00:47:42Z"}, {"author": "Amir Omidi", "text": "

https://cabforum.org/baseline-requirements-documents/

\n

https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-v2.0.0.pdf

", "time": "2023-07-25T00:48:30Z"}, {"author": "Brian Dickson", "text": "

I am aware of a large CA that would be interested in moving as soon as the requirements get updated. (Brian from GoDaddy)

", "time": "2023-07-25T00:49:42Z"}, {"author": "Corey Bonnell", "text": "

Amir Omidi said:

\n
\n

https://cabforum.org/baseline-requirements-documents/

\n

https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-v2.0.0.pdf

\n
\n

Section 3.2.2.4.7, in case you don\u2019t want to go digging through the whole doc

", "time": "2023-07-25T00:55:45Z"}, {"author": "Tim Hollebeek", "text": "

When we wrote the HTTP validation methods, proxying it across onion was not something we thought about, and I'm a little bit worried it might change the security assumptions a bit. For example, a malicious exit node could perhaps cause validation to succeed when it should fail, and a bad actor could try validations until they hit the exit node they want. Even if that doesn't work, it's probably worth doing a little bit of thinking about whether HTTP-01 over Onion is actually safe. We intentionally wrote the Appendix B validation because Onion is a bit different.

", "time": "2023-07-25T01:02:32Z"}, {"author": "Michael Richardson", "text": "

I like this.

", "time": "2023-07-25T01:19:18Z"}, {"author": "Brian Dickson", "text": "

Agree, useful, scalable, and the CAA spec supports adding parameters that are optional.

", "time": "2023-07-25T01:20:46Z"}, {"author": "Amir Omidi", "text": "

Cloudflare does that

", "time": "2023-07-25T01:20:53Z"}, {"author": "Amir Omidi", "text": "

https://developers.cloudflare.com/ssl/edge-certificates/backup-certificates/

", "time": "2023-07-25T01:21:15Z"}, {"author": "Tadahiko Ito", "text": "

I believe we need that kind of mechanism to move toward 90 days (or short lived) certs.

", "time": "2023-07-25T01:21:15Z"}, {"author": "Michael Richardson", "text": "

I think that many organizations have a backup set of CERTIFICATES, but as was said, only LE does ACME easily.

", "time": "2023-07-25T01:21:19Z"}, {"author": "Brian Dickson", "text": "

Add DNSSEC FTW

", "time": "2023-07-25T01:23:16Z"}, {"author": "Yoav Nir", "text": "

@Amir: Still in the queue on purpose?

", "time": "2023-07-25T01:24:12Z"}, {"author": "Michael Richardson", "text": "

also the WG should know that CAA ==> Canadian Automobile Association, and it's who you call to get towed.

", "time": "2023-07-25T01:24:20Z"}, {"author": "Brian Dickson", "text": "

Without giving too much away, it would be a good thing to pay attention to announcements from GoDaddy in the near future, concerning DNSSEC...

", "time": "2023-07-25T01:24:33Z"}, {"author": "Amir Omidi", "text": "

Oops left the queue

", "time": "2023-07-25T01:24:59Z"}, {"author": "Samantha Frank", "text": "

awwww

", "time": "2023-07-25T01:25:03Z"}, {"author": "Amir Omidi", "text": "

Didnt intend to be in the queue :)

", "time": "2023-07-25T01:25:07Z"}, {"author": "David Benjamin", "text": "

Can the client actually usefully validate the resulting cert if it knows nothing about the CA? I mean, it can check the certificate is syntactically correct, but the subscriber may legitimately want a CA that isn't known to the client.

", "time": "2023-07-25T01:25:19Z"}, {"author": "Deb Cooley", "text": "

But the client has an account with the CA, so....

", "time": "2023-07-25T01:26:18Z"}, {"author": "Yoav Nir", "text": "

But I think \"client\" is the cloud provider, not the same as the user.

", "time": "2023-07-25T01:27:03Z"}, {"author": "Daniel Gillmor", "text": "

David Benjamin said:

\n
\n

Can the client actually usefully validate the resulting cert if it knows nothing about the CA? I mean, it can check the certificate is syntactically correct, but the subscriber may legitimately want a CA that isn't known to the client.

\n
\n

If we're talking about public CAs and public servers, i'd argue that the client should know something about a widely understood pool of trust roots (whatever that means)

", "time": "2023-07-25T01:28:36Z"}, {"author": "Amir Omidi", "text": "

internal account binding does pertain to servers

", "time": "2023-07-25T01:28:42Z"}, {"author": "David Benjamin", "text": "

@Daniel Gillmor Sure. Yeah, I guess the question is whether this is intended to be for \"the\" Web PKI or more than that. (Quotes around \"the\" because believing that's a singular PKI is already somewhat interesting.)

", "time": "2023-07-25T01:29:33Z"}, {"author": "Brian Dickson", "text": "

Open question: does ACME specs or this WG have any guidance to use of DANE (DNSSEC authentication of named entities)?
\nHas any thought been given to signaling that domain owners are using DANE, even if clients may not yet be checking for TLSA records?

", "time": "2023-07-25T01:30:34Z"}]