Subject: Re: [Acme] Draft notes from 27/3/19

From: "Salz, Rich" <[email-masked]>
Date: Wed, 27 Mar 2019 11:27:29 +0000

Thank you Robin!

Please post corrections here, the chairs will integrate and post to the datatracker.

From: "[email-masked]" <[email-masked]>
Date: Wednesday, March 27, 2019 at 12:27 PM
To: "[email-masked]" <[email-masked]>
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

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 27 Mar 2019 12:38:14 +0100

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:
> *From: *"[email-masked]" <[email-masked]>
> *Date: *Wednesday, March 27, 2019 at 12:27 PM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[Acme] Draft notes from 27/3/19
>
> ACME WG notes, 27/3/19
>
> Rescorla: acme-ip-05 : security considerations section need to be 
> updated following my most recent comments on it.
>
> 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?
> Carsten Bormann: Does authorization become attestation by being 
> packaged as a certificate? What makes this an “attestation”?
>
> Chair: too early to hum for adoption. Draft needs updating to remove 
> any ambiguity around terms of art such as “attestation”.
>
>
> 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.
>
> 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).
>
> 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.
>