ace-wg / est-oscore

Other
0 stars 0 forks source link

Content-Format support for DER-encoded ASN.1 objects #38

Closed malishav closed 4 months ago

malishav commented 5 months ago

The draft currently mandates that Content-Format 281 MUST be supported by the server and Content-Format 287 MAY be supported by the server:

Content-Format 281 MUST be supported by EST-oscore servers. Servers MAY also support Content-Format 287. It is up to the client to support only Content-Format 281, 287 or both.

This is an issue in RFC9148 as it may lead to interoperability issues where clients request/support 287 but server only supports 281.

This issue aims at fixing this in the EST-oscore document.

CC: @EskoDijk

malishav commented 5 months ago

@EskoDijk wrote:

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

malishav commented 5 months ago

@EskoDijk:Has this progressed further in ANIMA in a way that I could reference it from this document? Is there a document you could point me to?

(I created a PR with the simplest solution to mandate 287 for servers (PR #39) for now, but don't plan on merging it until this is resolved. )

EskoDijk commented 5 months ago

@malishav Thanks for looking into this. There's now a new revision of cBRSKI where this issue is addressed, see text in https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher#brski-est-extensions-registrar (Section 6.6).

Besides this, cBRSKI also adds in Seciton 6.5.5 a new Content-Format for the /crts resources specifically. See https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-voucher#name-multipart-content-format-fo This is a simpler/alternative container for multiple certs that uses CBOR-based "multipart-core" instead of PKCS.

I've just created the issue https://github.com/anima-wg/constrained-voucher/issues/295 , seeing that cBRSKI doesn't yet mandate support for 287 but the Pledge does rely on it.