Feature Request: Support for RFC 8410 Ed25519 certificates and keys about nebula HOT 6 CLOSED

Hi,

Thanks for this clear explanation.

I'm working around Nebula and I would like to know if that vault plugin is also open source or not.

Thanks!

from nebula.

Great questions!

When we started writing nebula we were using x509 to do all this. One of the early pain points was the lack of official RFC or stdlib support for ed or x25519 key material. We hacked around that for nebula-cert and our internal CA, but despite the fact it was x509, nothing could work with these certs out of the box. The thought of upstreaming support into openssl or vault or any of the other x509 tools just seemed very unlikely since it was such a hack.

We then turned to how to properly encode the details we needed without abusing the x509 spec too much. This was more or less "how can we make openssl x509 -text -in ... output meaningful information". It was largely a losing battle since our concepts don't map too well to what x509 is trying to accomplish, and if they did, the tooling wasn't built to be aware of it.

Then we looked at the size of the certs we were generating. The ASN.1 structure was fairly bloated and carried a lot of dead weight for our use case. If we want nebula to work in the most pessimistic networks, where the MTU is the minimum, then we needed a more compact certificate structure with fewer wasted bits to give room to the details that matter, like groups or ip address assignment.

Now with proper support for ed* in golang stdlib and x509, we could move half of this to x509 if we wanted but that only solves the root certificate story. Client certs use x25519 since their main function is the diffie-hellman used over that key material to create symmetric keys per tunnel. The root certs use ed25519 since their main function is to sign the client certs. There does exist a method to transform ed* to x* but we met up with Trevor Perrin to discuss it and the result was "don't do that, wait for ristretto". We never gained enough confidence to make that move but we have gained enough confidence in our current tooling that we lost our desire to go this route.

As for tooling, we publish the cert package which is meant to be used as a library for other tool builders. nebula-cert uses this to do all the cert creation, signing, and verification on the command line. Slack also uses it in a vault plugin, which is used to authenticate a node with vault, but it would be fairly simple to make a plugin that enables vault to sign nebula certs.

A good TLDR might be that x509 may be an appropriate format for nebula to use but the x509 ecosystem is too far behind on current crypto and most tools lack full support for them to be of any use.

from nebula.

Ah, I didn't realize different algorithms were used in different spots. I believe RFC8410 also handles x25519 in x509, but that doesn't seem to be in the stdlib yet. If it was do you think supporting x509 would be more feasible? I understand the encoding problem and the x509 bloat, but is this a show-stopper? I definitely think it would be cool if we had proper ASN.1 fields for everything but, as you've said, existing tools wouldn't really be able to leverage them, hence my suggestion of stuffing a URI into the subject.

You're correct that you could make the tooling work, but I'd like to explore this route first. Since much of the tooling I work with is in Go, if the stuff Nebula needs was available in the Go stdlib, than I could get any other tooling in Go to support it with relative ease, even if the rest of the x509 ecosystem is lagging.

from nebula.

I think it would lower the barrier but I personally don't see what feature it actually adds. Mutating x509 properties for nebula is certainly do-able but hides away information in fields that don't appropriately match their original intent.

When we ditched x509 we considered using ASN.1 directly. Ease of use for ASN.1 lost to basically any other tool though. Our current cert format is using protobuf which gave us peace of mind while we moved nebula through R&D to production and will hopefully pay future dividends if/when we need to rev the certificate structure.

Since you work in go a lot, we formulated the cert library to be easily importable and usable as a library

import(
    "github.com/slackhq/nebula/cert"
)

All the parts should be there for you. Marshalling/unmarshalling in a few different formats. Signing, root certificate pools, verification, etc.

from nebula.

The primary goal I have is automated certificate provisioning based on identity in an SSO system, with the potential for tying in groups, etc, in that system into Nebula. Another part is then also automating provisioning of certificates for servers/services which wouldn't be SSO based, but I haven't figured out how I'd like that to work, but ideally it would be a similar setup.

This is all possible using the nebula-cert tooling, but it still requires a bit more work than if I could use x509. The primary thing I'd like is a CSR-like process, which is doable with the nebula tools, but non-trivial. There's other features in x509 I'd like, but are less important.

I do see issues with re-using existing fields for other purposes though (eg: max length would make using a URI in the CN not scale) so I can understand why you went with protobuf.

I did explore previously for methods of using x509 for this but it largely seems to be relegated to largely-unsupported mechanisms like rfc5755, as you mentioned previously. It's basically the same issue as getting your own OIDs and/or using custom fields in the ASN.1 format.

I'll attempt to see how well I can automate things the way I like, but unfortunately I imagine it's going require much more glue than I'd like so I may end up needing to find something else. If you have any advice, I'd be glad to get another perspective.

from nebula.

Closing this issue out as there are currently no plans to support X509 / ASN.1 certificates.

from nebula.