So a few minor naming corrections for the STAR session: Roman is our
incoming AD, the person from Telefonica is Diego Lopez, and Carl is
really Cullen.
On 27/03/2019 12:27, Salz, Rich wrote:
Thank you Robin!
Please post corrections here, the chairs will integrate and post to
the datatracker.
*From: *"[email protected]" <[email protected]>
*Date: *Wednesday, March 27, 2019 at 12:27 PM
*To: *"[email protected]" <[email protected]>
*Subject: *[Acme] Draft notes from 27/3/19
ACME WG notes, 27/3/19
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.
Rowan (incoming AD): ack
Telefonica: there is one implementation, available on Github and in
use by Telefonica.
Rescorla: Is STAR being used in certificate issuance protocols?
Carl 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 wouldn’t
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
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
