Support authentication of devices using X.509 certificates in the CoAP adapter

[mostafa-eltaher]

The CoAP adapter should support devices using an X.509 client certificate for authenticating.

[sophokles73]

I would suggest to also include support for raw public keys in this issue.

[boaks]

x509 - PR #816

"Long ago", I tried to implement it. In the meantime, the hono code base changed a lot, so I'm not sure, if that contains still useful ideas.

RPK - Issue #733

Contains some ideas about RPK.

For both, x509 and RPK, the validation in Californium is currently still "blocking/sync", so I'm not sure, if the validation could be postponed into the "naturally" none-blocking forwarding of the message.

[sophokles73]

@boaks

x509 - PR #816

"Long ago", I tried to implement it. In the meantime, the hono code base changed a lot, so I'm not sure, if that contains still useful ideas.

I took a look at your PR and I believe that it basically does the right thing(s). It would need to be adapted to the current state of the CoAP adapter but in general it looks quite good. Would you like to give it another shot?

[boaks]

I guess, that I will not have time for it until the end of this year ;-(.

[sophokles73]

@boaks Then how about I give it a shot? I can rebase and adapt to current CoAP adapter. WDYT?

[boaks]

Sounds good.

[boaks]

@sophokles73
@mostafa-eltaher

I started to implement a "none blocking" CertificateVerifier and RPK lookup. That's only the first step to get an initial support. The steps for handling multiple server certificates based on DNS/SNI or signature algorithms are not planned from my side for now. Also steps to make the "session cache" really cluster ready, are not planned (see Evolving the SessionCache ).

FMPOV, using expensive crypto-functions as x509 should therefore also use CID. Hopefully with the cid-load-balancing the cluster topic will be sorted out.

I hope, that approach works for you.

[boaks]

@sophokles73

I created a first PR for x.509 in californium which also supports a custom argument may be used for the device id.

About RPK support:
Does hono support a "credentials store" per tenant? If so it will be hard for RPK, because the RPK doesn't contain more information than its "global unique public key". If it's OK to do a "global credentials lookup", I will add the none blocking support for RPK next week as well.

[boaks]

I prepared a first PR #2629, which introduces x509 (again).