Req: Support for self-signed certificates, optionable CRL check, and optimize WS communication

[cyriac83]

Hi there,

Thanks for integrating the WS feature into COAP. It helped us a lot to test our new protocol that's based on COAP and WS. We do have a few feature requests though:

1. Would it be possible to support self-signed certificates for TLS (maybe as a runtime option for applications that use the library)? It's noticed that self-signed certificates are not supported currently.
2. Would it be possible to make the CRL check for TLS an optionable step (again, as a runtime option for applications that use the library)? Currently, the CRL check is done always.
3. It's observed that when WS exchanges application data, the header and payload go out as separate TCP packets even when the application data is only a few bytes. Can this be optimized to send as a single TCP packet (of course, with some maximum limit on the application data size) to avoid header overhead?

Kindly consider these if you think it would improve the usability of the library. Thanks again!

Regards, James C.

[mrdeep1]

Would it be possible to support self-signed certificates for TLS (maybe as a runtime option for applications that use the library)? It's noticed that self-signed certificates are not supported currently.

When setting up the PKI Information, in the coap_dtls_pki_t structure, variable allow_self_signed can be set to 1.

Would it be possible to make the CRL check for TLS an optionable step (again, as a runtime option for applications that use the library)? Currently, the CRL check is done always.

When setting up the PKI Information, in the coap_dtls_pki_t structure, variable check_cert_revocation can be set to 0.

It's observed that when WS exchanges application data, the header and payload go out as separate TCP packets even when the application data is only a few bytes. Can this be optimized to send as a single TCP packet (of course, with some maximum limit on the application data size) to avoid header overhead?

This makes sense. It should not be that difficult to update coap_ws_write() to do this by creating a temporary output buffer for concatenating the 2 parts.

[mrdeep1]

Please try out #1261 to see if this fixes your TCP write issues.

As a further comment, on a client, if you set in the coap_dtls_pki_t->coap_dtls_key_t->coap_pki_key_pem_t structure the variables ca_file, publiic_cert and private_key to NULL as passed to the coap_new_client_session_pki() function, then the client then uses its own internal certificates in the same way that a web browser generally uses when using the https:// protocols.

The CoAP server then needs to understand that it is not to check the CoAP client's certificates, which is done when setting up the PKI Information, in the coap_dtls_pki_t structure, variable verify_peer_cert is set to 0.

[cyriac83]

Thank you for the fast response! I'll come back to this in a day or two and update.

[mrdeep1]

PR #1261 has now been merged into the develop branch for testing.

[mrdeep1]

@cyriac83 Can this be closed now?

[cyriac83]

Yes, please. Thanks for checking.

On Fri, Mar 8, 2024, 9:20 a.m. Jon Shallow @.***> wrote:

@cyriac83 https://github.com/cyriac83 Can this be closed now?

— Reply to this email directly, view it on GitHub https://github.com/obgm/libcoap/issues/1257#issuecomment-1985987924, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB3PT7NDCSRCNTM5XQBN553YXHQNTAVCNFSM6AAAAAA6EF3KM2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBVHE4DOOJSGQ . You are receiving this because you were mentioned.Message ID: @.***>