verax wrote:The main advantages I see to splitting the password instead of the key:
1) It's easier to apply generic redundancy setups to a couple of chars in a string than it is for a fragment of a key. It's also easier to memorize.
2) If part of the key is lost, that's the end of it. If part of the password is lost, we could probably collect the rest and brute-force it in an emergency
3) I can't think of an easy way to re-assemble the key without someone ending up with the complete key. With the password we just have each keyholder type their keys in turn into a tmux that everyone's holding. Yes, I know that that's not exactly secure, but it's better than someone saying "I promise I deleted the key when I was done"
That's fair, option 2 would work either way, so we could definitely split a password instead. I just wish there was a more secure way to assemble all the pieces together... The other main downside would be during the creation process, it'd be hard to confirm the person creating the key and splitting the password among the holders (I'm assuming myself, but not necessarily. That's a discussion for another time...) deleted the entire password after distributing that information.
Just for reference: We are only talking about the Root Private Key, right?
As a model, we a Rootadmin should generate a Root Certificate on a air-gapped computer. The RC has to be kept very
secure obviously. I agree that the it should be encrypted, I suggest AES-256-CBC. Now for redundancy reasons, the encrypted copy should be transferred to at least two other Rootadmins. The password should be split up into three pieces and each piece will be transferred to three different key holders, like it was already described.
The Root Certificate should issue an Intermediate Certificate. (For that process, three key holders of different groups have to transfer their fragment to a Rootadmin. The Rootadmin will delete the decrypted private key as well as the fragments later, but keep his copy of the encrypted private key.) The IC private key has to be kept secure as well, however, it also has to be kept operational
, and by that I mean on a signing server
that has Internet access. Like Nadia and Jonah already mentioned, this signing server should implement the ACME protocol
Yes, we're looking into various operating systems and platforms we could use to ensure everything's secure. I'm not 100% sure whether or not we'll go with ACME, for reasons I'll post elsewhere soon, but there will definitely need to be online intermediate signing servers. The good thing is (as you mentioned below) we can revoke any of them if need be.
pfo wrote:A sysadmin should be in charge of the signing server. Ideally, this wouldn't be a single person, but multiple, at least two, but as we would probably not meet personally, a single person has to be sufficient. In case the sysadmin becomes inactive without passing the authorization to someone else, the RC will just revoke his IC and issue a new one to a new sysadmin. In case the sysadmin betrays us and issues certificates that shouldn't have been issued, the same happens.
We could potentially have multiple signing servers concurrently in operation (with multiple ICs, "OpenNIC X1 Signing CA," "OpenNIC X2 Signing CA," etc.). If we went with an ACME implementation this would be less necessary (but still possible, with multiple signing servers for example), but another solution I thought of was granting each Tier 1 operator an IC so they could provide certificates with their domains upon registration (user submits a CSR, etc.). There are some benefits (and downsides) to that situation that I'll start another thread about to outline.
pfo wrote:Rootadmins, sysadmins and key holders should all be separate people. We will need three Rootadmins, one sysadmin and nine key holders. That are thirteen people who have to be trustworthy, do we have enough in the OpenNIC community? I would be willing to act as a key holder or a rootadmin.
I'm thinking we could (should) go with T1 ops for most of these roles, since they already have a large amount of trust placed on them already.
pfo wrote:Now there are a few critical transferrals here: The encrypted root key hat to be transferred from the first Rootadmin to two other Rootadmins, the first Rootadmin has to transfer the password fragments to the key holders, and the key holders have to transfer their fragment back to a Rootadmin in case a new certificate is to be issued.
pfo wrote:PGP is the tool we should use for encryption and signing. Now how do we ensure trust? If we agree that talk.geek is a secure channel, the receiver would have to message the sender on talk.geek with a signed PGP message claiming "Hello, I am $NAME on talk.geek, send me the encrypted message here".
We'll definitely use PGP, it's already in use for a lot of stuff in the community already. Assuming it's done well we don't even need to trust
talk.geek per se, since talk.geek wouldn't be able to read the messages. We will have to establish multiple forms of identification to verify each user's PGP key however, across a lot of different platforms. For example I'd have to tell you these are places you can find my PGP key:
Since you all likely know me on IRC, you'd be able to ask me on IRC @jonaharagon on #moderntld or #opennic and I'd be able to confirm the above information, and you'd also be able to ask me on the mailing list. With me being able to identify myself across that many third party sites and platforms, you can reasonably assume the PGP key linked across those sites is indeed mine after investigation. Other keyholders should probably be able to provide an identity assurance identical or better than what I've outlined here to be considered trusted.<edit>Also
, since the PGP keys have email addresses associated with them, you should be able to
- Email the addresses listed on the key to ensure they belong to that recipient and they can decrypt it; and
- Check whether or not the email addresses are associated with the emails that trusted users have been using to send messages to the Mailing List.
pfo wrote:Here is what I have in mind:
There are thirteen people: Rootadmin1, Rootadmin2, Rootadmin3, Sysadmin, Keyholder1, Keyholder2, Keyholder3, Keyholder4, Keyholder5, Keyholder6, Keyholder7, Keyholder8, Keyholder9.
. . [cut off long list] . .
This is a good plan, replacing steps 1-12 with more stringent trust like I outlined above.The main issues
are with steps 20 and 33, because they require a lot of trust in the root admin to delete said information. Assuming I'm doing this initial signing, I could tell you truthfully that the information was deleted, but you don't necessarily have a reason to believe that, and I can't necessarily offer any proof of that fact as far as I can think of. That's what mainly requires more thought to be put into, I'm not sure what the ideal solution would be.