[Anima] BRSKI<->ACME use case (was: Re: FWD: ACME for devices side meeting)

[Toerless Eckert <[e-mail]>]

Some thoughts about draft-friel-acme-integration also after the ACME side meeting.

Talking to Owen after ANIMA, he explained the use case for his draft,
which would be great to include into a rev. At least i hope i wasn't
the only one to whom it wasn't completely obvious even without being
stated ;-))

The way i would desribe the use-case is this:

You are an enterprise or home, you may have some BRSKI like
infrastructure (cloud-based, local, whatever) that helps to auto-enroll
any type of devices you want to use in your network, but: Many of these
devices will have a web-server to access/control/use them, and when
you access them via a browser there is the issue that web browsers
will complain unless the device is enrolled with a certificate signed
by a public PKI CA (in the browsers TA list) and can be used to 
authenticate the domain name the device is using.

This is where ACME comes in because the key thing separating itself from
EST is that it has the mechanisms so RA (registrars) can provide proof
of ownership of a DNS domain/prefixes for which they can then request
certificates. At least thats how i understood the explanation given to me.

So, i would certainly welcome if we made sure BRSKI<->ACME can be made
to work well.

Another thing coming to mind: devices that have a web-server will
support TCP, so they won't pose the problem of having to change the
basic transport protocol to use for BRSKI, unlike the constrained "iot"
devices, where we have to use protocols like CoAP. And given how
we made sure that the ANI certificate pieces do not conflict with any
type of certifictes attributes required for "web certificates", this
should also all work well with not only BRSKI but even ANI (using
certificates with the ACP rfc822Name). At least this would be my hope,
and certainly something i would like to verify with ACME.

Cheer
    Toerless

On Thu, Jul 25, 2019 at 12:00:15AM +0200, Toerless Eckert wrote:
> 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
> > 
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[e-mail]