Intermediate Certificate Operation

The purpose of the Encryption Working Group is to devise an official Root Certification Authority system for issuing server certificates to OpenNIC domains and user certificates to OpenNIC members.

Moderator: Encryption WG

JonahAragon
T1 Operator
Posts: 27
Joined: Mon Dec 05, 2016 4:22 pm
Location: Minnesota
Contact:

Intermediate Certificate Operation

Postby JonahAragon » Wed Feb 15, 2017 11:15 pm

We've talked a bit about how to handle signing server certificates, but not fully in detail.

There's a few options I can see working out...

1: We could distribute Intermediate Certificates to each TLD operator (either 1 per registry ("go.libre Signing Certificate", "ModernTLD Signing Certificate", etc.) or 1 per TLD (".o Signing Certificate", ".geek Signing Certificate", etc.)) possibly/probably with name constraints (although I'm not sure how widely supported those are, but extra precautions are welcomed) and of course strict auditing. We place a decent amount of trust on Tier 1 operators and registrars already so granting Intermediate Certificates doesn't seem too much of an added risk.

Benefits to this option would probably be ease of deployment for us and good usability for end-users, as certificates could be signed as a part of the registration process.

The major downside I can think of is more of an issue with OpenNIC as a whole: nobody has enough time to implement anything or at least, doesn't want to commit the time, so relying on various server operators to add certificate management systems to their servers would likely ensure this project never gets off the ground. Which is unfortunate because otherwise I like this option.

2: Alternatively, we could setup an ACME server (same protocol and clients as Let's Encrypt uses) so users can receive certificates using the certbot/letsencrypt CLI tool (with the --server flag). There'd still be strict auditing so we could verify the server administrator was validating correctly.

Benefits would be a much higher likelihood of adoption, as it doesn't rely on anyone (other than our initial setup) to start signing certificates.

A downside would probably be the limitations on the ACME protocol. It only signs certs for short periods of time, which is somewhat more secure, but makes it more difficult in specific situations where you can't easily update your certificates automatically (cPanel users, for example, or most other web panels in general). Also, you can't create wildcard certificates. Also, it centralizes the issuance system to a single point of signing, which not only creates uptime issues, but doesn't seem to be completely in line with OpenNIC ideas. That could somewhat be solved by multiple servers/multiple ACME server sysadmins, but not completely.

Additionally, ACME is currently mostly "beta" software, and the only server implementation that currently exists at all is the relatively poorly documented Boulder server, which would require extensive reworking (and knowledge on our part of the Go programming language, for that matter). All of this is possible, just difficult.

3: We could go with a hybrid of the two options. Setup an official Boulder/ACME server for easy propagation of SSL across all OpenNIC domains (as Let's Encrypt has with relative success on ICANN), and distribute intermediate certificates to registry operators that request them.

If we went with this option, we could ensure widespread SSL isn't held back by programming apathy, and it would cover the needs of more advanced users, who would hopefully be able to request longer-term certificates or wildcard certificates from the TLD operators as needed.

---

Any way we go there would be strict auditing and revocation systems added, likely using some form of Certificate Transparency and OCSP/CRLs, so trust isn't a major issue either way.

pfo
Posts: 11
Joined: Tue Feb 07, 2017 10:03 pm

Re: Intermediate Certificate Operation

Postby pfo » Thu Feb 16, 2017 11:27 pm

Those are very good detailed thoughts, thank you for outlining them. I think we should use the hybrid option.

JonahAragon wrote:We could distribute Intermediate Certificates to each TLD operator (either 1 per registry ("go.libre Signing Certificate", "ModernTLD Signing Certificate", etc.) or 1 per TLD (".o Signing Certificate", ".geek Signing Certificate", etc.)) possibly/probably with name constraints


We should go with one certificate per registry, because it is possible, although not probable at this stage, that there will be more than one registry per TLD. Like you suggested, if a registry requests a certificate the root will issue one.

JonahAragon wrote:A downside would probably be the limitations on the ACME protocol. It only signs certs for short periods of time, which is somewhat more secure, but makes it more difficult in specific situations where you can't easily update your certificates automatically (cPanel users, for example, or most other web panels in general). Also, you can't create wildcard certificates.


My initial guess was that this would be easily re-configurable. Issuing for 3 months or for 4 months, who cares, it should be a config option in Boulder. However, I didn't find anything quickly and am lacking the time to look into the matter deeper. I would still imagine that it can be configured.

JonahAragon wrote:Also, you can't create wildcard certificates.

This is most probably not easily configurable, however, if someone would commit some time into writing an implementation for that, I'm sure Boulder can be modified to support this feature. Again, I unfortunately do not have enough time for this and also no experience in Go. Perhaps the project should start without wildcard support and if someone implements this feature, it will be added. That could take years, so it would not be good to wait.

JonahAragon wrote:Also, it centralizes the issuance system to a single point of signing, which not only creates uptime issues, but doesn't seem to be completely in line with OpenNIC ideas. That could somewhat be solved by multiple servers/multiple ACME server sysadmins, but not completely.


I do not understand. Multiple (at least two) signing servers are a good solution, what is the problem?

JonahAragon
T1 Operator
Posts: 27
Joined: Mon Dec 05, 2016 4:22 pm
Location: Minnesota
Contact:

Re: Intermediate Certificate Operation

Postby JonahAragon » Thu Feb 16, 2017 11:43 pm

pfo wrote:My initial guess was that this would be easily re-configurable. Issuing for 3 months or for 4 months, who cares, it should be a config option in Boulder. However, I didn't find anything quickly and am lacking the time to look into the matter deeper. I would still imagine that it can be configured.

pfo wrote:This is most probably not easily configurable, however, if someone would commit some time into writing an implementation for that, I'm sure Boulder can be modified to support this feature. Again, I unfortunately do not have enough time for this and also no experience in Go. Perhaps the project should start without wildcard support and if someone implements this feature, it will be added. That could take years, so it would not be good to wait.


This is the main problem in general with Boulder. It's not well documented for production use because it was built more or less specifically for Let's Encrypt, so there isn't easy configuration, installation, etc. And nobody I've spoken with as of yet has the experience with Go that would be required to modify it to our needs. I'd definitely be open to learning it (good experience), but it would require a lot of time to figure out Go and the intricacies of Boulder, as it's a relatively large project.

Upon first impression it looked relatively easy to change, but I'm concerned it will take a bit more effort than I originally thought.

pfo wrote:
JonahAragon wrote:Also, it centralizes the issuance system to a single point of signing, which not only creates uptime issues, but doesn't seem to be completely in line with OpenNIC ideas. That could somewhat be solved by multiple servers/multiple ACME server sysadmins, but not completely.


I do not understand. Multiple (at least two) signing servers are a good solution, what is the problem?


I suppose it'd be fine, and definitely possible if we went with a more hybrid approach, as server ops would be able to run their own Boulder servers as well (perhaps if we have the chance to modify it, we could make it easier for more admins to install it on their own).

I agree with your opinion, I think it would be in our best interest to grant Intermediates to registries and other parties that could expedite the process with close integration with their respective registry systems, with Boulder being a fallback since such systems wouldn't be implemented right away.

pfo
Posts: 11
Joined: Tue Feb 07, 2017 10:03 pm

Re: Intermediate Certificate Operation

Postby pfo » Thu Feb 16, 2017 11:57 pm

JonahAragon wrote:Upon first impression it looked relatively easy to change, but I'm concerned it will take a bit more effort than I originally thought.


Even if it will take time, we can still start off with a normal Boulder instance, three-month-certificates are not the end of the world. If someone finds out how to change it, the time frame will be expanded.

If you want to prepare for prod, you can already try to set up a signing server and get the IC afterwards. If there are problems, we can shoot them down one by one and later add functionality (extended time period + wildcard support). I suppose a Github fork would be appropriate, then others can help and every one is at the same level.

JonahAragon
T1 Operator
Posts: 27
Joined: Mon Dec 05, 2016 4:22 pm
Location: Minnesota
Contact:

Re: Intermediate Certificate Operation

Postby JonahAragon » Fri Feb 17, 2017 12:04 am

pfo wrote:
JonahAragon wrote:Upon first impression it looked relatively easy to change, but I'm concerned it will take a bit more effort than I originally thought.


Even if it will take time, we can still start off with a normal Boulder instance, three-month-certificates are not the end of the world. If someone finds out how to change it, the time frame will be expanded.

If you want to prepare for prod, you can already try to set up a signing server and get the IC afterwards. If there are problems, we can shoot them down one by one and later add functionality (extended time period + wildcard support). I suppose a Github fork would be appropriate, then others can help and every one is at the same level.


I was referring more in general to configuring everything, not just specifically the registration times. There's likely a lot of work to be done outside of that.

I've forked it on GitHub so we can work on development specifically for our needs: https://github.com/ModernTLD/boulder -- I'm going to get caught up on Go and then start contributing, but other contributions are welcome in the meantime.

Sometime this weekend I can setup a development/staging server to run the changes we make, make sure everything's going well.

pfo
Posts: 11
Joined: Tue Feb 07, 2017 10:03 pm

Re: Intermediate Certificate Operation

Postby pfo » Sat Feb 18, 2017 3:33 pm

Would you add me to the repository? My name on Github is pfo as well.

Do you have a list of specific things to do?

JonahAragon
T1 Operator
Posts: 27
Joined: Mon Dec 05, 2016 4:22 pm
Location: Minnesota
Contact:

Re: Intermediate Certificate Operation

Postby JonahAragon » Sat Feb 18, 2017 11:26 pm

pfo wrote:Would you add me to the repository? My name on Github is pfo as well.

Do you have a list of specific things to do?


Added, look here: https://github.com/ModernTLD/boulder/invitations

I don't yet, I have to take a closer look at what is and isn't finished, when I get the time.


Return to “Encryption”

Who is online

Users browsing this forum: No registered users and 0 guests