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

[Mike Ounsworth <[e-mail]>]

 <mailto:bweeks=[e-mail]> @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=[e-mail]>; Prachi Jain <[e-mail]>
Cc: Mike Malone <[e-mail]>; Deb Cooley <[e-mail]>; Thomas Fossati <[e-mail]>; [e-mail]; [e-mail]
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=[e-mail] <mailto:bweeks=[e-mail]> > 
Sent: Thursday, February 22, 2024 4:25 PM
To: Prachi Jain <[e-mail] <mailto:[e-mail]> >
Cc: Mike Malone <[e-mail] <mailto:[e-mail]> >; Mike Ounsworth <[e-mail] <mailto:[e-mail]> >; Deb Cooley <[e-mail] <mailto:[e-mail]> >; Thomas Fossati <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
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$ <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$ <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 <[e-mail] <mailto:[e-mail]> > 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 <[e-mail] <mailto:[e-mail]> > 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$ <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=[e-mail] <mailto:Mike.Ounsworth=[e-mail]> > 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 <[e-mail] <mailto:[e-mail]> > On Behalf Of Prachi Jain
>>> Sent: Thursday, February 22, 2024 6:03 AM
>>> To: Deb Cooley <[e-mail] <mailto:[e-mail]> >
>>> Cc: Thomas Fossati <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
>>> 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 <[e-mail] <mailto:[e-mail]> > 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 <[e-mail] <mailto:[e-mail]> > 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 <[e-mail] <mailto:[e-mail]> > wrote:
>>> 
>>> Hi, all,
>>> 
>>> The acme-device-attest draft is expired.
>>> 
>>> Just checking: what are the plans?
>>> 
>>> cheers, thanks!
>>> 
>>> _______________________________________________
>>> Acme mailing list
>>> [e-mail] <mailto:[e-mail]> 
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem67ft2Ds$ <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem67ft2Ds$> 
>>> 
>>> _______________________________________________
>>> Acme mailing list
>>> [e-mail] <mailto:[e-mail]> 
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem67ft2Ds$ <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem67ft2Ds$> 
>>> 
>>> _______________________________________________
>>> Acme mailing list
>>> [e-mail] <mailto:[e-mail]> 
>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem67ft2Ds$ <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/acme__;!!FJ-Y8qCqXTj2!fu3SxMuwGtSlmeB62k3eNjvoS8g2HzC3XbRtn17d7Pf0WzL9Sze1JAQxH2FFJRr0gDTLP9ymFYYHCL6CLLTTf2oFs7yem67ft2Ds$>