On Tue, Jan 15, 2019 at 1:58 PM Rifaat Shekh-Yusef <[email protected]>
wrote:
> The proposed mechanism does not suggest the CA perform a domain validation
> based on
> an attestation from the Device Authority.
> Instead, the Client that already has an account with the ACME server and
> proved that it has control
> over the domain, is asking for a certificate to be issued to a specific
> device with their domain.
>
I had the same reading and reaction as Ilari when I first read it.
Specifically, from reading Section 2.2, I found that a bit confusing, as it
reads:
For example, if vendor.com is configured as a trusted entity on ACME
server, and if a device from vendor.com is being deployed by a
customer.com, and customer.com requires the device to obtain an ACME
certificate, this mechanism allows the automatic issuance of
certificates to the device with the customer.com identifier based on
attestation from vendor.com.
This seems to suggest some delegated form of domain validation; if that's
not intended, then this is probably a problematic description of the use
case.
This seems similarly supported based on 2.3, namely:
This architecture assumes a trust relationship between the ACME CA
and the Third-Party Device Authority, which means that the ACME CA is
willing to accept the attestation of the Third-Party Device Authority
for particular types of identifiers as sufficient proof to issue a
certificate.
>From reading through your protocol flow in Section 2.4 and Section 7, it
appears the use case is for ACME CA to allow Client to attest a non-domain
identity (in this case, "identifier={mac}"), in addition to the domain
name. Rather than ACME CA directly validating the "identifier={mac}", it
relies on an apriori trust relationship with Device Authority, and Client
demonstrates their control/ability by the use of JWT via Device Authority.
Is that an accurate read?
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
