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

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 12 Jan 2019 12:38:59 -0500

Hi,

I have submitted the draft below that defines a mechanism to automate the
deployment of certificates to devices based on an attestation from
3rd-party server that has authority over the device.
I would appreciate any review and feedback on this document.

Regards,
 Rifaat

---------- Forwarded message ---------
From: <[email-masked]>
Date: Sat, Jan 12, 2019 at 12:34 PM
Subject: New Version Notification for
draft-yusef-acme-3rd-party-device-attestation-00.txt
To: Rifaat Shekh-Yusef <[email-masked]>

A new version of I-D, draft-yusef-acme-3rd-party-device-attestation-00.txt
has been successfully submitted by Rifaat Shekh-Yusef and posted to the
IETF repository.

Name:           draft-yusef-acme-3rd-party-device-attestation
Revision:       00
Title:          Third-Party Device Attestation for ACME
Document date:  2019-01-12
Group:          Individual Submission
Pages:          9
URL:
https://www.ietf.org/internet-drafts/draft-yusef-acme-3rd-party-device-attestation-00.txt
Status:
https://datatracker.ietf.org/doc/draft-yusef-acme-3rd-party-device-attestation/
Htmlized:
https://tools.ietf.org/html/draft-yusef-acme-3rd-party-device-attestation-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-yusef-acme-3rd-party-device-attestation

Abstract:
   This document defines a Third-Party Device Attestation for ACME
   mechanism to allow the ACME CA to delegate some of its authentication
   and authorization functions to a separate trusted entity, to automate
   the issuance of certificates to devices.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 15 Jan 2019 20:13:05 +0200

> https://www.ietf.org/internet-drafts/draft-yusef-acme-3rd-party-device-attestation-00.txt

To me, the mechanism proposed seems to be fundamentially insecure.

WebPKI CAs are forbidden from having any trusted third parties for
domain validation. They are required to do domain validation
themselves. This restriction came (previously trusted third parties
were just required to be audited) after some high-profile incidents
where trusted third parties did some very poor job, and audits (nor
the CA) did not catch that well.

Thinking about domain validation from OAUTH point of view, relaxing
some constraints, and trying to apply existing protocols yields that
one would only need a protocol for device authority to ask the customer
for grant to get a certificate via existing ACME validation methods.

Such thing would be useful when ACME client and the target of the
certificate are privilege-separated from each other.

-Ilari

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 15 Jan 2019 13:58:09 -0500

Thanks Ilari,

Please, see me reply inline...

Regards,
 Rifaat

On Tue, Jan 15, 2019 at 1:13 PM Ilari Liusvaara <[email-masked]>
wrote:

> themselves.

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.

> This restriction came (previously trusted third parties
> The Device Authority has no authority over the Client's domain, so I am
not sure how that would work.
I will take a look at the ACME protocol again to see if this is possible.

Regards,
 Rifaat

---

From: Ryan Sleevi <[email-masked]>
Date: Tue, 15 Jan 2019 14:56:45 -0500

> 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?

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Tue, 15 Jan 2019 15:34:20 -0500

Thanks Ryan,

Please, see my reply inline...

Regards,
 Rifaat

On Tue, Jan 15, 2019 at 2:56 PM Ryan Sleevi <[email-masked]> wrote:

>> The proposed mechanism does not suggest the CA perform a domain
>> validation based on
> Specifically, from reading Section 2.2, I found that a bit confusing, as
> it reads:
>
> Yeah, this is bad wording on my part. I will fix that.

> Is that an accurate read?

Yes, that is correct.

Regards,
 Rifaat