Root Key Storage

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:

Root Key Storage

Postby JonahAragon » Sat Feb 04, 2017 12:14 am

We'll need to devise a system for storage of the Root CA's private key. This key should ideally be kept in a secure and trusted environment. I've thought of a few options I'll list below, but this isn't necessarily the only solutions we can take.

Option 1

By far the simplest solution would be moving the key to a long-term storage medium (tape, Blu-Ray, etc.) and locking that media in an environmentally secure location, such as a bank vault. We could encrypt the key beforehand for added security. This has the benefit of being a relatively secure storage solution, but does not incorporate any redundancy. If the key was lost or the keymaster disappeared, we would no longer be able to sign as the root. In addition, it places a lot of trust on a single keymaster, who would be able to sign as the Root CA.

A variation of this option could be to create multiple copies of the private key and distribute them to multiple keymasters. This solves the redundancy issues but not the trust issue, in fact it creates a need for trust in EVERY keymaster, since any keymaster could sign new certificates as the root. Additionally, it would be hard to ensure the keys are stored in a safe location.

In my opinion, this is not the way to go.

Option 2

This method involves splitting the private key into multiple parts and distributing PGP encrypted copies of each part to one (or more) person(s):

Image

This method ensures no single person has the ability to sign certificates. In a hypothetical situation where the key is split into Parts A, B, and C, and two copies of each part are sent to trusted keyholders (for a total of 6 keyholders), at least 1 person from Groups A, B, and C will be needed to sign new certificates. During signing, 1 person from each group will send their parts to the "keymaster" (or, whoever will be signing the certificate), who will be trusted to:

  1. Receive and decrypt each part on a secure (offline, air-gapped, possibly dedicated computer)
  2. Sign the new certificate
  3. Delete the private key when finished

This places a lot of trust in the keymaster. But I believe that any keymaster is indeed already trusted, if the keyholders gave the parts to them in the first place.

This solution solves the redundancy issues, as multiple people will have Part A, Part B, ..., Part n stored. It also solves trust issues as no single person will hold the key, except when trusted to hold it (for signing purposes) by keyholders from each group. Additionally, as no single person will hold the entire key, compromises are unlikely, as a single compromise of one part does not reveal the entire key. (That being said, physical security is still important, as if all parts are compromised the key will be lost). We can split the key in a virtually unlimited number of parts across an unlimited number of people.

The primary issue with this plan would be that if every member of Group A (Part A holders) were to disappear, we would no longer be able to sign.

The keyholders would likely be Tier 1 operators, as they are more likely to remain stable members in the community, but exact criteria have yet to be determined.

Other ideas would be very helpful!
Attachments
keymaster1.png
keymaster1.png (20.46 KiB) Viewed 6574 times

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

Re: Root Key Storage

Postby pfo » Tue Feb 07, 2017 11:19 pm

I like Option 2 better than Option 1. Option 2 is also not ideal, however, I do not have a better idea currently. I'll thing about other concepts though.

