- - -

- - - - - - - - -History -

- - - - - -

GnuTLSExternalValidation¶

- - -

This page is intended to flesh out ideas to externalize the X.509 chain validation, X.509 private key handling, and possibly also OpenPGP validation and private key handling.

- - -

It is important to realize that these are different problems, so the solution may be different. Let's first make the goals clear:

- - -

Make it possible to store private keys in a process different from the process that runs the GnuTLS client/server.
Make it possible to perform X.509 chain validation in a different process.
Make it possible to perform OpenPGP key validation in a different process.

- - -

One must decide whether the external agent should be responsible for making authentication decisions, authorization decisions, or both. Possibly it should be able to make both kind of decisions. The GnuTLS process can always make further authorization decisions as well.

- - -

For private keys, there is the PKCS#11 interface. GnuTLS has a branch that supports it. However, PKCS#11 doesn't solve the problem with an external process. It seems better to move the PKCS#11 interface to the external agent, rather than adding PKCS#11 interface to GnuTLS itself. Btw, GnuTLS already has PKCS#11 support on a special branch, and has been tested against the Scute PKCS#11 provider together with a Swedish eID X.509 smartcard.

- - -

The solution should allow simple integration with GNOME components such as SeaHorse.

- - -

Private key protocol¶

- - -

Possible we should re-use GnuPG's external protocol here? What we need is an IPC protocol that does:

- - -

SIGN [ALG] [KEY-ID] [TLS-DATA]

- - -

Where KEY-ID somehow denotes a key to use, and TLS-DATA is the data that needs to be signed using the TLS algorithm. Given that TLS supports several algorithms, and even RSA is supported in more than one mode, there needs to be an ALG flag to indicate this.

- - -

X.509 Chain Validation¶

- - -

GnuPG's dirmngr has a protocol for doing this, using assuan. Unfortunately, assuan's design criteria state "no protection against DoS needed". This might make it unsuitable for a TLS implementation or other online tool.

- - -

It is not clear to me whether the trusted CAs should be sent over the IPC, or whether it is something that is assumed to be known by the agent. The latter seems safer, but the former may be useful in some scenarios. (what scenarios?) They aren't mutually incompatible, so maybe we can support both.

- - -

Thus we need a command to send over a trusted certificate:

- - -

TRUSTED [b64pem...]

- - -

And also send over untrusted certificates provided by the TLS peer:

- - -

UNTRUSTED [b64pem...]

- - -

Finally, a request to perform chain validation on a particular certificate is performed using:

- - -

VALIDATE [b64pem...]

- - -

Generic Certificate Validation¶

- - -

It would be nice to be able to hand the agent any kind of certificate (OpenPGP or X.509), or even to be able to hand the agent a raw public key to see if it validates.

- - -

The crucial request would be:

- - -

VALIDATE {LABEL} {CERTTYPE} {PEERNAME} {CERTIFICATE}

- - -

This says "I'm a program called LABEL. I'm about to send you a certificate of type CERTTYPE. I want you to tell me whether the specified PEERNAME matches one of the names stored in the certificate, and that the matching name in the certificate is cryptographically valid based on your knowledge of trusted certifiers."

- - -

The agent can respond with VALID or INVALID. We maybe should consider whether INVALID might be implemented as an extensible set of reasons for invalidity (e.g. EXPIRED, NOMATCH, UNTRUSTED, SELFSIGNED, etc): would the potential extensibility from this outweigh the added implementation and semantic complexity?

- - -

The possible options for CERTTYPE could be:

- - -

RAWPUBKEY (maybe modelled after ssh-dss and ssh-rsa in RFC 4253 ?)
OPENPGP (after section 11.1 of RFC 4880 either base-64 encoded or raw)
X509 (after RFC 5280, either PEM or DER encoded)

- - -

This would allow numerous clients and servers to make use of the validation agent. For example:

- - -

