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

Richard Barnes <> Thu, 17 January 2019 06:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4AC5130DBE for <>; Wed, 16 Jan 2019 22:51:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.041
X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FMSuo0_pxY94 for <>; Wed, 16 Jan 2019 22:51:49 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD43D126DBF for <>; Wed, 16 Jan 2019 22:51:48 -0800 (PST)
Received: by with SMTP id a11so10157490otr.10 for <>; Wed, 16 Jan 2019 22:51:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FC3ouL5lge8rqx7cs4MdIfCnaT/ml5qxfTXwgjgj/mI=; b=GxJ1IclVikCJLxirNydfI1hQyRctYMTCrspEx5i2A9BMBSKpjFBuqGPruL68VbkEf5 DcCsJ/sbQLqnwozgGrEJngPtTs7SESH+frwjYclXgx2PJqeU5oxtCdiPS0K29RiOmGGi /bhL4TM//gCFbTtpz2XtqbRXNx5NoRvKx/l4q72oCyw03aumuSRvJS9XKphkyQmOK+f9 vTq5KzY/WC54MWEkz4lePdjXx9ayqULT5QisMBDi5mRSseG/iQwimlbctIXuhWCXRvzL SuQ9gvBwwutwBbKk4VzKVfgBjnFm1fuWLKirkCtrk1wTQmsE88s+UUFv38NMPmPP9i8V G9dQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FC3ouL5lge8rqx7cs4MdIfCnaT/ml5qxfTXwgjgj/mI=; b=EkYceLZJ9MjpbFFIGVBb0jRtNQe3zQezU2UZvk64FSccH8zVgc/B+8Je8tqkizaKHK R95IyfQ/PwL0ibLLFppp1TKQBIpLrmwABb4dokYsSAZXse/azcmf6Kng0tB7NnKbYhrh 70cPvzX6mo4E56LEKL6BesyVbRySCKhOXRpHe7imC6OVBDFMVxhTm8BHtJLD8l3Osm5a Cvgsil0BzC++iv2JyX5CsOKmppSRlqS3tmMqlfv+W+oB/lF+LNq2LRWOtUKZrr3GXKrF wWUGf8o6yVqV8ddgTyYa4LRZGie+kMB5rxqyOZCHGXZpKXvkyRMwZl4aHVG4kcj4BpLK d6qg==
X-Gm-Message-State: AJcUukdY71+UavrmZA8leAV2WSPK0018F+18cxCGEgg/QP8C1XceiL0m jJYP26x2XhAm/64tJh/ImRzUg/7InfG2PQANkuvC7cHHerw=
X-Google-Smtp-Source: ALg8bN57k2AykMxQzDFg3a9z3bugeKxoarw43PbPlH6KCTg3Gd6g/Anwz5fA9toEDWN0vrlSFph7CKSWHAGXW+S0KuY=
X-Received: by 2002:a9d:191a:: with SMTP id j26mr8402570ota.81.1547707907859; Wed, 16 Jan 2019 22:51:47 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Richard Barnes <>
Date: Wed, 16 Jan 2019 22:51:15 -0800
Message-ID: <>
To: Rifaat Shekh-Yusef <>
Content-Type: multipart/alternative; boundary="000000000000107f8e057fa1d4af"
Archived-At: <>
Subject: Re: [Acme] Fwd: New Version Notification for draft-yusef-acme-3rd-party-device-attestation-01.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Jan 2019 06:51:52 -0000

It seems like the core of this draft is identifier delegation.  Namely, the
CA recognizes the DA as an authority for a certain identifier space (e.g.,
the first few octets of a MAC address), and the JWT delegates permission to
issue certificates for some identifier in that space to the Client.

Given that, it seems to me like this could fit under the rubric of the
"authority token" challenge.  If you were to do what this draft wants to do
with that framework, the Client would have two separate interactions -- an
OAuth interaction with the DA to get a token, then an ACME interaction with
the CA to issue the certificate.  The only specification needed would be to
specify the identifier and token type, as has been done for TNAuthList [2].

The only thing that would then be missing with regard to this draft is that
the CA wouldn't provide the redirect to the DA.  Whether that makes sense
depends on the use case, but I suspect that in most cases it does not.  The
design in the draft presumes there's a single DA per identifier, and that
the CA keeps a mapping table from possible identifiers to DAs.  That seems
unlikely for most identifier spaces and most CAs with reasonably broad
coverage.  So losing this property of the draft doesn't seem like a big

So net/net, I think this draft should be restructured along the lines of
[2], to just define a token type and maybe an identifier type.



On Wed, Jan 16, 2019 at 12:33 PM Rifaat Shekh-Yusef <>

> 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.
> Regards,
>  Rifaat
> ---------- Forwarded message ---------
> From: <>
> Date: Wed, Jan 16, 2019 at 3:28 PM
> Subject: New Version Notification for
> draft-yusef-acme-3rd-party-device-attestation-01.txt
> To: Rifaat Shekh-Yusef <>
> A new version of I-D, draft-yusef-acme-3rd-party-device-attestation-01.txt
> has been successfully submitted by Rifaat Shekh-Yusef and posted to the
> IETF repository.
> Name:           draft-yusef-acme-3rd-party-device-attestation
> Revision:       01
> Title:          Third-Party Device Attestation for ACME
> Document date:  2019-01-16
> Group:          Individual Submission
> Pages:          9
> URL:
> Status:
> Htmlized:
> Htmlized:
> Diff:
> 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
> The IETF Secretariat
> _______________________________________________
> Acme mailing list