Closed shnwc closed 1 year ago
The linked document proposes using
It seems to me that there is room to align a bit more with the harmonisation work this group has done in the past few months on encap formats -- which are (unsurprisingly) compatible with the tagged bstr approach, but use a different registration strategy --, as well as other standards work done in the IETF regarding X.509 extensions for carrying evidence in certs which may provide stronger semantics.
I support creation of this project with a scope of encouraging commonality between existing/future RA-TLS implementations through documentation and conformance tests. If the scope is to expand in the future to include implementation code for other projects to rely upon, further discussion/approval should occur.
@KeithMoyer Thank you for your support! Yes the scope is to encourage interoperability between existing/future RA-TLS implementations through documentation and conformance tests.
@thomas-fossati The tagged CBOR data is the same as the "CMW CBOR Tags" format defined in draft-ftbs-rats-msg-wrap, which supports tags registered with CoAP as well as other registries. The RA-TLS proposal does not put limitations as to which registry must be used. Different evidence formats could be suitable for different registries.
draft-ietf-lamps-key-attestation-ext focuses on certificate management protocols extension and WebAuthn. The RA-TLS scope is different, it uses an X.509 cert extended with and OID containing evidence that covers the subject public key. The DICE OIDs aligns perfectly.
@thomas-fossati The tagged CBOR data is the same as the "CMW CBOR Tags" format defined in draft-ftbs-rats-msg-wrap, which supports tags registered with CoAP as well as other registries. The RA-TLS proposal does not put limitations as to which registry must be used. Different evidence formats could be suitable for different registries.
Maybe make this point clearer in the description.
draft-ietf-lamps-key-attestation-ext focuses on certificate management protocols extension and WebAuthn. The RA-TLS scope is different, it uses an X.509 cert extended with and OID containing evidence that covers the subject public key. The DICE OIDs aligns perfectly.
I think it's worth for you and @nedmsmith to have a chat with Carl Wallace on this point. I've spoken to him last week and he said he was happy to make room to CMWs in the LAMPS extension. I can organise a meet-up if you are interested.
Yes. Please arrange a meeting.
In response to "Maybe make this point clearer in the description", clarification will be in the design document to be posted in this new project, and reviews and updates can be done there. The project proposal in this issue should avoid trying to define the solution itself.
In response to "Maybe make this point clearer in the description", clarification will be in the design document to be posted in this new project, and reviews and updates can be done there. The project proposal in this issue should avoid trying to define the solution itself.
That's exactly the issue I have tried to highlight with the document linked above: it looks to already define the solution.
My thinking is that there is potentially a way to tweak the design to profit from a stronger harmonisation with other parts of the ecosystem, not just between the RA-TLS solutions.
In our spirit of minimum viable governance, I would like to unblock this RA-TLS harmonization. A valuable first goal is getting these 3 CCC projects interoperable. That's actually a really big outcome for our SIG. As we do that if we can improve from that to a broader goal that's great, but I would prefer we not block the creation of this repo while sorting that out.
@thomas-fossati please see updated description with the clarification. Let me know if that addressed your concern.
@thomas-fossati please see updated description with the clarification. Let me know if that addressed your concern.
awesome, thanks.
Thank you @thomas-fossati! Since there is no objection from other chairs, I'll move forward to create the repo.
The project repo has been created, this issue is now closed.
The new repo for reference: https://github.com/CCC-Attestation/interoperable-ra-tls
Proposal to create an Interoperable RA-TLS Project
Background
Based on the recent CCC Attestation SIG presentation on Interoperable RA-TLS and recommendations, we have created documents with detailed X.509 cert extension and evidence formats definition. Pull requests have been created in existing RA-TLS projects (Gramine, RATS-TLS, Open Enclave, SGX SDK) add support of the proposed scheme.
Proposal
This proposal is to create a project (interoperable-ra-tls) under the CCC Attestation SIG, to host design documents and interoperability tests.
The Interoperable RA-TLS presentation forms initial version of the proposed scheme, which will be further clarified and refined in the design documents to be hosted in this projects. Though the presentation mentioned about IANA registration, the proposed scheme will not put restrictions on which registry must be used. Different evidence formats could be suitable for different registries.
Proponents