[Cscwg-public] Side meeting on PKIX key attestation format

Fri Apr 7 14:18:04 UTC 2023

This meeting has been moved to 9:30 AM Eastern next Thursday to avoid the
conflict with the CABF plenary conference call at 11.

-----Original Message-----
From: Cscwg-public <cscwg-public-bounces at cabforum.org> On Behalf Of Corey
Bonnell via Cscwg-public
Sent: Friday, April 7, 2023 6:53 AM
To: cscwg-public at cabforum.org
Subject: [Cscwg-public] FW: Side meeting on PKIX key attestation format

Hello,
As we all know, key attestation has been an active topic here especially
considering the improved key protection requirements coming into effect in
June. In light of this, Mike Ounsworth of Entrust asked me to forward the
email below. Mike has been working on a draft that specifies a common format
for key attestations [1] and is scheduling a meeting next week for folks
interested in this topic to discuss. If you or any members of your team are
interested in attending, please reach out to Mike directly at
mike.ounsworth at entrust.com.

The below email can also be found in the LAMPS WG mail archive at
https://url.avanan.click/v2/___https://mailarchive.ietf.org/arch/msg/spasm/X
qQam3x1A0RM_GgorNLVZN-DPAE/___.YXAzOmRpZ2ljZXJ0OmE6bzo0MjU5ODZhODY4YTU2MDEyY
zg4NDU5NzhhNmEyOGY3OTo2OjMxYmU6YWYxNmIzMDNmYWFjN2E1NjUxZjNhMTg5ZDhkMjE4MDg5M
jgwMzA3OWVhZmE1MWJlMzQ2OTg1NWNlYzM2NTZlMjpwOkY.

Thanks,
Corey

[1]
https://url.avanan.click/v2/___https://datatracker.ietf.org/doc/draft-ounswo
rth-pkix-key-attestation/02/___.YXAzOmRpZ2ljZXJ0OmE6bzo0MjU5ODZhODY4YTU2MDEy
Yzg4NDU5NzhhNmEyOGY3OTo2OmI0MTE6Mjk3MWNmOTFhN2E0NDNjNjBhZDFjMDA4NGM2ZjVmMGJh
ZDJiZDQ4MzFhMTMxNzk2Y2RkNGUzZGRiMmVlYTY3MzpwOkY

-----Original Message-----
From: Spasm <spasm-bounces at ietf.org> On Behalf Of Mike Ounsworth
Sent: Thursday, April 6, 2023 9:37 PM
To: 'LAMPS' <spasm at ietf.org>
Subject: [lamps] Side meeting on PKIX key attestation format

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
Spasm at ietf.org
https://url.avanan.click/v2/___https://www.ietf.org/mailman/listinfo/spasm__
_.YXAzOmRpZ2ljZXJ0OmE6bzo0MjU5ODZhODY4YTU2MDEyYzg4NDU5NzhhNmEyOGY3OTo2OjRkZG
U6ZmMxZDA2YThhNGUwZTRlNzNhZTI4OTQ3MThjYjhiZDU2NzRlYzBmN2U4YTA0OTJmMjNhNTk1YT
k5ODYyZjBlYzpwOkY
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4990 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/cscwg-public/attachments/20230407/d884be4f/attachment.p7s>