Minutes IETF106: acme
minutes-106-acme-00

Meeting Minutes Automated Certificate Management Environment (acme) WG
Title Minutes IETF106: acme
State Active
Other versions plain text
Last updated 2019-12-03

Meeting Minutes
minutes-106-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.

Leif: adopt

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
response).

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
and wildcards.

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,
should discuss.

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
important.

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
Forum).