CCC-Attestation / governance

Apache License 2.0
0 stars 5 forks source link

Proposal to create an Interoperable RA-TLS Project #8

Closed shnwc closed 1 year ago

shnwc commented 1 year ago

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

thomas-fossati commented 1 year ago

The linked document proposes using

  1. A OID in the TCG DICE arc for the cert extension
  2. A tagged CBOR bstr for the evidence format, with the associated registration procedures

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.

KeithMoyer commented 1 year ago

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.

shnwc commented 1 year ago

@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 commented 1 year ago

@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.

nedmsmith commented 1 year ago

Yes. Please arrange a meeting.

shnwc commented 1 year ago

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.

thomas-fossati commented 1 year ago

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.

dcmiddle commented 1 year ago

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.

shnwc commented 1 year ago

@thomas-fossati please see updated description with the clarification. Let me know if that addressed your concern.

thomas-fossati commented 1 year ago

@thomas-fossati please see updated description with the clarification. Let me know if that addressed your concern.

awesome, thanks.

shnwc commented 1 year ago

Thank you @thomas-fossati! Since there is no objection from other chairs, I'll move forward to create the repo.

shnwc commented 1 year ago

The project repo has been created, this issue is now closed.

dcmiddle commented 1 year ago

The new repo for reference: https://github.com/CCC-Attestation/interoperable-ra-tls