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

Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Tue, 15 January 2019 20:34 UTC

Return-Path: <rifaat.ietf@gmail.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552E6130F0F for <acme@ietfa.amsl.com>; Tue, 15 Jan 2019 12:34:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqRQwe3AnHF3 for <acme@ietfa.amsl.com>; Tue, 15 Jan 2019 12:34:32 -0800 (PST)
Received: from mail-it1-x12d.google.com (mail-it1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD4F81294D0 for <acme@ietf.org>; Tue, 15 Jan 2019 12:34:32 -0800 (PST)
Received: by mail-it1-x12d.google.com with SMTP id h193so6277657ita.5 for <acme@ietf.org>; Tue, 15 Jan 2019 12:34:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JqVdYVHGSu5e0c63tm/Ym5MBmPtpM1tj+0n6Lt9xY2I=; b=lW1Uy0Lx8t0Ej1J0YnfsAp+wWPY861Tl3C86aMRcA0u2CwvY/Y7M41wIRCWA3P1uLY KcWHFPgIjBdjgmeQ+SHnYh9DU3DkQRP5+GlQK9E6m8d4YCkgz3pOfRVuc6+x4jOC9ACX xAejdSB5n7VanwGwtCHFMYnO+yvEtFq3N4QdNKTq+Fsr5FVI6hdt3fcH0MBAFySt2OCH NIpMu/Ol2kc56H1vWGrOv4UxWYreMzDox1pNcoS2KsbNBxn1htMf7FL9f8RrdFoeZDyN DN+S72tuKc0f5Q4cHvIkl32TdoL+a+pCTwrlb0uIKzlk44hKBJonc3vW+FyN5FGaMP+g e+MA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JqVdYVHGSu5e0c63tm/Ym5MBmPtpM1tj+0n6Lt9xY2I=; b=UlnTZFU4MPr24D7t++7vtJ1GQMvtsFwvUE00JaQdZZgub89B147iHuTiAaPYCuWkFF AnJ3wH+LIRDo6GB38JIDE3Kd9e0/4D3u6VBV4MYM24sFNsxSTTKGFIK9YHvN4dtQPgUa Zy//7LAPOdi1tDjaVwNBbRK3UdWwnXi0hfBjgkQLlGQRlCDajT6x8L7Ly4BIv7Gb8H2r AXsJi2YHlxR9VHfbPblfjR6ieodhFGxxMbhloOQOWbEO5dZsbg1X9OmfBjLhDzgbOg1j 9328Jkw6Q3V8IsvFvK6X5+jTcogXEq87KLVvJrJedhvf2XcHVcrP0g/AoMlGYQH88906 TkVw==
X-Gm-Message-State: AJcUukczjB6uTRVF/k1Y/xd3nNBTMSslacbEK3Z6il8ZsWZgfSD1/hUT xZNuyujqcFHQwJCrfju79bZNKk1RmkdV3nphc8edo1fr
X-Google-Smtp-Source: ALg8bN6rIakFRFmKxW8CqeBoUef76iJABLYbwnQBk/voXmdxScX6IjiaAn23dTyCRdQ2FqyDLfsg+Iwezy6ufAtyHms=
X-Received: by 2002:a24:cfc1:: with SMTP id y184mr3357183itf.72.1547584471871; Tue, 15 Jan 2019 12:34:31 -0800 (PST)
MIME-Version: 1.0
References: <154731447787.20477.12913146888480686432.idtracker@ietfa.amsl.com> <CAGL6epJHA-p-4YLU=fc9+vPha12njRoTnAD++1Ai-TqMh0Q2rQ@mail.gmail.com> <20190115181305.GA22841@LK-Perkele-VII> <CAGL6epJpATPOpHWMRqcQQ0fZ1Q=NkZpr1tuS=YCkD+KDdbYBrQ@mail.gmail.com> <CAErg=HHgou91JM14b+s_C4joW_ZiYwL31EZ-SYx3w14oM4HQcg@mail.gmail.com>
In-Reply-To: <CAErg=HHgou91JM14b+s_C4joW_ZiYwL31EZ-SYx3w14oM4HQcg@mail.gmail.com>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Tue, 15 Jan 2019 15:34:20 -0500
Message-ID: <CAGL6ep+P_CXVNM=zdZhLTqDSxYo4Xz+ybges44c6U2vT+Y5eag@mail.gmail.com>
To: Ryan Sleevi <ryan-ietf@sleevi.com>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b4b4bd057f851617"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/BFlvuVGHFGcGVePVLxh268xn_ZM>
Subject: Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-00.txt
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jan 2019 20:34:35 -0000

Thanks Ryan,

Please, see my reply inline...

Regards,
 Rifaat


On Tue, Jan 15, 2019 at 2:56 PM Ryan Sleevi <ryan-ietf@sleevi.com> wrote:

>
>
> On Tue, Jan 15, 2019 at 1:58 PM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
> 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.
>
> Yeah, this is bad wording on my part. I will fix that.



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

Yes, that is correct.

Regards,
 Rifaat