Re: [Acme] [EXTERNAL] Re: acme-device-attest expired

Brandon Weeks <bweeks@google.com> Tue, 19 March 2024 01:01 UTC

Return-Path: <bweeks@google.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 07E69C14F5FE for <acme@ietfa.amsl.com>; Mon, 18 Mar 2024 18:01:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.608
X-Spam-Level:
X-Spam-Status: No, score=-17.608 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 Q2UC-5eiFgVu for <acme@ietfa.amsl.com>; Mon, 18 Mar 2024 18:01:18 -0700 (PDT)
Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (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 BDA92C14F60F for <acme@ietf.org>; Mon, 18 Mar 2024 18:01:18 -0700 (PDT)
Received: by mail-qv1-xf34.google.com with SMTP id 6a1803df08f44-69145fc4265so34569976d6.1 for <acme@ietf.org>; Mon, 18 Mar 2024 18:01:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1710810077; x=1711414877; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ozAReJRX0nXZLVzjSs27OdsW6w+4htvxQtToN/p4/oU=; b=aZE/aS7o+6eLSRIPOKmifa32aS5L6aX103q5TZIe4cKKHSNKFC8a0uK+JApW9XKMOK amoNEksovkt+NpPzjjwJfhxY0FWv6qppZbjD73Saj6Fq/k5jAMJL8lzWJBULF/VImYvY OhuzqZ1dSVZlOG/y0CAHgvJXA+sLAxiztb3zSL+xAmWA4oo98Ug9z34t3tMKipj44y0C /l3JtM9xxImDsyJLXj6xOFUStQ//fgKBZwXGt1ObztS9OoLKwuoRs0JtjlOS0ELQqb5Y 7RLiuwBKxie7vZFrESWuW2n2L8Au9FGU5cju69NbXfTSNmbd2cuSMJd7di/RFz1K4AI0 BDHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710810077; x=1711414877; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ozAReJRX0nXZLVzjSs27OdsW6w+4htvxQtToN/p4/oU=; b=aF1Vyfk4T9wFjgPwibVTAhiXAQaQWaIKiIjN9YtK/tf2j67Fjt79qKlh165kj4FISh K8Pu+rHWKureh6+HsDDC6l9jnmJHywXn5aiWHB2lk+0y9UpE6ccBC9mgHR7XoAWJo/UX SkfAPMnP9+cewsmUcKxg/Ut/w54OL+CJHJeGFYbPULCmAiRVzKdIivo8ni0SRYEqaTaM 3nRORBSfT1WFDXp7Bv5SdSVwAVYxyZN2CK1GNsjGOVefswp7QaLzWfzurg1vBfRJHVoI UYb4bt1wb8BdRz3VnHL1WcYb47bVUn18mlJbG0V5jymg3ijtysdeelKXURFr3eDMhS9h /l/A==
X-Forwarded-Encrypted: i=1; AJvYcCUcHMjoBqrapBXYFrUnvimmhz2fNwXiB6YHwXqkgywm0kwp3l5J1EbnxRleGI0UmxVgkmFKOQU75QylqOUO
X-Gm-Message-State: AOJu0Yxxua9avMYB6qnYOiSXMN+IJjSQgJPyAZURTzE2hfHQyn23ctGI NbCBe9L7QvybgjbG3/Qmny8Cu1FaFU+Q0+KLwUZHDdKFQUE8rWCXaV47hRcEqBnyDcNbcUSWNwN UpylTip2kdhjxq8N1qNg1m9SidW1cb8BGQm1e
X-Google-Smtp-Source: AGHT+IG2dxwJcgxHO4M2jlmAwKwg7UvX0DrP0jwTFkNPJwsQNeWRpjTh5biV7MS+L6ECE9MRjwkJIfWUGgCxhtVzVzk=
X-Received: by 2002:a0c:f88c:0:b0:691:8924:79f1 with SMTP id u12-20020a0cf88c000000b00691892479f1mr989469qvn.11.1710810077205; Mon, 18 Mar 2024 18:01:17 -0700 (PDT)
MIME-Version: 1.0
References: <CAObGJnMnuZu6St4zZT27jgq6OnR6aSdCUy9RS_m-C0Fv1ta-nQ@mail.gmail.com> <CAA1-vB3tom_rEqSc+P7oQfNeYvKwPdp8mzVNKZrj+QSTW6tiAQ@mail.gmail.com> <CAGgd1Oe0U=WQPsgYQ76X4-bTkesPAd4ezPzLPEJf=gYO-qmLNQ@mail.gmail.com> <CAA1-vB184w6DVaxrD1dZCcaTJc9W_1D6Jv-cBGp1sVcZvDckiQ@mail.gmail.com> <CH0PR11MB5739186FCEF7D97A61D47EDD9F562@CH0PR11MB5739.namprd11.prod.outlook.com> <CAOEiZmHyrZZD3jqQtdNiYyxkLeCYjELRf4Mb5dhk2_m5Cnh2Tw@mail.gmail.com> <CAA1-vB0FAjjZ8qZCSw=+jnex4p_kM=LPYaWR1XMBGQZ_U-BAiQ@mail.gmail.com> <CAP+ZhPb3t9+BpV5HEWwJFMxAfvw2HRa3=XL9kQvG8EJGq4aY9g@mail.gmail.com> <CH0PR11MB5739D31D3FE472A6B9ED38869F552@CH0PR11MB5739.namprd11.prod.outlook.com> <CH0PR11MB5739A0BE8758D8B08B2D0F699F552@CH0PR11MB5739.namprd11.prod.outlook.com>
In-Reply-To: <CH0PR11MB5739A0BE8758D8B08B2D0F699F552@CH0PR11MB5739.namprd11.prod.outlook.com>
From: Brandon Weeks <bweeks@google.com>
Date: Mon, 18 Mar 2024 18:00:58 -0700
Message-ID: <CAP+ZhPbt2DcEOUZ1YuUkFM_ZebgKfFaz1WbTeG13enCm77Cb3Q@mail.gmail.com>
To: Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org>
Cc: Prachi Jain <prachi.jain1288@gmail.com>, Mike Malone <mike@smallstep.com>, Deb Cooley <debcooley1@gmail.com>, Thomas Fossati <tho.ietf@gmail.com>, "acme@ietf.org" <acme@ietf.org>, "draft-acme-device-attest.authors@ietf.org" <draft-acme-device-attest.authors@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000f6a3a60613f902c5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/fEVCbIoaaSjIp2p_lQH6sGy1sPQ>
Subject: Re: [Acme] [EXTERNAL] Re: acme-device-attest expired
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.39
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, 19 Mar 2024 01:01:23 -0000

My goal for draft-acme-device-attest is to provide a relatively simple
method for issuing client certificates using the attestation schemes
and formats that exist today. Making "attObj" generic explodes the
complexity of implementing the draft.

I assume that this document will be supplanted by the RATS
architecture (and future ACME extensions) once platform vendors have
adopted it.

On Fri, Feb 23, 2024 at 9:56 AM Mike Ounsworth
<Mike.Ounsworth=40entrust.com@dmarc.ietf.org> wrote:
>
> @Brandon Weeks – I wonder if acme-device-attest-01 could be broadened so that “attObj” is allowed to contain evidence other than WebAuthn – ie make WebAuthn an example rather than normative? I would suggest listing “EvidenceBundles” from draft-ietf-lamps-csr-attestation, and RATS ConceptualMessageWrapper from draft-ietf-rats-msg-wrap as other valid examples.
>
>
>
> ---
>
> Mike Ounsworth
>
>
>
> From: Mike Ounsworth
> Sent: Friday, February 23, 2024 11:48 AM
> To: Brandon Weeks <bweeks=40google.com@dmarc.ietf.org>; Prachi Jain <prachi.jain1288@gmail.com>
> Cc: Mike Malone <mike@smallstep.com>; Deb Cooley <debcooley1@gmail.com>; Thomas Fossati <tho.ietf@gmail.com>; acme@ietf.org; draft-acme-device-attest.authors@ietf.org
> Subject: RE: [Acme] [EXTERNAL] Re: acme-device-attest expired
>
>
>
> Here’s my 5-minute side-by-side of the two drafts.
>
>
>
> draft-ietf-lamps-csr-attestation:
>
>
>
> - whatever evidence blob your device can produce, stick it as an OCTET STRING (or whatever other ASN.1 type) inside a new CSR attribute called id-aa-evidence.
>
> - Any cert chains required to validate the evidence blob also go inside id-aa-evidence.
>
> - It’s the CA’s job to find a verifier that can parse whatever evidence data you gave it.
>
> - Was written under the full generality of the RATS Architecture.
>
>
>
>
>
>
>
> draft-acme-device-attest:
>
>
>
> - Defines new SANs for use in CSRs: “permanent-identifier” and “hardware-module”.
>
> - Defines a new ACME Challenge “device-attest-01”
>
> - Expects the returned Evidence data to be in WebAuthn format.
>
> "payload": base64url({
>
>     "attObj": base64url(/* WebAuthn attestation object */)
>
> - Was written specifically for Android, Chrome, and TPM attestations in WebAuthn format.
>
>
>
>
>
>
>
> My first impression is that we should continue with both in parallel and not try to combine them.
>
>
>
> lamps-csr-attest is more general in that it applies to things that are not WebAuthn, and will work anywhere that accepts CSRs.
>
> acme-attest allows the client to send a cert req, and then the CA to decide whether or not to challenge for an attestation. It also has invested implementors.
>
>
>
> ---
>
> Mike Ounsworth
>
>
>
> From: Brandon Weeks <bweeks=40google.com@dmarc.ietf.org>
> Sent: Thursday, February 22, 2024 4:25 PM
> To: Prachi Jain <prachi.jain1288@gmail.com>
> Cc: Mike Malone <mike@smallstep.com>; Mike Ounsworth <Mike.Ounsworth@entrust.com>; Deb Cooley <debcooley1@gmail.com>; Thomas Fossati <tho.ietf@gmail.com>; acme@ietf.org; draft-acme-device-attest.authors@ietf.org
> Subject: Re: [Acme] [EXTERNAL] Re: acme-device-attest expired
>
>
>
> Apologies for letting the draft expire. I've recently switched roles within Google and have been busy ramping up. My new team is responsible for Android Key Attestation[0], one of the attestation schemes included in the draft, which hopefully
>
> Apologies for letting the draft expire. I've recently switched roles
>
> within Google and have been busy ramping up. My new team is
>
> responsible for Android Key Attestation[0], one of the attestation
>
> schemes included in the draft, which hopefully allows me to build a
>
> production implementation of the draft.
>
>
>
> I've incorporated one change from Thomas and updated the draft to version 2[1].
>
>
>
> There hasn’t been much feedback on the draft during the ACME sessions
>
> or on the mailing list, especially from implementers, so I’m really
>
> excited to see all of the interest on this thread. I’d be more than
>
> happy to incorporate any feedback received and present at IETF 120. If
>
> reviewing the draft in a meeting would be helpful, please reach out to
>
> me directly and I’d be happy to schedule time.
>
>
>
> Thanks,
>
> Brandon
>
>
>
> [0] https://urldefense.com/v3/__https://developer.android.com/privacy-and-security/security-key-attestation__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem9PC1YNe$
>
> [1] https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-acme-device-attest/02/__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem6-cnbGh$
>
>
>
>
>
> On Thu, Feb 22, 2024 at 1:53 PM Prachi Jain <prachi.jain1288@gmail.com> wrote:
>
> >
>
> > I plan to do a POC using this draft and potentially implement it based on the results. Thus very motivated to get this past the finish line.
>
> >
>
> > @Mike Ounsworth, I haven't read draft-ietf-lamps-csr-attestation yet so I am going to give it a read and come back with my thoughts.
>
> >
>
> > On Thu, Feb 22, 2024 at 3:00 PM Mike Malone <mike@smallstep.com> wrote:
>
> >>
>
> >> It's worth noting that Apple has already implemented this draft on macOS, iOS, iPadOS, and tvOS[1]. We've implemented the server side at Smallstep and can confirm that there is adoption. That shouldn't stop the evolution of this draft, of course, but could help inform it. Adoption is promising and it would be unfortunate to see this die at draft.
>
> >>
>
> >> We don't have any experienced IETF authors here -- not sure what that entails -- but we are very interested in the outcome here and would be happy to help however we can. To start, I've shared this with a few contacts that I know will also be interested.
>
> >>
>
> >> Mike
>
> >>
>
> >> [1] https://urldefense.com/v3/__https://support.apple.com/lt-lt/guide/deployment/dep28afbde6a/web__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem_caMV21$
>
> >>
>
> >> On Thu, Feb 22, 2024 at 12:21 PM Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org> wrote:
>
> >>>
>
> >>> At the risk of adding another draft to my plate, I am the lead author on draft-ietf-lamps-csr-attestation, so I suppose it is reasonable for me to volunteer to work on this one also.
>
> >>>
>
> >>>
>
> >>>
>
> >>> I wonder if the design of acme-device-attest should change in light of the existence of draft-ietf-lamps-csr-attestation? But I admit to not having read acme-device-attest in a while :/
>
> >>>
>
> >>>
>
> >>>
>
> >>> ---
>
> >>>
>
> >>> Mike Ounsworth
>
> >>>
>
> >>>
>
> >>>
>
> >>> From: Acme <acme-bounces@ietf.org> On Behalf Of Prachi Jain
>
> >>> Sent: Thursday, February 22, 2024 6:03 AM
>
> >>> To: Deb Cooley <debcooley1@gmail.com>
>
> >>> Cc: Thomas Fossati <tho.ietf@gmail.com>; acme@ietf.org; draft-acme-device-attest.authors@ietf.org
>
> >>> Subject: [EXTERNAL] Re: [Acme] acme-device-attest expired
>
> >>>
>
> >>>
>
> >>>
>
> >>> Thank you for the update, Deb. I am more than willing to work as an author on this draft and help out :) On Thu, Feb 22, 2024 at 5: 28 AM Deb Cooley <debcooley1@ gmail. com> wrote: I know Brandon has been busy, but I don't know his plans
>
> >>>
>
> >>> Thank you for the update, Deb.
>
> >>>
>
> >>>
>
> >>>
>
> >>> I am more than willing to work as an author on this draft and help out :)
>
> >>>
>
> >>>
>
> >>>
>
> >>> On Thu, Feb 22, 2024 at 5:28 AM Deb Cooley <debcooley1@gmail.com> wrote:
>
> >>>
>
> >>> I know Brandon has been busy, but I don't know his plans for this draft.  Maybe his use case has changed?  I've cc'd him on this message.
>
> >>>
>
> >>>
>
> >>>
>
> >>> Note:  acme is a 'working group', to get a draft through the process people have to be willing to work on the draft (vice merely following).  Also drafts can certainly have multiple authors, perhaps an offer of helping as an author might work.
>
> >>>
>
> >>>
>
> >>>
>
> >>> Deb
>
> >>>
>
> >>>
>
> >>>
>
> >>> On Tue, Feb 20, 2024 at 11:01 AM Prachi Jain <prachi.jain1288@gmail.com> wrote:
>
> >>>
>
> >>> Hello,
>
> >>>
>
> >>> I have been closely following this document as well and would like to know the status of the same.
>
> >>>
>
> >>> Thanks,
>
> >>> Prachi
>
> >>>
>
> >>>
>
> >>>
>
> >>> On Sun, Feb 18, 2024 at 1:57 AM Thomas Fossati <tho.ietf@gmail.com> wrote:
>
> >>>
>
> >>> Hi, all,
>
> >>>
>
> >>> The acme-device-attest draft is expired.
>
> >>>
>
> >>> Just checking: what are the plans?
>
> >>>
>
> >>> cheers, thanks!
>
> >>>
>
> >>> _______________________________________________
>
> >>> Acme mailing list
>
> >>> Acme@ietf.org
>
> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem67ft2Ds$
>
> >>>
>
> >>> _______________________________________________
>
> >>> Acme mailing list
>
> >>> Acme@ietf.org
>
> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem67ft2Ds$
>
> >>>
>
> >>> _______________________________________________
>
> >>> Acme mailing list
>
> >>> Acme@ietf.org
>
> >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem67ft2Ds$