Subject: [Iot-onboarding] ACME for devices side meeting

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Wed, 24 Jul 2019 20:26:20 +0000

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

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 24 Jul 2019 23:46:03 +0200

Thanks, Owen

Let me forward your notes to anima mailing list and encourage folks here
to have the discussion on that mailing list that i think is best done
there. Which i think is most of the aspects discussed because it looks
to me as if almost all the aspects discussed center around MASA and
(BRSKI)RA. 

Cheers
    Toerless

> -- 
> Iot-onboarding mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iot-onboarding

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 25 Jul 2019 00:00:15 +0200

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