Ian, do you know anyone who's working on OpenPGP software that uses the nym model (instead of the web of trust)?

When I download a new version of a program that is signed using OpenPGP, I don't really care if the signer's user ID has been certified, as this doesn't tell me if the signer is authorized to release new copies (my favorite example: Would you install a new Apache release that is signed by "Rodent of Unusual Size"?). However, if my OpenPGP software could tell me that the signer is the same as the last time I downloaded the software, I would be quite confident that the new release is as genuine as the old one, too.

To answer your first question: webfunds (click on my name below) is uses a nymous protocol called SOX. Whether this quite matches what you are asking for, you can judge:

SOX version 1 was purely PGP, but the old 2.6. Each account was a PGP key that was registered as above, and formed the basis for payments and trades, as well as retail purchasing (the "SOX shop" :). I chose and insisted on PGP because I thought conformance to a standard would help market acceptance. I was wrong!

In SOX version 2 we dropped the requirement to use PGP. SOX 2.0 used x.509 certs as its basic nym; but after a year we discovered that x.509 cannot do financially oriented transactions because it lacks WoT so we switched over to OpenPGP.

However, the nyms that are in the underlying SOX2.2 (and thereafter) are not OpenPGP keys. They are just keys, and I can't recall the precise format. They *could* be OpenPGP keys, but in practice, the notion of "being compatible with some standard" was a complete woftam for the nymous application; what was more important by several orders of magnitude was that the system worked and no money was lost. After that, nobody cares what format the keys are in.

Having said that, there is the question of WoT. For the WoT elements we use OpenPGP, but these are not used as nymous keys! Our plan (a project that is being worked on) is to layer WoT OpenPGP keys over the top of the nyms, so I'd have to say that we are not seeing any desire to use OpenPGP keys as nymous keys, directly.

I think it's horses for courses. The stuff that OpenPGP concentrates on is mostly about additional information related to a key; which is the antithesis of what a nym is. A nym is a key with no information, and its value is its relationship to all the different uses of the key, not to any "statement" tacked on.

To answer your second question: in order to track a nym's activities, the application has to understand what a nym is doing. That is, your download application probably needs to relate the nym to the downloads; and an OpenPGP application won't really understand that.

But you raise an interesting point. If I were to create a key with a name of "Rodent of Unusual Size" and shove it on a key server, then I would be able to happily send out downloads; it is only until some human comes along and realises that there are two keys with the same name that the game would be figured out.

This of course just leads us down to the gulf between reality and security systems. Most security systems, OpenPGP included, relate people to identities to keys and assume that covers it. But most reality deals with assets and actions on those assets, not with people or identity.

All verifying consistency of the signer will do is to make sure that the guy who gave you a backdoored copy can extend and elaborate the deception at will.

Thanks for the post, Ian!

I intend to do some more research about nyms in time (right now, I'm actually on vacation and will get in trouble soon for being on line). Perhaps Adam will give me a tutorial if I buy him a beer.

What's interesting to me is the way nyms relate or can relate to our method of initial validation (http://www.wikidsystems.com/selfservice.shtml) which is 'marketed' toward corporate validation but is actually extremely flexible and extensible and could be used in a WoT way or with PGP. Essentially the public keys are exchanged between our client and the server. After a successful exchange the server sends a registration code (which is then hashed on the client with the public key of the server). Only after the registration code has been returned to the server via a separate trusted channel is the account activated. Typically this process is done on the trusted LAN with trusted credentials, but it could easily be done via PGP or some other mechansim.