lsh could feed its fetched host keys to the validation agent instead of having to maintain ~/.lsh/host-acls
slapd could use the validation agent to identify the DN of the remote client.
subversion could ask the validation agent to ensure that the OpenPGP certificate offered by a remote https server (using mod_gnutls) is in fact who it claims to be (and the mod_gnutls could validate the identity of the client in the same way).

- - -

Additionally, it might be nice to have a command to offer intermediate certificates to the certificate store:

- - -

UNTRUSTED {LABEL} {CERTTYPE} {CERTIFICATE}

- - -

using UNTRUSTED with a RAWPUBKEY certificate wouldn't be a meaningful operation, but it could be used for intermediate X.509 certificates, or for the equivalent OpenPGP certificates (if such things were handy).

- - - - - - -

-Also available in: -HTML -TXT -

- - - - - - - -

Monkeysphere: an OpenPGP-based PKI for SSH

Ever thought that there should be an automated way to handle ssh -keys? Do you know the administrators of your servers, and wish that -SSH could verify new host keys from them automatically, based on your -personal connections to the web-of-trust? Do you wish you could -revoke and/or rotate your old SSH authentication keys without having -to log into every single machine you have an account on?

Do you administer servers, and wish you could re-key them without -sowing massive confusion among your users (or worse, encouraging bad -security habits among them)? Do you wish you could grant access to -your users by name, instead of by opaque string? Do you wish you -could rapidly revoke access to a user (or compromised key) across a -group of machines by disabling authentication for that user?

A group of us have been working on a public key infrastructure for -SSH. Monkeysphere makes use -of the existing OpenPGP web-of-trust to fetch and cryptographically -validate (and revoke!) keys. This works in both direction: -authorized_keys and known_hosts are -handled. Monkeysphere gives users and admins tools to deal with SSH -keys by thinking about the people and machines to whom the keys -belong, instead of requiring humans to do tedious (and error-prone) -manual key verification.

We have debian -packages available which should install against lenny (for i386, -amd64, powerpc, and arm architectures at the moment), a mailing -list, and open ears for good questions, suggestions and -criticism.

If you have a chance to give it a try (as a -user or as an -admin), it would be great to get -feedback.

