[kgo]

Yep, you can do WoT with X.509 if you write the semantics from scratch, and you can also do a CA approach with OpenPGP.

The thing is, for years no-one has stepped in and actually gone through the pesky little details of implementing all those semantics for rubygems via X.509 even though it's come up repeatedly. But maybe someday some expert will come along and fix things.

If you actually read the rubygems documentation on signing gems, it's pretty much "Okay generate your own self-signed key, then sign it with your self-signed key." That leaves a lot to be desired vs best practices. There isn't even an attempt to describe how you get your self-signed keys to users.

I just think leveraging the existing OpenPGP semantics, ecosystem, and battle-hardened gnupg codebase, is a lot easier than implementing an entire system from scratch on X.509 just because openssl is already installed everywhere and ruby has better bindings and gnupg is not and does not.

I'm just trying to take the approach you usually preach: Don't roll your own crypto code and leave the real work to the pros, and it seems like gpg offers a lower path of resistance.

[tptacek]

Using OpenPGP is a bad idea here. All the mainstream rubies have access to high-quality X.509 in their mainline distros without a third-party gem.

Both OpenPGP and X.509 are going to require a little of fiddley semantic details that will take time to hash out. The bottleneck here isn't the technology.

I like, and routinely recommend, OpenPGP for solving app crypto problems. X.509 makes a lot more sense here.