Support 2-tier and 3-tier CAs: fetching multiple CA certs using EST /crts request?

[EskoDijk]

Background: for 2-tier and 3-tier CA domains, it is useful if all constrained-Pledges are able to fetch all CA certificates of the Domain in a standard way. This also allows them to correctly do things like CA renewal in a 2- or 3-tier domain. The current optional 'limitation' to a single /crts response certificate makes such things more complex and dependent on the "type" of constrained Pledge/IoT-device.

We had earlier ideas on this: 1) mandatory support for EST-coaps content-format application/pkcs7-mime; smime-type=certs-only (281) - EST standard 2) support a content-type that is a CBOR array of 1 or more single X509 certificates (simpler to parse with embedded libraries / mbedTLS?) 3) support multiple CoAP sub-resources for additional certs, e.g. after doing /crts we request /crts/1, /crts/2, etc. If resource is not found 404 it means that certificate isn't there. 4) support blockwise transfer, already mandated by EST-coaps, to transport either (1) or (2) or (3).

The Pledge / IoT device would also use the fetched CA certificates to create the cert chain that it needs for the (D)TLS handshake when connecting to a peer in the domain or another Registrar, per RFC 7030 4.1.3.

[mcr]

Esko Dijk @.***> wrote:

1) mandatory support for EST-coaps content-format application/pkcs7-mime; smime-type=certs-only (281) - EST standard

Boo.

> 2) support a content-type that is a CBOR array of 1 or more single X509
> certificates (simpler to parse with embedded libraries / mbedTLS?)

I'm okay with this, but it's not my preference.

> 3) support multiple CoAP sub-resources for additional certs, e.g. after
> doing /crts we request /crts/1, /crts/2, etc. If resource is not found
> 404 it means that certificate isn't there.

This is my first choice. Is there something we could return in /crts as a header that could indicate the N?

> 4) support blockwise transfer, already mandated by EST-coaps, to
> transport either (1) or (2) or (3).

If we must.

-- Michael Richardson @.***> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide

[EskoDijk]

@mcr For option 3), in CoAP we have CoAP Options that function like headers. These could be used for that purpose; but there is currently no Option defined with anything that comes close to our use case. A new header could be defined but that's most often only done when there are multiple use cases that can benefit of the Option i.e. something generic.

There are ways to avoid defining Options (and thus tampering with the CoAP stack) although these could be less efficient (more round trips):

1. define a new response format (application/cbor) for the /crts resource that just returns a single number which states the number of available certificates. Each certificate is then available under a number /crts/1, /crts/2 etc.
2. as 1. but define the new resource under a different name like /crts/c ("certs count") which the client will try to fetch first.
3. host both the certificate and the CBOR structure that returns number N at the same resource - the client indicates with the Accept Option which representation it wants to have, the full cert, or the number N. This is a bit misusing the resource concept.
4. define a new response format that is a two-part CBOR array, part 1 is number N and part 2 is the first CA cert. ... and probably more

[mcr]

Some require multiple round trips. Some require new formats. Which is the better tradeoff?

[EskoDijk]

@mcr A new content-format (and possibly also a new resource name) should be okay, since CoAP was designed to easily handle additional/new formats and resources. Given that Constrained BRSKI is not deployed yet AFAIK, we can still make changes to it. We already update EST-coaps in some aspects so adding an additional content-format should be ok.

We can use the existing CoRE multipart format: https://www.rfc-editor.org/rfc/rfc8710.html This would e.g. contain a CBOR array as payload with 4 elements:

[60 , \<single-CBOR-encoded-integer-number-N> , 287 , \<single-X509-binary-cert> ]

the number N is the total number of CAcerts. The first one is already included in the payload (\<single-X509-binary-cert>). The second, third etc can be requested by GET on /crts/N with N=2,3, etc. N=1 would return the first one which was returned by the GET /crts request.

In case of multiple certs, this approach also avoids having to use CoAP blockwise transfers to fetch an entire blob of multiple certificates.

[mcr]

Esko Dijk @.***> wrote:

We can use the existing CoRE multipart format: https://www.rfc-editor.org/rfc/rfc8710.html This would e.g. contain a CBOR array as payload with 4 elements:

[60 , , 287 , ]

yeah, let's do that then.