- -On Saturday (2008-6-22) dkg and I set up sks as a replacement for onak. onak -had proven to be unstable, mostly in that it tended to corrupt its own database -beyond repair. - -The sks instructions want the admin to download many huge dumps of keys from -the world's keyservers (on the order of 5 GiB?), so we imported a dump -containing only my key. We learned that sks won't start with an empty database, -unlike onak. - -2008-06-25: Locally exported george's key to its keyserver. Tried a remote -send-keys of squash's key and it appears to work. - - -TODO: - - * Get some more keys in there. - - * Read up on syncing with other keyservers. - - - - diff --git a/doc/george/policy b/doc/george/policy deleted file mode 100644 index a17a310..0000000 --- a/doc/george/policy +++ /dev/null @@ -1,33 +0,0 @@ -Policy for maintaining george.riseup.net ----------------------------------------- - -Riseup graciously provided the MonkeySphere project with a vserver for -testing and public documentation. This is known as george.riseup.net, -for those who are curious about the MonkeySphere. - -george will be maintained as a debian lenny machine, with minimal -packages from experimental as needed for installing and running what -we build elsewhere. - -george will host 3 public-facing services: an ssh daemon on port 22, -an http service on port 80, and an OpenPGP keyserver (the HKP -protocol) on port 11371. - -Administration of george is a shared responsibility across the core -members of the MonkeySphere development team. Administrators will log -changes in their git repositories, in doc/george/changelog (a peer of -this policy file). - -monkeysphere packages installed on george will use unique, tagged -version numbers so we know what we're running. - -We will try to keep the installation as minimal as possible while -still allowing for comfortable day-to-day administration. - -We will use aptitude for package management where possible. - -Outstanding questions: - -Who should have superuser access? - -Who should get regular user accounts? diff --git a/doc/george/user-id-configuration b/doc/george/user-id-configuration deleted file mode 100644 index 9a7f4d2..0000000 --- a/doc/george/user-id-configuration +++ /dev/null @@ -1,40 +0,0 @@ -2008-06-19 03:00:58-0400 ------------------------- - -setting up authorized_user_id configuration on george was also more -cumbersome than it needs to be. Here's what i (dkg) did: - -monkeysphere-server trust-keys 0EE5BE979282D80B9F7540F1CCD2ED94D21739E9 - -monkeysphere-server update-user-userids dkg 'Daniel Kahn Gillmor ' -monkeysphere-server update-user-userids jrollins 'Jameson Rollins ' -monkeysphere-server update-user-userids micah 'Micah Anderson ' -monkeysphere-server update-user-userids mjgoins 'Matthew Goins ' -monkeysphere-server update-user-userids ross 'Ross Glover ' -monkeysphere-server update-user-userids jamie 'Jamie McClelland ' -monkeysphere-server update-user-userids mlcastle 'mike castleman ' -monkeysphere-server update-user-userids enw 'Elliot Winard ' -monkeysphere-server update-user-userids greg 'Greg Lyle ' - - -then i added a scheduled: - - monkeysphere-server update-users - -to run hourly via /etc/crontab - -and made sure that root's keys were working with a temporary symlink -(see TODO about that business) - -and then modified /etc/ssh/sshd_config with: - - AuthorizedKeysFile /var/cache/monkeysphere/authorized_keys/%u - - -Some outstanding questions: - - * Should we ship a scheduled monkeysphere-server update-users cron - job automatically? - - * why was i not prompted to confirm the trust-keys line, which seems - like the most delicate/sensitive line of all of them? diff --git a/doc/ikiwiki.setup.sample b/doc/ikiwiki.setup.sample deleted file mode 100644 index 97e77c8..0000000 --- a/doc/ikiwiki.setup.sample +++ /dev/null @@ -1,29 +0,0 @@ -use IkiWiki::Setup::Standard { - wikiname => "Monkeysphere", - adminemail => 'webmaster@monkeysphere.info', - - srcdir => "/path/to/cloned/monkeysphere/repo/website", - destdir => "/path/to/web/dir", - - url => "http://monkeysphere.info", - - rcs => "git", - - wrappers => [ - { - wrapper => "/path/to/post-receive/hook", - wrappermode => "0755", - } - ], - - rss => 1, - atom => 1, - verbose => 0, - syslog => 0, - - add_plugins => [qw{goodstuff favicon toc sidebar}], - - - tagbase => "tags", - -} diff --git a/doc/zimmermann/changelog b/doc/zimmermann/changelog deleted file mode 100644 index f3e8171..0000000 --- a/doc/zimmermann/changelog +++ /dev/null @@ -1,71 +0,0 @@ -****************************************************************************** -* * -* zimmermann system log * -* * -****************************************************************************** -* Please add new entries in reverse chronological order whenever you make * -* changes to this system (first command at top, last at bottom) * -****************************************************************************** - -2010-03-10 - micah - * Updated /etc/monkeysphere/*.conf to use zimmermann - for the keyserver - -2010-03-09 - dkg - * transferred the https://z.m.o key from /root/.gnupg into the - monkeysphere-host keyring with: - - gpg --export-secret-keys | GNUPGHOME=/var/lib/monkeysphere/host gpg --import - - * used undocumented "monkeysphere-host update-pgp-pub-file" to - refresh the output of m-h s. - -2010-02-19 - dkg - * upgraded to monkeysphere 0.28-1~bpo50+1 (includes gnupg from - backports.org) - -2010-02-?? - dkg - * manually created an OpenPGP certificate for zimmermann's https - RSA key, stored in /root/.gnupg; published it to the keyserver - network, certified it myself. - -2008-11-29 - dkg - * zimmermann now uses an X.509 certificate signed by the MF/PL CA - for its HTTPS connection. - -2008-11-19 - dkg - * added 10 SKS peers as a result of feedback from sks-devel. - * set localtime to America/New_York via dpkg-reconfigure tzdata - * aptitude update && aptitude full-upgrade - * set up /var/lib/sks/www/index.html based on - doc/zimmermann/index.html from this repo. - * made nginx proxy plain ol' HTTP on port 80 also so that SKS does - not need to try to listen on a privileged port. - * turned on initial_stat and stat_hour: 3 in /etc/sks/sksconf - -2008-11-19 - mlc - * aptitude install nginx - * get rid of /etc/nginx/sites-enabled/default - * create /etc/nginx/sites-available/https-proxy and make a symlink - to it in the sites-enabled directory - * invoke-rc.d nginx start - -2008-11-17 - micah - * verified the SHA256 values for the key material - * /usr/lib/sks/sks_build.sh (chose option #2: normalbuild) - * chown -R debian-sks:debian-sks /var/lib/sks - * edit /etc/default/sks to enable the initscript - * /etc/init.d/sks start - * rm -rf /var/lib/sks/dump - -2008-11-15 - micah - * aptitude update && aptitude full-upgrade - * aptitude install sks - * cd /var/lib/sks/dump ; wget -q -r -np -nd -A bz2,SHA256,asc \ - http://nynex.net/keydump/ -e robots=off - * install monkeysphere 0.21-2 package - * apt-get install bzip2 ; bunzip2 /var/lib/sks/dump/*.bz2 - -2008-11-15 - jamie - * aptitude install esmtp-run mailx - * edited /etc/esmtp-run, configured to relay to bulk.mayfirst.org diff --git a/doc/zimmermann/https-proxy b/doc/zimmermann/https-proxy deleted file mode 100644 index c4521a7..0000000 --- a/doc/zimmermann/https-proxy +++ /dev/null @@ -1,14 +0,0 @@ -server { - listen 443; - server_name zimmermann.mayfirst.org; - ssl on; - ssl_certificate /etc/ssl/certs/ssl-cert-snakeoil.pem; - ssl_certificate_key /etc/ssl/private/ssl-cert-snakeoil.key; - ssl_ciphers HIGH:MEDIUM:!ADH; - - access_log off; - - location / { - proxy_pass http://localhost:11371/; - } -} diff --git a/doc/zimmermann/index.html b/doc/zimmermann/index.html deleted file mode 100644 index e8e36e0..0000000 --- a/doc/zimmermann/index.html +++ /dev/null @@ -1,73 +0,0 @@ - - - - SKS Search Page - - - - -

