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

[Yaron Sheffer <[e-mail]>]

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: *"[e-mail]" <[e-mail]>
> *Date: *Wednesday, March 27, 2019 at 12:27 PM
> *To: *"[e-mail]" <[e-mail]>
> *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
>
>
>
>
>
>
>