Closed EskoDijk closed 3 years ago
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"
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?
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].
[1] https://github.com/anima-wg/constrained-voucher/issues/72 [2] https://github.com/notifications/unsubscribe-auth/ADCZGQJ2QOISJTUSCA3A2DTS222MTANCNFSM4WKQAIQA
idea:
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.
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:
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.
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.
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.
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)
The combination of constrained BRSKI + constrained (CoAP) EST works well, however it has 2 distinct disadvantages:
(*) 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:
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.