search

ace-wg / est-oscore

Other
0 stars 0 forks source link

Normative requirements on Content-Format support (ASN.1 / CBOR) #35

Closed malishav closed 4 months ago

malishav commented 8 months ago

Given that some Content-Formats may be CBOR-encoded objects, a question is what should be the normative requirements that should be listed for EST-clients and EST-servers.

Here is a proposal to keep backward compatibility:

EST-server SHOULD support both ASN.1 and CBOR-encoded objects. It is up to the client to support only ASN.1, CBOR encoding, or both. As a reminder, Content-Format negotiation happens through CoAP's Accept option present in the requests.

gselander commented 8 months ago

Content type negotiation may take place inside object, see https://github.com/cose-wg/CBOR-certificates/issues/77#issuecomment-849721718

malishav commented 7 months ago

Comment at IETF-118 from Esko:

ED: I hope I am not interrupting. We can phrase it with a capital SHOULD. And to add some exception to say that is ok not to support both. (…) In ANIMA WG we offer many options and the Constrained Client picks up one. (…). There is a problem coming from the EST-COAP RFC In general it is ok for the client to support only one format, but the server should support both. (avoid asking for non-supported format) At ANIMA WG we are also looking at other formats, we have a problem with the PK(…) we are looking for another format>

malishav commented 7 months ago

Comment at IETF-118 from @marco-tiloca-sics:

I think this proposal is good. On the negotiation, the Accept option is critical. So, if you want negotiation to be possible in general, you have to say that the EST-server MUST support the Accept option. You already have a section with this kind of requirements where you can say that.

EskoDijk commented 7 months ago

To clarify my comment from IETF 118: it would be nice to have a "MUST" on the server to support both the RFC 9148 ASN.1 formats, and any new formats if defined by this draft (which could be the "CBOR formats" mentioned).

Though I'm not fully sure what the intended CBOR formats are: it could be e.g. a C509 certificate instead of an X509 certificate (which is application/pkix-cert, 287). Or it could be that another CBOR format was intended as alternative to an ASN.1 format.

EskoDijk commented 7 months ago

And the problem I mentioned in RFC 9148, which possibly needs to be corrected in this document, is the following text in 4.3:

Content-Format 281 MUST be supported by EST-coaps servers. Servers MAY also support Content-Format 287.

This means 287 is optional for a server. However a client may only support 287. As indicated by the following text:

It is up to the client to support only Content-Format 281, 287 or both.

So that means the protocol doesn't work necessarily if the client chooses only 287. One way to solve it is to make both types mandatory on the server. But, in the ANIMA WG we have discovered that there are some management problems if the client uses type 287 only; it's a very limited method of getting only one CA certificate. So a better solution will be to ensure the client does not use a single request asking for 287, but something more intelligent that enables it to get multiple CA certificates if needed.

In ANIMA WG we want to do this without using the PKCS#7 container format 281, which is useless overhead in our case: the only thing we need is just a "bag" of X509 certificates and we're working on an efficient method to get the elements from this "bag".