have /crts return trusted anchor certificates one at a time

[EskoDijk]

The combination of constrained BRSKI + constrained (CoAP) EST works well, however it has 2 distinct disadvantages:

• The EST CA-certs ressponse (/est/crts) needs support for the PKCS#7 format which is not implemented in popular libraries like mbedtls.
• CoAP blockwise transfer is needed to transfer the EST CA-certs response, because it potentially contains more than 1 certificate and then it doesn't fit anymore in a single UDP packet (1280 byte MTU limit). Note that other payloads like single certificates, vouchers, voucher requests etc will all fit in the 1280 byte limit comfortably(*) So only for this single message it would be needed to add CoAP blockwise transfer, which increases code size and complexity.

(*) based on implementation experience.

An easy and elegant remedy for both issues above is to allow an EST client to make different requests to retrieve the CA-certs one by one:

GET /.well-known/est/crts
Accept: application/pkix-cert (TBD287)

2.04 Changed
Content-format: application/pkix-cert (TBD287)
Payload: single CA certificate 'CA1' that is the direct "parent" of the LDevID cert

GET /.well-known/est/crts/2
Accept: application/pkix-cert (TBD287)

2.04 Changed
Content-format: application/pkix-cert (TBD287)
Payload: single CA certificate 'CA2' that is the direct "parent" of CA1

GET /.well-known/est/crts/3
Accept: application/pkix-cert (TBD287)

4.04 Not Found

This enables the Pledge / EST client to build the complete chain: LDevID -> CA1 -> CA2 . The last 4.04 response tells the Pledge that there are no more relevant CA certificates. The CA certificates available under resources /.well-known/est/crts/ could be served in no particular order, or in chaining order if applicable. It would be preferred if the certificate served under /.well-known/est/crts would be the direct signing CA of the LDevID that the Pledge has obtained at that EST server, or will obtain at that EST server.

Doing such a solution would be an update of ace-coap-est. The advantage is that the Pledge now does not need to implement PKCS#7 nor CoAP blockwise.

[mcr]

I'm very enthusiastic for this. I think we should do this, and we should make this the default. I'm unclear why the /est/certs should return 2.04 though?

In the COSE meeting today, we are discussing CBOR compressed certificates. We also discussed whether CRLs and OSCP staples should also be compressed.

What format do you want to return rather than PKCS7? I think that we should provide this action as a different URL than "crts"

[csosto-pk]

I like it as well. I wish we had thought of it as well when writing the EST-coaps draft. So EST-coaps-bis? Or put it in the Constrained Voucher draft?

[petervanderstok]

Hi Esko,

I understand the PKCS#7 argument. However, I do use blockwise rather suscessfully; My limit is 1024 bytes and that is smaller than the request_voucher payload from registrar to masa. Blockwise is certainly more efficient and more reliable than sending the the certificates one after the other. (lower number of packets, lower number of bytes)

I prefer a new document for your suggestions and keep the constrained voucher draft focus as is.

Cheerio,

Peter

Esko Dijk schreef op 2021-01-20 12:06:

The combination of constrained BRSKI + constrained (CoAP) EST works well, however it has 2 distinct disadvantages:

• The EST CA-certs ressponse (/est/crts) needs support for the PKCS#7 format which is not implemented in popular libraries like mbedtls.
• CoAP blockwise transfer is needed to transfer the EST CA-certs response, because it potentially contains more than 1 certificate and then it doesn't fit anymore in a single UDP packet (1280 byte MTU limit). Note that other payloads like single certificates, vouchers, voucher requests etc will all fit in the 1280 byte limit comfortably(*) So only for this single message it would be needed to add CoAP blockwise transfer, which increases code size and complexity.

(*) based on implementation experience.

An easy and elegant remedy for both issues above is to allow an EST client to make different requests to retrieve the CA-certs one by one:

GET /.well-known/est/crts Accept: application/pkix-cert (TBD287)

2.04 Changed Content-format: application/pkix-cert (TBD287) Payload: single CA certificate 'CA1' that is the direct "parent" of the LDevID cert

GET /.well-known/est/crts/2 Accept: application/pkix-cert (TBD287)

2.04 Changed Content-format: application/pkix-cert (TBD287) Payload: single CA certificate 'CA2' that is the direct "parent" of CA1

