IETF Logo Mail Archive

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

Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Fri, 25 January 2019 13:12 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 D8B73130DF6 for <acme@ietfa.amsl.com>; Fri, 25 Jan 2019 05:12:24 -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 Lur8S-isH7pi for <acme@ietfa.amsl.com>; Fri, 25 Jan 2019 05:12:22 -0800 (PST)
Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (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 77628130DEF for <acme@ietf.org>; Fri, 25 Jan 2019 05:12:22 -0800 (PST)
Received: by mail-io1-xd2e.google.com with SMTP id b16so7715339ior.1 for <acme@ietf.org>; Fri, 25 Jan 2019 05:12:22 -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=81bPNTsbQ5f/TAn+HhlkOCv0fjvjUbpnsAs1AppLphQ=; b=hOTEPZXODLmlR/sbdDJZx+D8w4KwHElm7Fd1rWUELS7uGE3gp9xPIZlo7OEx43b/Ck 8fnagWbtk/tyn1HSdTGOTloBC9/RMx8UjXiCzE4BjmJfrASaxjmxoiX4vX4QM1gUCKEe 69vWLmN6MdHfPA5reJp3CCNVdOjHJuCOcctMhZTzDE2sigi1Y/t8rrvtD3q/RpS3wGbz 6yo8GOkg/9ttvOHwwZAuEQ7BQRWkWLqLmNFcpHZcsB+amgluiW6ezJC8teqgioBP3Mh2 tJRxqkBbVR6stdF+q9QMPopvw7IbZBc9P9IC/URF4WZOzLJZ1K9OqZYNpSVRoKN+AIvo i9Yg==
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=81bPNTsbQ5f/TAn+HhlkOCv0fjvjUbpnsAs1AppLphQ=; b=ekgNezq9QWJGu09l8CkmSNc2xmh+54RNe7PqU2+v/16BLXexMkqO6UUO8lc3gnl9C2 G8N3sn36vg57MB/MbeVVjffWjt6O6ZywInMoTs7FkPnQY/CsO8fvboMu/bvnMLZBsu82 tFiT93N/n6jJVfarFH3uPTFcuvwhsAwx0SCKFETL3F26FyEVt5q3QovF8QhPngJW3U3h z0OX8lhOG+cI8DdaE8C31dtouyRrLDqwwA4GREjY2UOw6Ea9e5C0AS6zcoDVCy8nS1Y3 aiUlNnGpropDmuyJxE3lEpZfQIAgQsDvAFf+MsVvpVB8D6IOVte7QuB0GQKCUZJHO4gg iRBQ==
X-Gm-Message-State: AJcUuke2+5/TPpnL0fCYlx1PnU/WJbbZkI8A8++MK2AYOtkJ8YnU96gG sHm9yvkLyYpuEV3ANlJxovi73s8DlcqQUeY7js6aKhC8qbQ=
X-Google-Smtp-Source: AHgI3IaavXOgGPWRyXC9SUMpcLA23XVpei8FnYCe59+lPK17kQsKZLwcV3QHsONTCyMpx7HFkAUogTYV8DCKp6qz9MQ=
X-Received: by 2002:a5d:904b:: with SMTP id v11mr7050976ioq.0.1548421941756; Fri, 25 Jan 2019 05:12:21 -0800 (PST)
MIME-Version: 1.0
References: <154767050457.29430.8305250740505088239.idtracker@ietfa.amsl.com> <CAGL6epJ6cVBSp_VWPbV9+kG7VGBp_mPPf_Q836cbf5bi8OY=hQ@mail.gmail.com> <CAL02cgQXYxqvi5q4iW8uhRkbsYG1UObQkb094ba1wFvw4dcy8Q@mail.gmail.com> <CAGL6epJX+dSb9fK7E8fagwROesL7DF_3KJhF0nB=TTqdcpi-cA@mail.gmail.com> <CAL02cgRx7SOYSmzCo8cLdz08U2Y=_KtjSe3Zha3GhFjQsYgW5Q@mail.gmail.com> <CAGL6epLpBCqyBbvSpZb41xOgOwy6TBobK_hHZ+SdSWAFjvuyKQ@mail.gmail.com> <ME1PR01MB07711AB21EFE888468CA571EE59B0@ME1PR01MB0771.ausprd01.prod.outlook.com> <CAGL6ep+AM_1APY2fCgGkLgJ-dXnfxYU7gtwmQ_P8higW5h1Vkg@mail.gmail.com>
In-Reply-To: <CAGL6ep+AM_1APY2fCgGkLgJ-dXnfxYU7gtwmQ_P8higW5h1Vkg@mail.gmail.com>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Fri, 25 Jan 2019 08:12:10 -0500
Message-ID: <CAGL6epKph4qGhxV0xXq3cgSkFvOLWh5=SgQJOm-O7YSf-yTW7A@mail.gmail.com>
To: "Manger, James" <James.H.Manger@team.telstra.com>
Cc: IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cd0b5505804813a3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/3XsfwrBOB3LD-XFpfs257IAQeGI>
Subject: Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.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: Fri, 25 Jan 2019 13:12:25 -0000

James,

"That way the ACME CA doesn’t need to know anything about the device
attestation."


No, the ACME CA would need to validate the JWT provided by the Device
Authority.

Regards,
 Rifaat


On Fri, Jan 25, 2019 at 8:06 AM Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
wrote:

> 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 <
> James.H.Manger@team.telstra.com> 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
>>
>> +61 4 1754 1870
>>
>

v2.23.0 | Report a Bug | By Email