Should we support Certification Chain in Leshan v2.0 ?

[sbernard31]

This issue aim to discuss about supporting Certification chains in Leshan v2.0
This was triggered by #1708.

Some facts :

• Leshan v1.x aims to support LWM2M v1.0.x
• Leshan v2.x aims to support LWM2M v1.1.x
• In LWM2M v1.1.x, "Public Key or Identity" Resource should only store the client certificate. (not the whole certificate chain. And only support DER encoding. LWM2M-v1.1.1@transport§5.2.8.3. X.509 Certificates.
• Since LWM2M v1.2.0, still limited to client certificate (not chain) but add support to PEM encoding. LWM2M-v1.2.1@transport§5.2.9.3. X.509 Certificates
• Since LWM2M v1.2.1, finally add support to certificate chain using PEM encoding. LWM2M-v1.2.1@transport§5.2.9.3. X.509 Certificates

This modificationsin LWM2M was mainly motivated by this discussion : OpenMobileAlliance/OMA_LwM2M_for_Developers#502

to prepare for this, Leshan client library can already use certificate chains in a backwards-compatible way.

Maybe we should consider to support that but I don't think backwards-compatibility is a good argument. (but maybe I didn't get you point)
FMPOV, a LWM2M client v1.1 does support PEM or certain chain. So a LWM2M server v1.2 should only send Certificate (not chain) in DER encoding.

Until now we didn't integrate LWM2M v1.2 feature in Leshan v2.x because this is out of scope.
I don't know if we should make an exception here ? If we decice we should we need to decide how ? (maybe this should not allowed by default)

[sbernard31]

@jakubsobolewskisag do not hesitate to describe in more detailed way why you need that 🙏

[eliasweingaertner]

I strongly would vote for making an exception. We see customers today already experimenting with partial chains, because DTLS allows that.

The gap in the LWM2M specification was that the discussion in there left room for speculation, and as you wrote, you could only bootstrap a single certificate to the device. There is no reason not to allow this even today.

[jakubsobolewskisag]

@sbernard31
From the bootstrap server perspective, what we write to device Security object is just a byte array. 1.0 and 1.1 specification mandates this byte array to be single DER certificate, but it's not verified or enforced in any way in the Leshan bootstrap server stack. We just write a byte array.

Considering above, I can argue that bootstrap server stack already supports PEM certificate chains, plus whatever future format someone will come up with. And don't get me wrong - I believe that this is great! It gives us (server providers) some sort of freedom and flexibility. If our customers ask us to support PEM certificate chains, we are able to implement it today (using Leshan) even if it violates 1.1 LWM2M specs a bit. And I believe that the single certificate limit of 1.0 and 1.1 is very unfortunate/artificial/bad.

The change I proposed in my PR is only about the client stack. It allows you to build a custom LWM2M client that will be able to send certificate chain when connecting to the server. You don't have to use PEM chain - previous format works perfectly fine, but you can implement a client that does that. I haven't changed a Leshan demo client implementation for that reason - it's exactly as it used to be. I just want to be able to implement my own version of the client using Leshan client stack.

And the main reason I created the PR is that we actually need a client to test PEM chains and it would be much easier to refer to main Leshan repo than to create our custom fork and maintain it separately. Aspecially that this change doesn't break anything, just gives us more flexibility and brings us one step closer to 1.2 features.

And I think it's always better to contribute the code with features that we need than to develop/maintain a custom private fork.

[sbernard31]

(don't worry if I first sight it looks like I'm against this changes. This is not the case I just try to have a clearer picture of that)

@eliasweingaertner thx for feedback 🙏

The gap in the LWM2M specification was that the discussion in there left room for speculation, and as you wrote, you could only bootstrap a single certificate to the device.

The specification seems clear and author confirms that we can only pass Certificate (and not Certification Chain) until 1.2
But I also agree that was a bad choice from OMA (hopefully they fix it in 1.2.1)

There is no reason not to allow this even today.

A reason could be that standard is about interoperability. And a server which try to send Cert chain to v1.1 client does not follow the spec and so could break interoperability.
For more detail about issue generated by being to liberal : https://github.com/eclipse-leshan/leshan/wiki/How-Leshan-should-behave-with-Non-Compliant-Implementations-%3F

@jakubsobolewskisag thx for detailed explanation 🙏

but it's not verified or enforced in any way in the Leshan bootstrap server stack. We just write a byte array.

It is expected this is checked by ConfigurationChecker (but there is maybe a bug 😅 )

And I believe that the single certificate limit of 1.0 and 1.1 is very unfortunate/artificial/bad.

I agree that's why I report that to OMA but unfortunately only fixed in 1.2.1 (I already explained rational above about trying to strictly follow the spec as much as possible)

I just want to be able to implement my own version of the client using Leshan client stack.

I understand the need. We will try to find a solution.
I would like to avoid that this behavior was the default one. (or tolerate by default)

And the main reason I created the PR is that we actually need a client to test PEM chains and it would be much easier to refer to main Leshan repo than to create our custom fork and maintain it separately. Aspecially that this change doesn't break anything, just gives us more flexibility and brings us one step closer to 1.2 features.

I get your use case now. Thx for clarification.

And I think it's always better to contribute the code with features that we need than to develop/maintain a custom private fork.

I really appreciate that.
I will look deeper at your contribution. I come back to you quickly.

[sbernard31]

I think that maybe we can go go :

• with most of the code supporting certificates array / certificate chain
• default behavior of ConfigurationChecker (bootstrap server) and DefaultBootstrapConsistencyChecker (client) ensure that only 1 certificate is present and DER encoding is used.
• possibility to easily set a custom BootstrapConsistencyChecker and ConfigurationChecker which could allow Certificate Chain and PEM encoding.

The main issue is that there is no easy way to check that a Certificate is using PEM or Der Encoding.
The only thing I found searching on the web is :

• Check if the first byte is 0x30 (ASN.1 Sequence) for DER
• Check if file start with "-----BEGIN CERTIFICATE-----\n" for PEM

That 👆 + "CertificateFactory succeed to decode" seems to be the best way without using external library like bouncy castle.

Probably I will need to refactor a bit ServersInfoExtractor too.

You will probably think I'm a bit silly to engage so much work just to check that Leshan strictly follow a bad/artificial rules from LWM2M v1.1 😅

[jakubsobolewskisag]

@sbernard31 I think it's a very good approach :)
I just have one question - in this case should I close my PR or do you want to keep/extend it? Do you need further help with this topic?

[sbernard31]

in this case should I close my PR or do you want to keep/extend it?

I don't know yet. I will probably reuse some part of your code. So let's keep it open for now.

Do you need further help with this topic?

At least, I could need helps about reviewing code and testing it.
If you want to contribute code, I can also set-up a branch with the idea and let you continue to work on it.
As you prefer, let me know 🙂

[jakubsobolewskisag]

I'll be happy to review the code and do some testing. I will also push what I already implemented in this topic so you can decide what parts to keep.

[sbernard31]

Thx again @jakubsobolewskisag for code contribution.

On my side I push some code in your PR : #1708 (comment)

[sbernard31]

@jakubsobolewskisag should we close this issue ? or maybe I wait you confirm the new API fit your needs ?