GET /.well-known/est/crts/3 Accept: application/pkix-cert (TBD287)

4.04 Not Found

This enables the Pledge / EST client to build the complete chain: LDevID -> CA1 -> CA2 . The last 4.04 response tells the Pledge that there are no more relevant CA certificates. The CA certificates available under resources /.well-known/est/crts/ could be served in no particular order, or in chaining order if applicable. It would be preferred if the certificate served under /.well-known/est/crts would be the direct signing CA of the LDevID that the Pledge has obtained at that EST server, or will obtain at that EST server.

Doing such a solution would be an update of ace-coap-est. The advantage is that the Pledge now does not need to implement PKCS#7 nor CoAP blockwise.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub [1], or unsubscribe [2].

Links:

[1] https://github.com/anima-wg/constrained-voucher/issues/72 [2] https://github.com/notifications/unsubscribe-auth/ADCZGQJ2QOISJTUSCA3A2DTS222MTANCNFSM4WKQAIQA

[mcr]

idea:

1. Pledge gets voucher, uses pinned item to complete provisioning.
2. Pledge does enrollment of LDevID, sees if pinned item is the CA for the LDevID, if so, then it MAY skip /crts
3. Pledge gets /crts, and if it gets 2.31, then it proceeds with /crts/{2,3,...} until it gets a 2.01
4. Is it possible that there are zero certificates returned?

2.04 Changed -> 2.31 Continue In the case where there are multiple trust anchors, then the pinned item will not be the LDevID anchor. We need a picture. We need some text explaining why there multiple trust anchors.

[EskoDijk]

on 1.) and 2.) : text for this is already in the Github repo

on 3.) I'm not in favor of using 2.31 Continue, because in CoAP it has a narrow definition in context of Blockwise Transfers only. Specifically, a 2.31 doesn't imply success of the GET request but rather indicates the final status will come later. So a client that does a GET request asking for a single cert (application/pkix-cert) and gets this in the response, needs to receive a 2.05 Content. (In this issue description I use 2.04 - sorry that's not the right code.)

on 4.) can zero certificates be returned: we can include text saying that this is not possible. An EST server always needs at least one TA, which is the CA that signs certificates produced by the EST server itself.

on 5.) in case there are multiple TAs: the pinned identity MAY be the LDevID anchor, or it MAY be another TA. Also note that the pinned identity MAY be a CA that's completely different from any EST TA !

Reasons / use cases for having multiple TAs:

• building system uses 2 different security zones. Each zone has its own subordinate CA that signs the LDevIDs. Most devices only communicate within their security zone, however, some devices are allowed to talk to a device from another security zone via a commissioning process where authorization parameters are set. All devices get EST-provisioned with the 2 subordinate CA certs and the root CA cert. (In total: 3 CA certs), even those devices that would never use the CA of the "other" security zone.
  • in the above, one reason to include the root CA cert in the TAs is because RFC 7030 requires this (specifically it requires the "root" to be there in the CA certificates response)
• similar examples for 3 or more security zones

Based on above example, suppose we have a memory/code constrained Pledge that can use EST /crts only with 1 certificate (application/pkix-cert). It will get the subordinate CA of its own security zone, but not the root CA nor the CA of the "other" zone. So it can only authenticate devices from its own security zone, using its single TA.

• This Pledge cannot fully meet the requirements of EST RFC 7030 in the sense that it cannot get the "root CA" TA during the EST process, nor other TAs of other security zones.
• My assumption is that our draft modifies EST/EST-coaps to reduce the requirements on the Pledge i.e. getting only a single TA is okay because it's just as secure.
• This also implies that a Domain owner cannot assume that all Pledges will after enrollment have all the Domain TAs configured. Because, some constrained Pledges may store only one of the Domain's TAs.

Concluding: I would reject this issue, and close it. Doing it in a "proper" way leads to more additional complexity and code branches than anticipated.

[csosto-pk]

If there are multiple TAs then another issue is how would the pledge know which one he is supposed to use if it could only use one. +1 on not addressing this because of complexity.

[EskoDijk]

Based on above discussion; closing this issue - keep the existing solution of either returning one TA only (in case of application/pkix-cert format is requested by Pledge) or multiple TAs potentially (in case PKCS10-format is requested by Pledge)