Discuss mailing list

[Jonah Aragon <jonaharagon AT gmail.com>]

I don't think I replied to this before, but I was meaning to.

You make some good points, I'm not sure how to get around some of them necessarily. This is why I was forming the WG, so we could have extended discussion on how to correctly implement a CA design before we send it here as a proposal. 

If you have ideas or more things to add I'd love to have you join us so we can work some of it out. Maybe an API based system would function better, I was simply thinking along the lines of that being a single point of authority, but it does appear it's designed that way anyways. I just wanted to mitigate some of that.

Maybe we do just need a centralized root for OpenNIC that will issue all certificates. Hopefully we can address the best way to go about this.

Jonah

On Jan 6, 2017 12:41 PM, "Amunak" <amunak AT amunak.net> wrote:

The issue is that you issue intermediate CA certs for, say, 4 years. Now there is need to transfer the TLD to a new operator, or the old one disappears / stops issuing the certs or something and you need to make a new one. Fine, but the old one still works, and you can't just reject it as that would invalidate all the users' certs. Same goes for any other issues with the TLD operator (even just him leaking the private key accidentally, getting hacked, whatever).

With DNS none of this is an issue since it's easy to "cut off" an operator if the need arises (just remove it from the list and perhaps send an informational email). And only a tiny portion of users is affected. And even existing users (provided that the operator - even if rogue in any way - still provides most replies correctly) are not too affected and have time to switch over.

But certificates are centralized by design. If you want to make issuance, signing, etc. secure you need to have the root cert in a single place, controlled by single entity (that is made of several trusted individuals). You need stuff like HSM that mandate logging, allow auditing and don't allow the key(s) be extracted. There is unfortunately no system in place where several individuals would hold the keys and some kind of multisig algorithm that would allow x out of y trusted people to sign (new) valid certificates. Which means that at least the root cert must be controlled in a centralized fashion (which I think we all agree on as there is no way around that as far as I know).

As for the intermediate certs you can have policies and procedures for the TLD operators but there is no way to enforce those. Or even check whether they are following them until something goes horribly wrong (and you potentially have to revoke the intermediate cert which means breaking websites and other services for tons of unsuspecting people with no time to react). You cannot control whether the list of certs signed/issued by them is complete, etc. And that's why I think it would be wise to not directly give TLD operators full access to the intermediate certs. I would actually argue that whoever does handle those certs (and the root cert) should ideally be different people from the TLD operators (if we have people capable of handling this) so that there is less room for abuse.

Why less abuse? Because this creates a level of decentralization: TLD operators have immense power. They can silently point (even specific) people to different targets (websites) than they were asked to be on. Now if you combine that power with the power to issue valid certificates for that website (with no way to see that it happened - hence I argue for full certificate disclosure) you are giving even more easily abusable power to those people.

Now I don't think any of our current TLD operators would actually do this, but it would be a way to mitigate possible future issues and it would also make sure that we can enforce certificate signing/issuance policies.

Amunak

Dne 05.01.2017 v 15:57 Jonah Aragon napsal(a):

Forgot to mention, I think it would still be a good policy for a list of issuances from each operator be made publicly available.

We're not just going to give each operator an Intermediate and have them do what they will completely, we'll have to impose some guidelines for Intermediate holders to follow for sure, with the penalty being revocation at the root... Publishing a list of issuances and revocations is definitely something that every party should do.

Jonah

On Jan 5, 2017 8:52 AM, "Jonah Aragon" <jonaharagon AT gmail.com> wrote:

Well the idea behind intermediate CA certificates for each operator is that they would be able to be revoked if the need arises, which should mitigate your concerns.

Better to not rely on a centralized source for certificate issuance, in my opinion. That goes for all OpenNIC projects, they can't rely on a single process.

Jonah

On Jan 5, 2017 8:47 AM, "Amunak" <amunak AT amunak.net> wrote:

While I'd say it is, there should still be auditable (and ideally public) list of operators' actions regarding signing certificates and such - I would not give the private keys to intermediate certs to TLD operators - I would only allow them to use some API for signing (which they could use in their application for issuing certs for verified domain owners). This also helps for cases when TLD operator changes and such and greatly mitigates risks with bad private key handling.

Dne 05.01.2017 v 6:31 spaesani AT mail.com napsal(a):

"we can validate domain ownership"
"offer https support.."

I'd say that'd the tld operator's prerogative.

Wednesday, 04 January 2017, 01:28PM -05:00 from Jonah Aragon jonaharagon AT gmail.com:

Hello all,

I feel there's a strong need for a Certificate Authority under OpenNIC control so we can validate domain ownership and offer HTTPS support for domain holders without the need for self-signed certificates. Ideally this certificate would be installed as a Trusted Root Certificate in operating systems by every user wishing to join the OpenNIC network, which doesn't seem like too much of a stretch seeing as we already get users to change DNS settings manually.

There's many obvious benefits to setting a system up. It would allow for secure communications between users and OpenNIC enabled servers, and provides a level of trust that the site they're viewing is legitimate, as certificates will only be given to the domain holders, more on that below. Because only the domain holder could possibly have the key, it would mitigate threats of a rogue Tier 2 server changing domain records, maliciously or not. 

I think the best way to go about this would be creating a OpenNIC Root CA and using it to sign Intermediate CAs to each TLD operator. Certificate issuance would fall on the TLD operator's responsibility, either by issuing along with registrations automatically or having a certificate request section in their various control panels, etc. A drawback to this would be the trust needed in TLD operators to only issue legitimate certificates, but we already put a level of trust in Tier 1 operators anyways as they essentially make up the root of our system, so it isn't much of a stretch. I still think this method would work best because there isn't any better person to vouch for a domain's legitimacy than the registrar itself, as opposed to a centralized certificate request system.

If we were to do this, we'd primarily need to think of a system we all trust to issue the Root CA itself, because allowing a single person to issue it and hold the keys would hand them a lot of power, require a lot of trust, and it wouldn't really fit with the decentralized transparent faith of OpenNIC. I'm not sure of a surefire method to solve that particular problem, so I'd love to hear suggestions...

I know some people are already working on a CA for the network, so we could definitely use their help or ideas. Basically I want to make a solution to this problem official and prominently featured to entire as many users on the network as possible are using it, both end-users and server owners.

I'd love to hear all your thoughts on how we can accomplish this.

Jonah

--------
You are a member of the OpenNIC Discuss list.
You may unsubscribe by emailing discuss-unsubscribe AT lists.opennicproject.org

--------
You are a member of the OpenNIC Discuss list. 
You may unsubscribe by emailing discuss-unsubscribe AT lists.opennicproject.org

-------- You are a member of the OpenNIC Discuss list. You may unsubscribe by emailing discuss-unsubscribe AT lists.opennicproject.org

--------
You are a member of the OpenNIC Discuss list. 
You may unsubscribe by emailing discuss-unsubscribe AT lists.opennicproject.org




--------
You are a member of the OpenNIC Discuss list.
You may unsubscribe by emailing discuss-unsubscribe AT lists.opennicproject.org