Thanks Owen, I honestly did not have a chance to look BRSKI yet.
Just to make sure that I understand you correctly, are you saying that BRSKI has a solution for my use case with ACME? If so, can you please point me to the right document? Regards, Rifaat On Tue, Apr 23, 2019 at 6:41 PM Owen Friel (ofriel) <[email protected]> wrote: > Hi Rifaat, > > Inline. > > > > *From:* Rifaat Shekh-Yusef <[email protected]> > *Sent:* 17 April 2019 20:37 > *To:* Richard Barnes <[email protected]> > *Cc:* IETF ACME <[email protected]>; Owen Friel (ofriel) <[email protected]> > *Subject:* Re: Use cases / trust model for device certs > > > > Hi Richard, > > > > I was not aware of the ANIMA work before the meeting in Prague, so I will > definitely look into that in details. > > > > One use case that I have in mind is a way to make sure that a specific > device can only be used by a specific party. > > If you rely on RP to request identities for the device, then any party > that has a valid ACME account can use any device. > > [ofriel] This is one of the use cases that BRSKI enables. Read the > sections relating to Ownership Tracker. > > > > For example, if party A purchased a device from the vendor, and party B > gets a hold of that device, then there > > is nothing that prevents party B from getting a valid ACME certificate for > that device. > > [ofriel] With strict ownership tracking, BRSKI is flexible enough to > prevent devices from bootstrapping against a network without proof of > ownership. > > > > If instead you reply on a token from the Device Authority, then the CA > will only issue a certificate to a specific party and specific device. > > [ofriel] The Device Authority appears to perform a similar function to the > MASA audit log function. The Client (i.e. customer.com) can claim devices > from the DA (via some sales channel/integration API), the DA issues JWTs > indicating that the device is claimed by a specific Client, and ACME checks > that the requesting Client matches that in the JWT which the DA has logged. > The BRSKI MASA service audit logs every single domain that a device has > registered against, and does not preclude Registrars claiming > devices/proving ownership via some sales channel integration/API. It > appears that this proposal is trying to address similar issues as BRSKI. > > > > Regards, > > Rifaat > > > > > > On Wed, Apr 17, 2019 at 1:09 PM Richard Barnes <[email protected]> wrote: > > Hey Rifaat, > > > > Owen and I were chatting about ACME and device certs this morning, and it > seemed like it might be useful to rekindle discussion on the topic here on > the ACME list. > > > > I'd like to push a little more on the trust model here. Just to establish > some terminology: > > > > - Device: Uses certificates to authenticate identifiers > > - Vendor: Makes the device that will get the end certificate > > - Customer: Buys the device from the vendor and operates it > > - CA: Validates identifiers and issues certificates > > - Relying Party: Uses certificates to verify authentication for identifiers > > - Device Identity: MAC address or similar > > > > In the flows Owen and I have been discussing (more based on ANIMA/BRSKI), > the model is basically broken in two, with the customer in the middle: > > > > 1. The customer validates devices' device identity as part of the ANIMA > flow, based on the customer trusting the vendor, and assigns the device a > domain name > > 2. The customer uses ACME to issue domain name certificates (the CA is > unaware of the device identity) > > > > That all pretty much just works with BRSKI and ACME as they are today. > But it presumes that the RP is authenticating the device by domain name, as > is prevalent in most uses of TLS today. > > > > In contrast, it seems like your draft presumes that the RP needs to know > the device identity; it's not satisfied by a domain name alone. Can you > elaborate a bit more on what scenarios you have in mind for this? If all > you care about is the customer tracking things, then the model above is > sufficient; the customer can simply assign domain names that encode the > device identity however it likes. > > > > Thanks, > > --Richard > >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
