search

anima-wg / constrained-voucher

This is a repo for the IETF Internet Draft about constrained vouchers in CBOR
2 stars 4 forks source link

CMS signed CBOR, COSE signed CBOR #52

Closed mcr closed 3 years ago

mcr commented 3 years ago

Is there a significant interest in CMS-signed-CBOR?

wgtdkp commented 3 years ago

Hi @mcr , Actually, the Thread technology is currently using CMS-signed-CBOR to forward voucher request to MASA server. See the implementation at https://github.com/openthread/ot-registrar/blob/c42a824cdbae1005459d18e88eb476100cf5a5ec/src/main/java/com/google/openthread/registrar/Registrar.java#L305-L308.

mcr commented 3 years ago

Thread is still using CMS-signed-CBOR. Keep it.

mcr commented 3 years ago

Does #59 solve this for you?

mcr commented 3 years ago

If the backend can be COSE-signed-CBOR, wrapping COSE-signed-CBOR, then the MASA need not speak CMS at all. The Registrar might not have COSE-signing, (just validation) if it can use CMS-signing all the time on the backend. Requirements to be determined.

mcr commented 3 years ago

@EskoDijk to bring this to Thread.

mcr commented 3 years ago

@siethower maybe too.

siethower commented 3 years ago

To my understanding Thread does not require CMS-signed-CBOR. Thread would follow what IETF is prosing here, to be confirmed by @EskoDijk

I see the following options, for communication between Registrar and MASA:

  1. Registrar voucher request to MASA in: "JSON-in-PKCS#7/CMS" or better: "JSON-in-JWS" -> this should be OK for HTTP based communication between Registrar and MASA -> depends on if there are limitations on the stack of Registrar/MASA for not using "JSON-in-JWS" or "JSON-in-PKCS#7/CMS", if the implementation is only focused on constrained pledges and would not support an additional form factor
  2. Registrar voucher request to MASA in: "CBOR-in-COSE_Sign", depends on #59 (maturity of draft-ietf-cose-x509-07, to carry signer certificate/chain) -> goes together with the question for CoAP between Registrar and MASA #58 and may be a resulting need for CBOR form factor
EskoDijk commented 3 years ago

@siethower Correct, the Registrar->MASA communication is out of Thread specification scope. (The OpenThread implementation is independent of that)

One reason to have an option 2 as above (in combination with CoAPS) would be to have a minimum-size solution that is suitable on a contrained data link between Registrar and MASA. The reason this link may be constrained is use cases of e.g. a portable Commissioning Tool with a Registrar on board, that visits building areas where there is no IT infrastructure yet and cellular/LPWAN coverage is minimal or just low speed (think e.g. a 20 kbps cellular link). However this scenario is becoming less relevant over time of course, and we didn't yet verify if the payload sizes totals would be actually much smaller using this CoAPS option. In terms of latency the DTLS still requires some round-trips to do the handshake so the benefit of COAPS over HTTPS here is still unclear.

Another reason for option 2 might be to avoid CMS as currently specified for BRSKI. (E.g. because one expects that CMS would be phased out or so, or has less attractive security properties than COSE - still JWS is another choice in this case!)

mcr commented 3 years ago
  1. "JSON-in-PKCS#7/CMS" vs "CMS-signed-JSON." (RFC8366)
  2. "JSON-in-JWS" vs "JOSE-signed-JSON" (new RFC?)
  3. "CBOR-in-PKCS#7/CMS" vs "CMS-signed-CBOR" (constrained-voucher)
  4. "CBOR-in-COSE" vs "COSE-signed-CBOR" (constrained-voucher)
csosto-pk commented 3 years ago

2. Registrar voucher request to MASA in: "CBOR-in-COSE_Sign", depends on #59 (maturity of draft-ietf-cose-x509-07, to carry signer certificate/chain) -> goes together with the question for CoAP between Registrar and MASA #58 and may be a resulting need for CBOR form factor

I have the concern that we may be going too bleeding edge with things that may never be used. I definately can appreciate the CBOR-in-COSE_Sign or JWT advantages, but I remember talking JWT and CBOR as the "attractive future things" in BRSKI 3 years ago and it still looks like we are not sure they will be needed or ready to support carrying the whole cert chain.

csosto-pk commented 3 years ago

However this scenario is becoming less relevant over time of course, and we didn't yet verify if the payload sizes totals would be actually much smaller using this CoAPS option. In terms of latency the DTLS still requires some round-trips to do the handshake so the benefit of COAPS over HTTPS here is still unclear.

I can definitely appreciate the scenario, but is it really a scenario that will occur? Could we be trying to boil the ocean in a complicated case that may never be necessary? Shouldn't rare cases be addressed where necessary in a separate document if they complicate the existing document by a lot?

EskoDijk commented 3 years ago

@csosto-pk Agree with your comments; we could save the "constrained uplink to MASA" case for the future, as a separate spec, in case it turns out that it is needed.

EskoDijk commented 3 years ago

As presented in the IETF 109 meeting - the way I understood it - preference is to follow BRSKI as closely as possible, so for Registrar -> MASA 1) Voucher Request over HTTPS with CMS-signed-JSON where the constrained (COSE-signed-CBOR) prior-signed-voucher-request is carried in the JSON base64 encoded as usual for the prior-signed-voucher-request. 2) Voucher (response) over HTTPS with constrained (COSE-signed-CBOR) format where the MASA determines the final format that the Pledge can accept & parse. The MASA bases its decision on knowledge of the Pledge model/type/serial and knowing also the format of the 'prior-signed-voucher-request'; and based on the Accept header given by the Registrar with its format preference(s).

mcr commented 3 years ago

On Pledge->JRC side, the COSE-signed-CBOR is used. OpenThread uses CMS-signed-CBOR only because there was no known way to include the chain. This only reason. Unanimous to remove CMS-signed-CBOR from constrained-voucher: not needed for Thread! @EskoDijk will bring this topic to Thread?

mcr commented 3 years ago

Let https://github.com/openthread/openthread know.

EskoDijk commented 3 years ago

To summarize the outcomes of recent discussions and actions: for Registrar-to-MASA communications

Given the above we can close this issue in IETF scope now.