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

Carl Wallace <carl@redhoundsoftware.com> Thu, 21 July 2022 23:33 UTC

Return-Path: <carl@redhoundsoftware.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 F08D0C14F739 for <rats@ietfa.amsl.com>; Thu, 21 Jul 2022 16:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MIME_QP_LONG_LINE=0.001, 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.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 MJrE7UgZcsd1 for <rats@ietfa.amsl.com>; Thu, 21 Jul 2022 16:33:51 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 08286C14F725 for <rats@ietf.org>; Thu, 21 Jul 2022 16:33:50 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id v28so2517885qkg.13 for <rats@ietf.org>; Thu, 21 Jul 2022 16:33:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=8x1qfl94rBE94tBUSV1tnFHnpFP+I7G5GPy8xLGPwSA=; b=YbKo80ndhqR02z0A3DR1kteyovd2FGRni4CbSX+TnHn2hPYXR5tobNcAFXNNLRQn5i TikBh9M9jyN68v7XUGBeaFiA9nPqifqT9DyY8b8keQgJhwFdeY2eZazQPHeZVPUA3qlG pdcLBGsei9sMUdQhsDCK6AJ2AsZSxQ6jcb3+M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=8x1qfl94rBE94tBUSV1tnFHnpFP+I7G5GPy8xLGPwSA=; b=7OulSdczH2Z8eXympDx2iWSAvuRW6rVw610di78JB5JJ+kEWxu7xRkYtbRO7cOgb1u cdVeEgg/dx8zLH0vt7FD/8Pqd4CfBFIH/PvyKzNSRNm7zIQLVhXuEBIVQQBTBgR8USWT kZ5FnmSX1RIUy5gkmGHmucrgnuLnt/ujDLDyvJpMD7m6p92MmgP3KvwkjpnLod7yJSSQ VrQzSquOVWjiEaBq6S2p2mz5jBd3/K70Ltea+Fk4pFiShfhmWnxWep8m260vdnMvOWT8 GVZATCXKcRHzJxxeiFLjaE5r3rBgmeiEMR1fjVmTTqz3fwC4G1Db0Sba5RoMB59slXSw 40lg==
X-Gm-Message-State: AJIora+hvjj7bqRzrkP7TToKNcV2bP49LAvO5kZI8Ws4blB8/H6Gu672 wFE6E5ShhmJlRa2TASKq+EiTaUHYaOOhSQ==
X-Google-Smtp-Source: AGRyM1v/EomAeApwxVfYnWjvAhx8rSk+ocSlHdkrES+ouxXo4M/RJ8iApAJzLMk/MH2yBoFlZ65qig==
X-Received: by 2002:a05:620a:2912:b0:6b5:e5b0:3dcf with SMTP id m18-20020a05620a291200b006b5e5b03dcfmr728249qkp.506.1658446429647; Thu, 21 Jul 2022 16:33:49 -0700 (PDT)
Received: from [192.168.2.16] (pool-173-66-83-240.washdc.fios.verizon.net. [173.66.83.240]) by smtp.gmail.com with ESMTPSA id do23-20020a05620a2b1700b006a758ce2ae1sm2546982qkb.104.2022.07.21.16.33.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Jul 2022 16:33:48 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.63.22070801
Date: Thu, 21 Jul 2022 19:33:48 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Brandon Weeks <bweeks@google.com>
CC: Michael Richardson <mcr+ietf@sandelman.ca>, rats@ietf.org, acme@ietf.org
Message-ID: <123AAE3A-F62A-454C-A544-475DDEB0047E@redhoundsoftware.com>
Thread-Topic: [Acme] [Rats] device attestation and ACME
References: <1680731.1658356904@dooku> <B950BEDF-DF18-4AF0-95A1-0EF3C0A9EA6A@redhoundsoftware.com> <CAP+ZhPbVuMYgtz5TW801fxm44UwgFNOeiFctVhfe9rSF9d7-DA@mail.gmail.com>
In-Reply-To: <CAP+ZhPbVuMYgtz5TW801fxm44UwgFNOeiFctVhfe9rSF9d7-DA@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/rS3lTSXieghBaOU28OIx5utj8MA>
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 23:33:55 -0000

Platform vendors can and do change things (including formats) at any time. Any verification procedures should be described in a reference identified in the registry (ideally with some words about sources for trust anchors).

The approach in the concise-ta-stores spec is similar to how TAs are handled in the FIDO metadata syntax spec. In the FIDO spec, TAs can be looked up by an authenticator ID. In the proposed spec, it's a more open environment definition because there is not as narrow a target as in the FIDO case, but it can be used to a similar end targeting vendor/product. In a CA I supported that has verified key attestations during certificate enrollment since 2018, we had a separate TA store per supported attestation type, with the stores manually updated as needed. The proposal manages a set of TA stores in an array, so different TA store elements in the array could address different attestation types, for example. There's nothing in the proposal re: distribution mechanism, frequency, etc.

On 7/21/22, 6:55 PM, "Brandon Weeks" <bweeks@google.com> wrote:

    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