ACME WG notes, 27/3/19 by Robin Wilton Milestone: RFC8555 is out! Rescorla: acme-ip-05 : security considerations section need to be updated following my most recent comments on it. STAR (Short-term Automatically Renewed Certs) - Yaron Sheffer Proposed moving to publish; authors don't feel a new WGLC is needed. => Chairs asked WG to read the current version, as an informal alternative to a new WGLC. Rescorla: My view is that the changes made are sufficient. Ask the incoming AD for his view. Roman (incoming AD): ack Diego Lopez: there is one implementation, available on Github and in use by Telefonica. Rescorla: Is STAR being used in certificate issuance protocols? Cullen Jennings: isn't this the point for the chairs to ask if anyone plans to implement? Michael Richardson: Anima won't exactly implement, but does recommend it and express a need. 3rd-party device attestation for ACME - Rifaat Richard Barnes: URL in the ACME JWT specifies the intended destination of the request, on the CA's ACME server. Is that the intended modification here? => Response inconclusive; RB will re-read the specs. Carsten Bormann: Does authorization become attestation by being packaged as a certificate? What makes this an "attestation"? Rifaat: the JWT specifies that this device is correctly associated with this certificate. Michael Richardson: ACME challenges essentially "attest to the existence of the device". Watson Ladd: what kinds of certificate are these? Rifaat: typically, an identifier for the device (MAC address), and a service URI. Chair: too early to hum for adoption. Draft needs updating to remove any ambiguity around terms of art such as "attestation". ACME Client Certificates - Kathleen Moriarty 1 - Device certificates: Yoran Sheffer - this is interesting but not a good fit for cloud deployments, where entities might not need their own name, but might still need a certificate. Thomas Peterson - IP/DNS not appropriate in all cases. Paul - would be nice if this could work with IPSEC Cert Protocol Richard Barnes - if client certs are already identifying themselves by one of the methods identified in the draft, no added work is needed. No core difference between client certs and server certs except in the EKU (which could be ignored under certain certs). KM - Draft was posted to the mailing list. 2 - End user certs Should ACME handle these? KM not aware of a use case. Can they be left to other organisations? Alexei Melnikov: S-MIME certs are a subset of these. Rescorla: don't think we need a new "meta-framework" to handle end user certs. Thomas Peterson - I think we should, to simplify enterprise handling of browser certs. Code-signing Certificates Max - we do a lot of this, e.g. for cable modem certs. The processes are really strict; the certs are more than EV certs, and we wouldnt feel comfortable automating this. Watson Ladd: don't use SMS/email as pre-authorization methods for this. They are too open to compromise, even with 2FA. Jon: STIR has specified an authorisation token that could be applied in this case - at least as *part* of an automation process. Karthikeyan: we published analysis of ACME last year; Read vs Write authentication channels are markedly different in security. Richard Barnes: consider removing superfluous material from the draft as part of the focussing exercise. Authority Tokens - Jon