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> Thu, 17 January 2019 02:03 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 691F1126CB6 for <acme@ietfa.amsl.com>; Wed, 16 Jan 2019 18:03:06 -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 i_MdUquNSZxh for <acme@ietfa.amsl.com>; Wed, 16 Jan 2019 18:03:04 -0800 (PST)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 4AC09130F12 for <acme@ietf.org>; Wed, 16 Jan 2019 18:03:01 -0800 (PST)
Received: by mail-io1-xd2c.google.com with SMTP id r200so6532596iod.11 for <acme@ietf.org>; Wed, 16 Jan 2019 18:03:01 -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=r0DqPVHH3LqfJw82Y/iVuIwBJcjDwhUzVkaUS3l6010=; b=UitzO9hQ8i0piaivu9PXs4eZ/G/kYGrO40LoEVmnZLQG7RrsPeFVdpIjCbbclCkmQg P7frBpQnfxtlH/iC0nMTnveLKWSkxDMRzTwDiQ8jRPLOSRI7SqSADAs0uZvI8J+HN18T LDxiolDCfkAjXnTFjtUYA3C7UYE/j6Tp3jUl2jypTAkZzMplOhNv+bwmYVLMaI7eRQXZ ehin3KeCUEpYqHFRTZTNVcjGRMq3wucz53tDKOBUM5H7qnPO2xcFjKe92gFH4nTf6kqG FZTIfXcuSI6VsMiJG7z8RX4Li9MEJjFaUlEYkRX8kJw4a7PK3fC91Mf6C7cHgOayan4+ pr8g==
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=r0DqPVHH3LqfJw82Y/iVuIwBJcjDwhUzVkaUS3l6010=; b=lBAMkBURrqOtifOa1rzEU7suNm9qmnL3pXUfbuGyyOH80JVbcp8c7TKg/cgVxvGgQx aX6OD8fVsZSwsk/y8MwIntSf7cbnPTDcorUEZHob0p/zJDPRQPdYXu9vmC8B+Q18N9Dh 1NtCKaCuxYkTCa/xXkqJqnY1V84OpI2X4oAMYZ4h+KeboRUL97SLwDjQzaqYqZLh3X13 zsCs3/dSMVhmUf4KBrhpWMT4xnk+2LAEjKs3xAp3kU39qohb7m9EwfunULChCnmOM+na ryOQ1Y5GQMj4ZgQ6jerPZIrxlo8fMqugrm33gwdiOOmZ82Pxh7RLkZ9XaPE288iLYqLP Hr8g==
X-Gm-Message-State: AJcUukdBTYm94agUkP48ikl1GfTH+QmJgpAh7dPBCVJ41c4MRNtUg7LB 8Wpnb2x6GPxT++iLcYNsMmilIUhWd4OeP2iok+aAji2AUTQ=
X-Google-Smtp-Source: ALg8bN4dZexSX5ycrAg9Q/DAPrn4wwjGpLM3eBJdBMaTIXZwZv2VRdyfq9d6QpHYA0lA5DFHlWSBHQB6nyC+ajY/VgE=
X-Received: by 2002:a5d:9913:: with SMTP id x19mr5634921iol.99.1547690580602; Wed, 16 Jan 2019 18:03:00 -0800 (PST)
MIME-Version: 1.0
References: <154767050457.29430.8305250740505088239.idtracker@ietfa.amsl.com> <CAGL6epJ6cVBSp_VWPbV9+kG7VGBp_mPPf_Q836cbf5bi8OY=hQ@mail.gmail.com> <20190116211522.GA7547@LK-Perkele-VII>
In-Reply-To: <20190116211522.GA7547@LK-Perkele-VII>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Wed, 16 Jan 2019 21:02:49 -0500
Message-ID: <CAGL6epKasNKJC-AKcFBxV4Tv-wTcMLpyyEygPfT1hsBy6aOHHw@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000477262057f9dcbb6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/UlR63Io_ou3w9jcoTI2Q9pfaXyg>
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: Thu, 17 Jan 2019 02:03:06 -0000

Thanks Ilari,

Section 2.4 is a informative section that meant to provide a high level
view of the full flow.

Remember that the assumption is that the Client already has an account with
ACME and already proved it controls customer.com domain.

The first request in this flow will be the same as defined in section 7.4
in the acme draft:
https://tools.ietf.org/html/draft-ietf-acme-acme-18#section-7.4
The only difference is that the url will contain the new order with the
vendor.com to indicate that it is requesting a certificate for a device
controlled by this Device Authority.

Hope this helps.
I will try to expand on this in the next version of the document.

Regards,
 Rifaat






On Wed, Jan 16, 2019 at 4:15 PM Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Wed, Jan 16, 2019 at 03:32:57PM -0500, Rifaat Shekh-Yusef wrote:
> > All,
> >
> > I have just submitted new updated version to address the issues raised by
> > Ilari and Ryan.
> > I would appreciate any more reviews and comments.
> >
> > ---------- Forwarded message ---------
> > Name:           draft-yusef-acme-3rd-party-device-attestation
> > Revision:       01
> >
> https://www.ietf.org/internet-drafts/draft-yusef-acme-3rd-party-device-attestation-01.txt
>
> Other comments:
>
> - How the ACME server can look up the client account with kid field
>   (which normally contains the client account identifier) now contains
>   the client domain?
> - URL field in first request seems to be also overloaded. Considering
>   that this field actually has security significance (prevent misrouting
>   to different resource), this seems questionable.
> - Constructing URL poiting to the client without knowledge of used paths
>   is very questionable.
> - It seems to me that this should be handled by defining a new validation
>   method for the mac identifiers, without touching rest of ACME. Then
>   the CA would send those back for mac identifiers (together with the
>   needed references) and then take the JWT as reply.
>
>
> -Ilari
>

v2.23.0 | Report a Bug | By Email