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. 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. 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. Regards, Rifaat On Wed, Apr 17, 2019 at 1:09 PM Richard Barnes <r...@ipv.sx> 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 Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