One way to prevent the keymaster from issuing certificates that he should not have approved of is making every signature public (It will not prevent him per se, but if a bad signature get's public, the keyholders will not provide him with the parts anymore). This is called Certificate Transparency. I am no expert on the topic, but I can provide a few links:


To implement the concept of CT we would need a log server of our own, since the other logs would probably not accept our root certificate.

As I plan to contribute more to this topic, I request to be added into the Encryption WG.
Last edited by pfo on Sat Feb 11, 2017 5:46 pm, edited 1 time in total.

verax
Site Admin
Posts: 30
Joined: Mon Jan 18, 2016 3:16 am

Re: Root Key Storage

Postby verax » Sat Feb 11, 2017 6:52 am

I'll offer an alternative option: encrypt the key and have the password split up. There are schemes that can be used so that only a certain number of the keyholders need to be present, that way someone can be away without blocking everything, but still requires consensus to function.

Nadia
Posts: 4
Joined: Tue Jan 24, 2017 5:45 pm

Re: Root Key Storage

Postby Nadia » Sat Feb 11, 2017 5:00 pm

Take a look here - https://letsencrypt.org/certificates - this is similar to what Jonah's suggesting. A more complete implementation using certbot is found here - https://github.com/certbot/certbot As for the password being dividing among [x] number of trusted holders of said 'password chunks', it's certainly a good concept, and it would be interesting to see schematics for a hybrid solution, one that incorporates both the division of keys and the division of password chunks. A bit 'overboard' perhaps, but I'm all for overboard when it comes to security.

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

Re: Root Key Storage

Postby JonahAragon » Sun Feb 12, 2017 6:33 pm

verax wrote:I'll offer an alternative option: encrypt the key and have the password split up. There are schemes that can be used so that only a certain number of the keyholders need to be present, that way someone can be away without blocking everything, but still requires consensus to function.


This could work mostly similarly to Option 2, but it'd have the same benefits and drawbacks overall... The primary issue with your plan or the 2nd idea I mentioned is that there's no realistic way for the keyholders to meet up IRL, so trust becomes a bit difficult.

pfo wrote:I like Option 2 better than Option 1. Option 2 is also not ideal, however, I do not have a better idea currently. I'll thing about other concepts though.

One way to prevent the keymaster from issuing certificates that he should not have approved of is making every signature public (It will not prevent him per se, but if a bad signature get's public, the keyholders will not provide him with the parts anymore). This is called Certificate Transparency. I am no expert on the topic, but I can provide a few links:


To implement the concept of CT we would need a log server of our own, since the other logs would probably not accept our root certificate.

As I plan to contribute more to this topic, I request to be added into the Encryption WG.


This is more or less the plan for our system, we're going to make it so everybody can see the list and fingerprints of every issued and revoked certificate in a public place, which should make it more trustworthy. I'm not sure how exactly to go about setting up a system like that, or if something like the lists you mentioned can be self hosted easily. I'll have to look more into solutions to make sure the process is completely transparent.

Nadia wrote:Take a look here - https://letsencrypt.org/certificates - this is similar to what Jonah's suggesting. A more complete implementation using certbot is found here - https://github.com/certbot/certbot


Somewhat like that, sure. That page doesn't really describe the protection of the private keys themselves though, just the issuance of certificates. I have some ideas involving Let's Encrypt's Boulder server implementation, but that's a topic for another post...

Nadia wrote:As for the password being dividing among [x] number of trusted holders of said 'password chunks', it's certainly a good concept, and it would be interesting to see schematics for a hybrid solution, one that incorporates both the division of keys and the division of password chunks. A bit 'overboard' perhaps, but I'm all for overboard when it comes to security.


Yeah, we'll have to look more into good solutions for this problem. Splitting up both like you mentioned might work, we just need good ways to do that while trusting all parties and making sure the entire key isn't lost if one holder disappeared. Lots of long-term thinking involved with this project...

verax
Site Admin
Posts: 30
Joined: Mon Jan 18, 2016 3:16 am

Re: Root Key Storage

Postby verax » Tue Feb 14, 2017 3:20 am

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"

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

Re: Root Key Storage

Postby pfo » Wed Feb 15, 2017 2:41 pm

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.

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.

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.

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. A few things have to be ensured in these transfers:
  1. The sender must encrypt the message on an offline system and then copy the encrypted version to an online system.
  2. Only the receiver (not even the sender) can read the message after it was encrypted.
  3. The sender must know that the receiver is really the receiver.
  4. Both sender and receiver have to delete the message from their email server, the sender after he has sent it successfully, the receiver after he has copied the (still encrypted) message to an offline system. The receiver can decrypt it on the offline system, but not leave the decrypted copy there for longer than necessary.

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".

Here is what I have in mind:
There are thirteen people: Rootadmin1, Rootadmin2, Rootadmin3, Sysadmin, Keyholder1, Keyholder2, Keyholder3, Keyholder4, Keyholder5, Keyholder6, Keyholder7, Keyholder8, Keyholder9.

  1. Keyholder1 sends Rootadmin1 a PGP signed message verifying that the PGP key and the talk.geek member belong to the same person.
  2. Keyholder2 sends Rootadmin1 a PGP signed message verifying that the PGP key and the talk.geek member belong to the same person.
  3. Keyholder3 sends Rootadmin1 a PGP signed message verifying that the PGP key and the talk.geek member belong to the same person.
  4. Keyholder4 sends Rootadmin1 a PGP signed message verifying that the PGP key and the talk.geek member belong to the same person.
  5. Keyholder5 sends Rootadmin1 a PGP signed message verifying that the PGP key and the talk.geek member belong to the same person.
  6. Keyholder6 sends Rootadmin1 a PGP signed message verifying that the PGP key and the talk.geek member belong to the same person.
  7. Keyholder7 sends Rootadmin1 a PGP signed message verifying that the PGP key and the talk.geek member belong to the same person.
  8. Keyholder8 sends Rootadmin1 a PGP signed message verifying that the PGP key and the talk.geek member belong to the same person.
  9. Keyholder9 sends Rootadmin1 a PGP signed message verifying that the PGP key and the talk.geek member belong to the same person.
  10. Rootadmin2 sends Rootadmin1 a PGP signed message verifying that the PGP key and the talk.geek member belong to the same person.
  11. Rootadmin3 sends Rootadmin1 a PGP signed message verifying that the PGP key and the talk.geek member belong to the same person.
  12. Sysadmin sends Rootadmin1 a PGP signed message verifying that the PGP key and the talk.geek member belong to the same person.
  13. On an online System, Sysadmin generates a private key: IC
  14. On an online System, Sysadmin generates a Certificate Signing Request with IC.
  15. Sysadmin transfers the CSR to Rootadmin1. (no encryption needed, it can as well be public.)
  16. Rootadmin1 transfers the CSR to his offline system.
  17. On an offline System, Rootadmin1 generates a private key and a corresponding public key: KEY and PUBLIC
  18. On an offline System, Rootadmin1 signs the CSR. (PUBLIC-IC)
  19. On an offline System, Rootadmin1 encrypts KEY with the passphrase ABC (KEY.enc)
  20. On an offline System, Rootadmin1 deletes KEY
  21. On an offline System, Rootadmin1 encrypts A to Keyholder 1 (A.enc1)
  22. On an offline System, Rootadmin1 encrypts A to Keyholder 2 (A.enc2)
  23. On an offline System, Rootadmin1 encrypts A to Keyholder 3 (A.enc3)
  24. On an offline System, Rootadmin1 encrypts B to Keyholder 4 (B.enc4)
  25. On an offline System, Rootadmin1 encrypts B to Keyholder 5 (B.enc5)
  26. On an offline System, Rootadmin1 encrypts B to Keyholder 6 (B.enc6)
  27. On an offline System, Rootadmin1 encrypts C to Keyholder 7 (C.enc7)
  28. On an offline System, Rootadmin1 encrypts C to Keyholder 8 (C.enc8)
  29. On an offline System, Rootadmin1 encrypts C to Keyholder 9 (C.enc9)
  30. On an offline System, Rootadmin1 encrypts KEY.enc to himself (KEY.enc.enc1)
  31. On an offline System, Rootadmin1 encrypts KEY.enc to Rootadmin2 (KEY.enc.enc2)
  32. On an offline System, Rootadmin1 encrypts KEY.enc to Rootadmin3 (KEY.enc.enc3)
  33. On an offline System, Rootadmin1 deletes ABC and KEY.enc
  34. Rootadmin1 transfers PUBLIC, PUBLIC-IC, A.enc1, A.enc2, A.enc3, B.enc4, B.enc5, B.enc6, C.enc7, C.enc8, C.enc9, KEY.enc.enc2 and KEY.enc.enc3 to an online system.
  35. On an online system, Rootadmin1 transfers A.enc1, A.enc2, A.enc3, B.enc4, B.enc5, B.enc6, C.enc7, C.enc8, C.enc9, KEY.enc.enc2 and KEY.enc.enc3 to the respective receivers.
  36. On an online system, Rootadmin1 deletes A.enc1, A.enc2, A.enc3, B.enc4, B.enc5, B.enc6, C.enc7, C.enc8, C.enc9, KEY.enc.enc2 and KEY.enc.enc3 from his "sent" folder.
  37. On an offline system, Rootadmin1 deletes A.enc1, A.enc2, A.enc3, B.enc4, B.enc5, B.enc6, C.enc7, C.enc8, C.enc9, KEY.enc.enc2 and KEY.enc.enc3
  38. Rootadmin1 publishes PUBLIC and PUBLIC-IC and by doing that establishes trust in Sysadmin.
  39. Everyone who wants to use the CA has to import PUBLIC into his browser.
  40. Sysadmin is now operational and can issue certificates signed by IC.

What do you think about this?

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

Re: Root Key Storage

Postby JonahAragon » Wed Feb 15, 2017 8:58 pm

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.

pfo wrote: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
  1. Email the addresses listed on the key to ensure they belong to that recipient and they can decrypt it; and
  2. 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.
</edit>

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.

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

Re: Root Key Storage

Postby pfo » Wed Feb 15, 2017 10:51 pm

JonahAragon wrote:another solution I thought of was granting each Tier 1 operator an IC so they could provide certificates with their domains upon registration
Interesting idea, I support that. However, in addition there should be an ACME service in case you want a combined certificate including different TLDs. I'm interested in seeing the disadvantages to that.

JonahAragon wrote: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.
Indeed. If we cannot trust them we cannot trust anyone. How many active T1 ops are there, and how many would be willing to take such role? I'm quite unfamiliar with the situation. At least 13 would be needed, including you.

JonahAragon wrote: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.


You misunderstood me. Of course talk.geek cannot read the messages, however talk.geek could impose you if need be. Imagine this: The owners of talk.geek, keybase.io, twitter.com and githubusercontent.com conspire to impose you. They will generate a PGP key in your name and post it to their sites. I'm not saying that to disrespect you or anything, also not that this is happening, but it would be possible.

Initially I thought that we could use talk.geek as a secure channel meaning that we could trust the owner to not conspire. However, I have thought of a simpler and more secure trusted channel: DNS. You want to use T1 Operators as actors in the CA? Awesome, they can just put a DNS TXT record up for their respective $FOO.dns.opennic.glue saying "PGP: $FINGERPRINT". That should ensure that they are truly the T1 operators. Keybase and Co. are nice, but there is no need to trust them.

JonahAragon wrote: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.


I agree, however, this would be done by a T1 operator and if we cannot trust them, we cannot trust anyone. In an ideal world, we could have witnesses of the deletion, but oh well.

I also think that you would not be the one doing the initial signing, because you would most probably be the sysadmin handling the intermediate certificate. A rootadmin would have to do the initial signing.

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

Re: Root Key Storage

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

pfo wrote:Interesting idea, I support that. However, in addition there should be an ACME service in case you want a combined certificate including different TLDs. I'm interested in seeing the disadvantages to that.


I just wrote more extensively on the topic of actual signing, so you can see this post: viewtopic.php?f=31&t=1013

pfo wrote:Indeed. If we cannot trust them we cannot trust anyone. How many active T1 ops are there, and how many would be willing to take such role? I'm quite unfamiliar with the situation. At least 13 would be needed, including you.


I'm not sure how many people would be on board. Since it would require minimal participation I don't think it will be a major issue, but we'll see. If need be, we could always find some longtime members as well. Not entirely sure yet,

pfo wrote:You misunderstood me. Of course talk.geek cannot read the messages, however talk.geek could impose you if need be. Imagine this: The owners of talk.geek, keybase.io, twitter.com and githubusercontent.com conspire to impose you. They will generate a PGP key in your name and post it to their sites. I'm not saying that to disrespect you or anything, also not that this is happening, but it would be possible.

Initially I thought that we could use talk.geek as a secure channel meaning that we could trust the owner to not conspire. However, I have thought of a simpler and more secure trusted channel: DNS. You want to use T1 Operators as actors in the CA? Awesome, they can just put a DNS TXT record up for their respective $FOO.dns.opennic.glue saying "PGP: $FINGERPRINT". That should ensure that they are truly the T1 operators. Keybase and Co. are nice, but there is no need to trust them.


The point wasn't that any one of those was secure, but that all together they can be considered trustworthy since they all hold identical information. Any single one of them might try to impersonate me, but the odds are infinitesimally small that ALL of them would try to conspire against me in unison, especially after I vouch for them as well. The DNS idea is nice though, we could definitely do that, coupled with DNSSEC that should be secure...

pfo wrote:I agree, however, this would be done by a T1 operator and if we cannot trust them, we cannot trust anyone. In an ideal world, we could have witnesses of the deletion, but oh well.

I also think that you would not be the one doing the initial signing, because you would most probably be the sysadmin handling the intermediate certificate. A rootadmin would have to do the initial signing.


Right, and I think we will have to concede on this front, unfortunately, since I can't think of a better idea.


Return to “Encryption”

Who is online

Users browsing this forum: No registered users and 0 guests