IETF Logo Mail Archive

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 18:58 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 28ECE130F11 for <acme@ietfa.amsl.com>; Tue, 15 Jan 2019 10:58:25 -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 9smZf4lvuYV0 for <acme@ietfa.amsl.com>; Tue, 15 Jan 2019 10:58:22 -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 32ED4130F06 for <acme@ietf.org>; Tue, 15 Jan 2019 10:58:21 -0800 (PST)
Received: by mail-it1-x12d.google.com with SMTP id h193so5870843ita.5 for <acme@ietf.org>; Tue, 15 Jan 2019 10:58:21 -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=dS8Idf9CZqQkDnwqBLvw/ZSH/c8uyinr9LIpWrDMwP4=; b=Gg6hy5AHTcQhJLhKLuLARhrxPEaupCAmku8fUb+1c+eOTILI/l73hM5sYKfpLRpyZ5 gtfY04awfjaSLKRGsADC0lGDWEowljWjwl+krlAKjGpJ4/bS/CDZ/WAbR1bOEElFsApr RWZyZzX3luQ+qadvlFAwIBZuee75bVJPFyOjtZotusyWYz5a1dCS6TWmTBqUU+BOSY1b ww3iHLTtNT9kUIaUgsynwKMKdzL8pCDJTMBeYM0yZmYGo5mCumN4HG8CBay+EPphAvtm xtuwObi8tfCX6zEIMeIwCRtOQvNn7rCApw0UUifFyevwDqU+ncGB5rxSnwo5YDtxANUt x7DA==
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=dS8Idf9CZqQkDnwqBLvw/ZSH/c8uyinr9LIpWrDMwP4=; b=QjbLhW12W1RVcFcpBnoysQLazO4ypt+arfPekn+72t5+Dguyy0GUKaSsghUOzswC3N gQx4O9bmXOYDLqgooNfHiQrpwjM6fuQWJWYav0lNS4P7NSSXNsBqjD55XMQWlukB+xz1 I6MYe8j14HCnKquiqxuVVeYviBqEtw6Y8+vWZJ96I9Pijz0Smcby0hU4csxHB8LmPuwC gYV/x/y6yu7dSLmSmrlDO0Zmy293w5L2/Rj09XGJxO7Q9kdFsSfuazfeB1sc3LwwH2Fg DZZjsbaJlsjRkl4MU54RtuzWA6w3wbcdrkVIwIWyJPQV4OpueVUViTfuXVCCAlfXwmiF FyOQ==
X-Gm-Message-State: AJcUukfQtRxyx3r5FH/V3dmOkPb1SLU8svpxjjcLEmGna82xabrPCpsp wpe2a3TVTK4a5P11nfAr6Qhp4wW542D5+KUpVdc=
X-Google-Smtp-Source: ALg8bN4tokHtJ3naqpF2Of1cDcv9iukfGqYHwq+pXnJQnJsIsnVdt8vDHqYlHgpkfT9ZVUMHKSvaw1ch6pq2YX91zkE=
X-Received: by 2002:a24:cfc1:: with SMTP id y184mr3128855itf.72.1547578701043; Tue, 15 Jan 2019 10:58:21 -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>
In-Reply-To: <20190115181305.GA22841@LK-Perkele-VII>
From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Date: Tue, 15 Jan 2019 13:58:09 -0500
Message-ID: <CAGL6epJpATPOpHWMRqcQQ0fZ1Q=NkZpr1tuS=YCkD+KDdbYBrQ@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: acme@ietf.org
Content-Type: multipart/alternative; boundary="000000000000bcde3d057f83be3f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/4OHJ8vo136LIc81REgpyJW2gpWY>
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 18:58:25 -0000

Thanks Ilari,

Please, see me reply inline...

Regards,
 Rifaat


On Tue, Jan 15, 2019 at 1:13 PM Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Sat, Jan 12, 2019 at 12:38:59PM -0500, Rifaat Shekh-Yusef wrote:
> > 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.
> >
> > ---------- Forwarded message ---------
> >
> > Name:           draft-yusef-acme-3rd-party-device-attestation
> > URL:
> >
> 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.


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



>
> -Ilari
>

v2.23.0 | Report a Bug | By Email