Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt

[Rifaat Shekh-Yusef <[e-mail]>]

Thanks for the review and feedback, James.
See my reply inline below.

Regards,
 Rifaat


On Thu, Jan 24, 2019 at 8:27 PM Manger, James <
[e-mail]> wrote:

> I’m confused about what is desired with
> draft-yusef-acme-3rd-party-device-attestation, but I think it may be quite
> different from what draft-ietf-acme-authority-token offers. Here’s my guess:
>
>
>
> draft-ietf-acme-authority-token is designed to issue certs for namespaces
> other than domain names, eg for phone numbers. The CA trusts another
> authority to vouch for that namespace.
>
>
>
> draft-yusef-acme-3rd-party-device-attestation is designed to issue certs
> for a domain name (as per normal Acme). The cert will be for a specific
> device whose serial number (eg MAC address) the domain-owner knows. The
> device manufacturer can vouch for device keys associated with that serial
> number.
>

Yes, and that was captured in section 2.2:
https://tools.ietf.org/html/draft-yusef-acme-3rd-party-device-attestation-01#section-2.2



> Curiously, the protocol flow in
> draft-yusef-acme-3rd-party-device-attestation doesn’t seem to involve the
> device at all – only the domain-owner (client), manufacturer, and CA. But
> surely the device needs to provide the CSR?
>
>
This is out of scope for this document, as the document is focusing on the
ACME interface. But you are correct that the device will be the one that
provides the CSR.


>
>
> It sounds like the client (domain-owner) should be able to confirm the
> correct device is involved (by talking to the device and manufacturer)
> before sending a normal ACME request. That way the ACME CA doesn’t need to
> know anything about the device attestation.
>

Correct. This the the OAuth interaction, which is out of scope for this
document.

Regards,
 Rifaat



>
>
> --
>
> James Manger
>
> [phone]
>