Re: [lamps] [EXTERNAL] Re: Side meeting on PKIX key attestation format

[Mike Ounsworth <[e-mail]>]

Hi Michael,

> Task B - Specify a key attestation statement format for big iron HSMs. This is NOT necessarily an ASN.1 structure, and, functionally, probably mimics the contents of a Trusted Platform Module attestation statement (e.g. a TPMS_ATTEST structure containing a TPMS_CERTIFY_INFO paired with a TPMT_SIGNATURE and any externally provided qualifying data like a nonce). 

I have the references you gave me to the TPM attestation format: TPM2_Part2_Structures section 10.12, and TPM2_Part3_Commands section 18. I still need to give those a detailed read before Thursday, but I thank you for pointing us to very similar work that's already been done. I am hopeful that you will be able to attend Thursday's meeting to provide historical context on how and why that come to be the way it is.

I agree with your summary if needs.

I am not opposed to taking this work to another SDO, but I want to get this moving with some momentum before really grappling with that question in full.

---
Mike Ounsworth

-----Original Message-----
From: Spasm <[e-mail]> On Behalf Of Michael StJohns
Sent: Saturday, April 8, 2023 2:53 PM
To: [e-mail]
Subject: [EXTERNAL] Re: [lamps] Side meeting on PKIX key attestation format

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.

______________________________________________________________________
Since I'm the one that suggested that LAMPS might be the correct home for all of this, I wanted to provide a bit of clarification.

As I see it there are actually 6 or so separate tasks being contemplated under the various drafts and needs:

Task A - Specify a mechanism for the carriage of key attestation statements in Certificate Signing Requests (of various formats).   As I see it, that's probably best done in LAMPS

Task B - Specify a key attestation statement format for big iron HSMs. This is NOT necessarily an ASN.1 structure, and, functionally, probably mimics the contents of a Trusted Platform Module attestation statement (e.g. a TPMS_ATTEST structure containing a TPMS_CERTIFY_INFO paired with a TPMT_SIGNATURE and any externally provided qualifying data like a nonce).   This would seem to me to be an HSM vendor task, and not necessarily or even desirably a CA/BF task, although the need for such is being driven by that group.

Task C - Specify the pairing of the results of A and B - an actual instantiation of A with the contents of format specified by B.  This could be done as part of B, or as a fairly simple LAMPS or independent stream submission, or as an IANA registration to get an OID for an external document.  Finishing this task is Mike's actual goal (I
believe) and is dependent on the first two tasks.

Task D - Specify the pairing of A along with necessary encodings of various attestation statements necessary to support the Webauthn attestation requirements. That's somewhat the goal of Carl's document that's current a WG document.

Task E - Specify the pairing of A along with any proprietary attestation statement formats - as they occur.    Those would be the responsibility of the format owner, and could be a simple IANA registration of an external documentation.  Only mentioned here because A has to support this model over time.

Task F - Specify the pairing of A along with an non-IETF, but standardized,  attestation statement formats - e.g. TPM and Android attestation statements spring to mind. Could be done in LAMPS, either stand-alone or included in the document from Task A, or by the originating standards bodies along the lines of Task E.

Note that B-F can be done in parallel with A, and none of those require IETF participation.

Mike


On 4/6/2023 9:36 PM, Mike Ounsworth wrote:
> Hi LAMPS!
>
> Meeting will be next Thursday, April 13 at 11:00 EST. I sent a calendar invite and Teams link to everyone who has contacted me with interest. If you would like an invite then please email me directly.
>
> I had been on the agenda of the LAMPS 116 meeting last week to present draft-ounsworth-pkix-key-attestation, but we ran out of time and I did not get to present. The slides I had planned to present are here. Given that this project is already late with respect to the new CA/Brower Forum Baseline Requirements going live on June 1, 2023, I am opting to start author's working sessions in advance of a LAMPS interim meeting. I hope that this time works for everyone.
>
> Meeting agenda
> * Urgent business:
>      * Do the design goals below cover your product's needs?
>      * Short discussion on whether any existing key attestation formats meet the design goals (WebAuthn or TPM).
>      * Mike to give a short presentation on the proposed key attestation format
>      * Discuss the proposed key attestation format and CSR attribute with the goal of agreement between HSM and CA vendors so we can start implementing.
> * Medium-term business:
>      * What about devices currently in the field with proprietary key attestation formats or no KA?Can they be bootstrapped into this key attestation format?
>          * Can HSM vendors provide CAs with command-line utilities to manually validate proprietary key attestation formats?
> * Long-term business:
>      * There has been a suggestion that IETF/LAMPS is not the right home for this work. That maybe W3C/WebAuthn or CA/B F CSBRs would be more appropriate.
>          * I propose that in the interest if time, we focus first on agreeing on an implementable wire format first, and afterwards figure out which SDO to seek publication with. For the time being let's leave it with IETF/LAMPS as the official discussion forum for this work.
>
> Regulatory requirement
> * Upcoming CA/Browser Forum Code Signing Baseline Requirements will be in force June 1, 2023 (see CSC 13, or CSBR v3.2 s. 6.2.7.3). They require CAs to verify that private keys are in a FIPS 140-2 L2 or CC EAL 4+ HSM (no TPMs). Keys must be non-exportable / non-recoverable and otherwise comply with the requirements of section 6.2.7.3.
>
> Design goals for a key attestation format
> 1.      From a CA's perspective, we want a standardized key attestation format that can be placed in a CSR and verified automatically to prove that the subscriber key complies with CA/B F CSBRs.
> 2.      From an HSM's perspective, we want a format that's easy to write an emitter for. Here, by "easy" we mean with minimal code changes from current functionality of the crypto module meaning fast time to a patch and an easy FIPS / CC re-cert.
>
> Existing key attestation formats
> * W3C / WebAuthn 2, particularly those defined in section 8.4
> * TPM 2.0, particularly Part 2 section 10.12.
> None of these appear to be a good fit for the design goals since they are either in encodings that cryptographic modules do not typically support today (such as CBOR), or they still resolve to a proprietary inside the envelope. However if the group of HSM vendors feels that one of the existing formats would be acceptable then that would be easier than defining a new one.
>
> Related CSR attribute
> * IETF/LAMPS draft-ietf-lamps-key-attestation-ext proposed a CSR attribute to carry WebAuthn-formatted key attestations in order to support WebAuthn-over-ACME (draft-acme-device-attest). There is ongoing discussion at LAMPS about whether to modify that draft to support both WebAuthn-formatted as well as our key attestation, or to assign separate CSR attr OIDs for the different attestation formats. This group probably should have an opinion, but ultimately I think this is up to LAMPS to decide since they are the ones assigning the OIDs.
>
>
> Thanks, and I look forward to a productive discussion,
> ---
> Mike Ounsworth
> Software Security Architect, Entrust
>
> Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spas
> m__;!!FJ-Y8qCqXTj2!dLTJRqPsUcHs86dH6pd972d9HzUq51qVK3oG0MH6DhKc2ZVVL7E
> Ynr3fFV9Vdx3Vgwfad9PhYQQn8Pzv7fRA0v7Sc2c$


_______________________________________________
Spasm mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!dLTJRqPsUcHs86dH6pd972d9HzUq51qVK3oG0MH6DhKc2ZVVL7EYnr3fFV9Vdx3Vgwfad9PhYQQn8Pzv7fRA0v7Sc2c$