Minutes IETF106: acme
Automated Certificate Management Environment
||Minutes IETF106: acme
Friday Nov. 22, 12:20.
Notes by Yaron Sheffer.
CAA published, 3 drafts in RFC Ed queue.
STAR Delegation: about 6 people indicated interest in-person.
Jon described an implementation of ACME certs in the STIR/TNauth context.
Kathleen: updated the Client draft with additional challenge types.
Hum: adopt, with a few voices that are undecided.
Alexey: describes changes to S/MIME draft in -06. Draft requires ACME, S/MIME
as well as Email expertise. Will reach out to relevant WGs. Rich: will issue WG
LC after the holidays, January.
Owen: Subdomain certs. Turns out several changes required in RFC 8555,
including one substantial change. One of the changes depends on an errata (200
Adoption hum: yes, will confirm on the list.
[EKR: too quick for me]
MCR: is concern that challenges will be confused. EKR: not sure. Should clarify
in security considerations. MCR: there may be people who confuse between this
Deb Cooley: this is for a specific subdomain. EKR: yes, but distinguishes
between issuance and verification.
Deb: how unusual to have a subdomain. EKR: very common. But usual assumption in
DNS is that parent controls child. We need a special indicator...
DKG: you can measure how common it is by looking at "public suffix list".
Owen: ACME integrations. 5 use cases. EMU and ANIMA are interested.
MCR: the docs are more technical ACME.
Rich: has it gone through TEEP? Owen, not controversial.
Roman: EMU is intereted, but did not discuss the venue.
Rich: need more discussion in the WG before adoption.
Yaron: CSR work (and maybe CSR template) might overlap with STAR Delegation,
Owen: need someone from a public CA to define policy on certificate fields
[which specific fields]? Rich: talk to LAMPS.
Deb: do you have a specific EKU in mind? Owen: yes. Deb: and commercial CAs
will not issue it.
Owen: in some bases the supplicants can only check DNS name.
Deb: not associated with a public CA :-)
DKG: does it mean EKU is meaningless because we cannot change it?
Deb: public CA cannot verify a private SSID. That's the big problem. EKU is a
smaller problem. Just a matter of changing the process.
Owen: this will take years.
DKG: the EKU determines that the verification method is different, it is very
MCR: chicken and egg: we are not a big enough market for them to care.
Deb: need to talk to C/AB Forum, plus various proprietary CAs (Microsoft).
Joe: there may be a CA that issues certs for hot spots (old spec from WiFi