[Anima] FWD: ACME for devices side meeting

[Toerless Eckert <[e-mail]>]

Owen sent the following nice notes about the side meeting.
Will comment separately. Bcc'ing the original recipients.

On Wed, Jul 24, 2019 at 08:26:20PM +0000, Owen Friel (ofriel) wrote:
> Minutes from today's meeting.
> 
> General consensus that figuring out how to use ACME for issuance of device/client certs is a good idea
> 
> There are (at least) three related drafts in this space
> - draft-yusef-acme-3rd-party-device-attestation
> - draft-friel-acme-integrations
> - draft-moriarty-acme-client
> 
> draft-moriarty-acme-client
> - outlines several use cases for client and device certs
> - as Kathleen could not make the meeting, we didn't discuss this in detail
> 
> draft-yusef-acme-3rd-party-device-attestation and subsections of draft-friel-acme-integrations are trying to solve similar problems:
> - leverage a cloud service to assist in ownership proofs for devices
> - use ACME to issue LDevID certificates to devices
> 
> draft-yusef-acme-3rd-party-device-attestation
> - assumes devices have self-signed certs, not certs signed by a manufacturer private CA
> - The BRSKI-ACME flow Rifaat presented uses a vendor default BRSKI registrar, and is a reasonable starting point for device's getting certs from ACME
> - This flow is not currently documented in Rifaat's draft
> - We can probably avoid the need for ACME to understand the vendor's JWT
> 
> draft-friel-acme-integrations
> - documents (partially) the BRSKI-ACME flow but uses a local domain registrar, not the vendor default registrar
> 
> draft-ietf-anima-bootstrapping-keyinfra
> - underspecifies how the MASA should handle Voucher Requests directly from the Pledge i.e. the Cloud Registrar use case
> - Toerless suggests that this clarification could be a small standalone document
> 
> No draft currently sufficiently specifies how the pledge/device should generate a CSR subject/SAN that will keep ACME happy
> 
> The EST/BRSKI sections of draft-friel-acme-integrations, and draft-yusef-acme-3rd-party-device-attestation, probably need to be combined by a new draft
> - if the device is going to use a self-signed cert, then how the EST RA validates device identity needs to be specified as this is a change from BRSKI
> 
> The ACME subdomain use case needs to be split out from draft-friel-acme-integrations into a separate small document
>