Few updates, but several new adopters
Some feedback has been presented on GitHub but not the mailing list
Q Misell: Distinction between this draft's WebAuthn and similar
challenge from Device Attestation draft?
Mike Ounsworth: WG has a July 2024 milestone to either move this
forward or abandon it
Sean Turner: Let's proceed to last call
Aaron Gable: Likes that the draft describes generic challenge types,
but
Charles Eckel: Would like clarification on relationship to
Dave Robin: Confusion on whether document is a survey, or a protocol
extension
Peter Liu: (notetaker missed this question)
Within cloud environments, you can either use their ACME CA, or
manually upload your own PEM file
Client problem: let ACME client discover what CA to use, given only
an identifier
Server problem: let CA discover what client account keys are
authorized
Drafts looking for a new owner
Aaron Gable: what about discovery for non-DNS identifiers (like IP
or DTNNodeID)
Q: Added code for this to a fork of certbot, quickly and easily
Leif Johansson: autodiscovery is also present in
draft-demarco-acme-openid-federation (see below)
Goal is to defend against public key replacement attacks
Four actors: Applicant, IDP, ACME Server, ACME Client
Draft adds a new challenge type, in which the server uses the IDP to
check that the requested pubkey is one the applicant actually wants
to use
Kathleen Moriarty: looks very similar to expired openid-connect
draft
Q Misell: Two main issues with the draft
David Adrian: it's good to have public key control challenges
David Robin: why are we getting rid of the CSR?
Since last meeting, added use case, current practices
Use case: inspector connecting to local wifi at each site
Draft puts RATS attestation in newOrder request
Next steps: design team continuing to meet, hope for adoption in
Montreal
Q Misell: RFC 8555 says that "a server should consider one challenge
sufficient"
Kathleen Moriarty: this could tie into the RATS posture assessment
draft
Creates a new JWTClaimConstraints identifier type
Cert may contain both TNAuthList and JWTClaimConstraints
Draft contains lots of discussion of how to validate these together
Next steps: seeking WG review and then adoption
To get around this, lots of impls use a CNAME to delegate DNS to a
cloud provider
So let's enshrine this, create a validation method using a
long-lived DNS record
Draft fully matches CABF's proposed syntax
ACME Challenge object has type "dns-persist-01", and no "token"
field
Q Misell: this is good, ACME for Onions also moved language from
CABF to ACME
Corey Bonnell: highly supportive
Erik Nygren: should also coordinate with DNSOP draft