SKS OpenPGP Keyserver
@zimmermann.mayfirst.org

SKS is a OpenPGP keyserver whose goal is to provide easy to deploy, decentralized, and highly reliable synchronization. That means that a key submitted to one SKS server will quickly be distributed to all key servers, and even wildly out-of-date servers, or servers that experience spotty connectivity, can fully synchronize with rest of the system.

You can find out more about SKS, along with links to graphs of the network status here.

- - - - - - - - - - - -

Extract a key

You can extract a key by typing in some words that appear in the userid - of the key you're looking for, or by typing in the keyid in hex format ("0x...")

-
-

Submit a key

- You can submit a key by simply pasting in the ASCII-armored version - of your key and clicking on submit. - -

- Access -

- To use this server directly via HKP add this to your .PGP keyserver list:
- -

x-hkp://zimmermann.mayfirst.org
-http://zimmermann.mayfirst.org:11371

- - You can also select a random server by adding this to your keyserver list:
- -

x-hkp://pool.sks-keyservers.net
-http://pool.sks-keyservers.net:11371

- -

- [Server Status] If you have any questions - about or problems with this server, please open a ticket. - - -- cgit v1.2.3

GnuTLS

Wiki

GnuTLSExternalValidation¶

Private key protocol¶

X.509 Chain Validation¶

Generic Certificate Validation¶

Monkeysphere: an OpenPGP-based PKI for SSH

SKS OpenPGP Keyserver @zimmermann.mayfirst.org

Extract a key

Submit a key

- Access -

SKS OpenPGP Keyserver
@zimmermann.mayfirst.org