If I were architecting a next-generation system-to-transform-and-rationalize crypto, I'd definitely look closely at SPKI; s-exp is so much nicer to work with than asn.1 that it's not even funny, and unifying things like certificates for OpenPGP and TLS and friends.
If, on the other hand, I were working on something like Monotone, I'd run screaming at the suggestion that we needed to replace TLS and OpenPGP in order to get the job done: yes, working with OpenSSL's X.509 functions (or NSS's, or whoevers) is a bit of a pain, but rebuilding a transport-layer encryption library from scratch sounds like a massive mission detour. Probably, I'd use TLS for the transport, OpenPGP-plus-some-decoration for data signing and encryption, and jury-rig some kind of certificate format (maybe spki, who knows) to manage the subkeys I was using for each.
What other way forward is there?
Let me riff on your idea. To do the most good work for the field in the small term, I'd start with a simple but powerful tool that could expand into the various protocols and slowly replace the badness of them. Take the "separate domains" problem you talk about above: It isn't hard to jury-rig cross-certification between the various certificate/fingerprint formats now, but so far as I know there is no popular standard way to certify your keys with one another, or unify them. Most pragmatically, I'd like people who trust my OpenPGP key to also be able to trust my OTR key and my SSH keys and my self-generated X.509 certs. I could OpenPGP-sign a document with all these keys in it, but people would need to handle it manually. (There are probably standards to handle this keys, but as far as I can tell, they aren't implemented in any way useful to me.) Once you've got a good cross-certification format, and you get it supported in a few applications (probably by add-on tools at first), you can start promoting it as a general-purpose certificate format for new protocols, and hopefully have it become an alternative format for existing tools.
At least, that's how I'd take over the PKI world this week: from below, starting as a convenience tool for hacker types; and attacking the domains that OpenPGP and X.509 certs handle the worst. Competing with existing standards is a mug's game; writing a tool that's useful from day one is how successful open-source software happens.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2007-02-19 06:49 am (UTC)If I were architecting a next-generation system-to-transform-and-rationalize crypto, I'd definitely look closely at SPKI; s-exp is so much nicer to work with than asn.1 that it's not even funny, and unifying things like certificates for OpenPGP and TLS and friends.
If, on the other hand, I were working on something like Monotone, I'd run screaming at the suggestion that we needed to replace TLS and OpenPGP in order to get the job done: yes, working with OpenSSL's X.509 functions (or NSS's, or whoevers) is a bit of a pain, but rebuilding a transport-layer encryption library from scratch sounds like a massive mission detour. Probably, I'd use TLS for the transport, OpenPGP-plus-some-decoration for data signing and encryption, and jury-rig some kind of certificate format (maybe spki, who knows) to manage the subkeys I was using for each.
What other way forward is there?
Let me riff on your idea. To do the most good work for the field in the small term, I'd start with a simple but powerful tool that could expand into the various protocols and slowly replace the badness of them. Take the "separate domains" problem you talk about above: It isn't hard to jury-rig cross-certification between the various certificate/fingerprint formats now, but so far as I know there is no popular standard way to certify your keys with one another, or unify them. Most pragmatically, I'd like people who trust my OpenPGP key to also be able to trust my OTR key and my SSH keys and my self-generated X.509 certs. I could OpenPGP-sign a document with all these keys in it, but people would need to handle it manually. (There are probably standards to handle this keys, but as far as I can tell, they aren't implemented in any way useful to me.) Once you've got a good cross-certification format, and you get it supported in a few applications (probably by add-on tools at first), you can start promoting it as a general-purpose certificate format for new protocols, and hopefully have it become an alternative format for existing tools.
At least, that's how I'd take over the PKI world this week: from below, starting as a convenience tool for hacker types; and attacking the domains that OpenPGP and X.509 certs handle the worst. Competing with existing standards is a mug's game; writing a tool that's useful from day one is how successful open-source software happens.