IETF Logo Mail Archive

Re: [Rats] [Acme] device attestation and ACME

Brandon Weeks <bweeks@google.com> Thu, 21 July 2022 22:57 UTC

Return-Path: <bweeks@google.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB4BC13C224 for <rats@ietfa.amsl.com>; Thu, 21 Jul 2022 15:57:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.61
X-Spam-Level:
X-Spam-Status: No, score=-17.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZhODq_jWEBR for <rats@ietfa.amsl.com>; Thu, 21 Jul 2022 15:57:01 -0700 (PDT)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF19C13C218 for <rats@ietf.org>; Thu, 21 Jul 2022 15:55:59 -0700 (PDT)
Received: by mail-wm1-x32d.google.com with SMTP id c22so1834004wmr.2 for <rats@ietf.org>; Thu, 21 Jul 2022 15:55:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8Aje0oLJtfpWdRNmx+Q0hAHujW/zYTGOV9DmBvEELs0=; b=CL5C/MvsSII2YFnY+3/0xmXOOod9bRCMUJuh6lzREcB0FDpMMrncX9nV71AgHjzuQo oc3x4J85E6ycmvRtpNL3se0ulGSk7UhLdsU4iqEy2DaZnBSFpDW8gLaKhTKfeaP7SejA DNbVdJz72vulK45k7UYOmCUVMix6j/ozA2RQbds7bV0KE3/FU+sGJc1tORdf4xFq1U3/ zIAxxHf8Z7It2GWYCVsY9Rwa2zUjIbXCIO3UqLzCausisYdmTyqwoVr1gzHq+AH1k5Bl nOC10cNlOi61bTQicDSWnp6XD/IRwQHwDbiHKm7UsOJ1x2zTb/FJIXfnpB9PogkMga/y 2AvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8Aje0oLJtfpWdRNmx+Q0hAHujW/zYTGOV9DmBvEELs0=; b=JoCnIhh4V+EAlbKZ/EPC9ta0g2NBCqY1aKquUuigspsimKxslve6+zLvUY/0HWdmG+ hz3ndEc6xZBfgnQgSrIFe84pdxd1KiWGF8BPJnGut4NyT7b0hwMxP2fJy395cI1TUZsq ++UIF7SIBIqYqyk0u6slbGJfGIJIS6IWcaJBC3x3FAQNrXY3FG4//7EVRmOKdj/tvUG2 d9j6KkIizwBG0hw2bENQBqAM/J4MlvIsuSN1SGbbpRwRUthmGvdZjHpFyD6tGgmbBTOG 3l4dyq4xpI7oAH7bWix+EPVQbgcBnH1EtdZ45U9kpldrA4XiBGM3shzw7eKivnj0bV/y GhZQ==
X-Gm-Message-State: AJIora85953463OnJ5x/Isl15kyGxMREFLUfk+CXd8peEWuKmQhpBo+q TvyTaLxEtGcMCwGVaO7rKvR7nMfN3gEuhYP19p5vt89yGQEUVA==
X-Google-Smtp-Source: AGRyM1v/d6T0j3VSG9lPIsaoKlikq40AdvXfKGdy4q6WaZndb34ETTOUmRXIqaR9kOvX18QnpTOXEgjqoHbr4cIARHA=
X-Received: by 2002:a05:600c:3044:b0:3a3:f60:c907 with SMTP id n4-20020a05600c304400b003a30f60c907mr9622639wmh.19.1658444157636; Thu, 21 Jul 2022 15:55:57 -0700 (PDT)
MIME-Version: 1.0
References: <1680731.1658356904@dooku> <B950BEDF-DF18-4AF0-95A1-0EF3C0A9EA6A@redhoundsoftware.com>
In-Reply-To: <B950BEDF-DF18-4AF0-95A1-0EF3C0A9EA6A@redhoundsoftware.com>
From: Brandon Weeks <bweeks@google.com>
Date: Thu, 21 Jul 2022 15:55:46 -0700
Message-ID: <CAP+ZhPbVuMYgtz5TW801fxm44UwgFNOeiFctVhfe9rSF9d7-DA@mail.gmail.com>
To: Carl Wallace <carl@redhoundsoftware.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, rats@ietf.org, acme@ietf.org
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000ebde4a05e4589e45"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/df5w0_Nkj37P3lJBCcBpEN32pD4>
Subject: Re: [Rats] [Acme] device attestation and ACME
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jul 2022 22:57:05 -0000

Unfortunately each attestation format has a different method of
verifying the trust relationship of the attestation certificates.

- Android Key Attestation: Android publishes the root certificates
that all valid attestation certificates chain up to.
  - https://developer.android.com/training/articles/security-key-attestation#root_certificate
- Apple Managed Device Attestation: follows a similar pattern of
Android, the attestation certificates chain up to a well-known root.
- Chrome OS: there is only a web API for verifying challenges, there
is no way to do offline verification.
  - https://developers.google.com/chrome/verified-access/developer-guide#how_to_verify_user_and_device
- TPM: an enterprise would manually curate a collection of trusted
Endorsement Key certificate roots or use Microsoft's curated
collection.
  - https://go.microsoft.com/fwlink/?linkid=2097925

Since platform vendors define the verification procedures and can
change the procedure or the trusted roots at any time, I'm not sure
the best place to either specify or informatively reference the
verification procedures.

On Wed, Jul 20, 2022 at 4:07 PM Carl Wallace <carl@redhoundsoftware.com> wrote:
>
> Distributing trust anchors to verify device attestations is one of the aims of https://datatracker.ietf.org/doc/html/draft-wallace-rats-concise-ta-stores-00. Note, there's also a LAMPS draft that borrows the WebAuthn format approach from this ACME device attestation draft but for use in extensions suitable for CMP, EST, SCEP, etc.
>
> On 7/20/22, 6:41 PM, "RATS on behalf of Michael Richardson" <rats-bounces@ietf.org on behalf of mcr+ietf@sandelman.ca> wrote:
>
>
>     I read acme-device-attest, and I guess the key part is a new device-attest-01
>     method.
>
>     https://www.ietf.org/archive/id/draft-bweeks-acme-device-attest-00.html#name-device-attestation-challeng
>
>     tries to explain the format, and how the challenge is signed by the device.
>     What I do not understand is any of the trust relationships between the ACME
>     server and the manufacturer/provisionor of the Android Key Attestation/Chrome
>     OS Verified Access/Trusted Platform Module.
>
>     Why does the Enterprise trust the attestation key?
>
>     --
>     Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>      -= IPv6 IoT consulting =-
>
>
>
>     _______________________________________________
>     RATS mailing list
>     RATS@ietf.org
>     https://www.ietf.org/mailman/listinfo/rats
>
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme

v2.23.0 | Report a Bug | By Email