Minutes IETF104: acme
minutes-104-acme-00

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