some random comments

[elijh]

Trusted Notary

Can't we make them a little less trusted? Trust but verify. How about a threshold where an identity certificate does get served by a directory until the identity certificate has three or more endorsements from the global list of recognized notaries (or one endorsement from a notary and one from the provider). This could also be enforced by the client.

If the certificate contains other UID or public keys, the client must omit these OpenPGP packets from the certificate presented in the request.

I very much like enforcing a single UID. The whole model rests on this, in some ways. However, I think the server can be smart enough to do this processing, making it easier to write clients.

If the provider implements mail sender authentication, we use this information to confirm the authenticity of the message from the user to raise the difficulty of attacking the verification system

I think it would be good to make this a one-way ratchet: Once a Certificate Endorsement Service discovers that provider X supports SPF or DKIM, all subsequent mail-backs with that provider should require it (i.e. further Mail Verification Protocol with that provider).

Both the key for encryption and the index for querying the record are derived by applying the scrypt() key derivation function to the address to be queried

scrypt is cool, but I don't think it is appropriate for this usage:

• scrypt is not as widely supported as other KDFs and makes it more difficult to write a client (the client probably already depends on other crypto libraries that support more common KDFs).
• I don't know that there is much benefit to making the hash expensive in terms of computation or memory. I think it is a good assumption that an attacker is rich in both (either because they control a bot army or they are from a very big organization).

ID servers allow users to segment identity information so that different types of queries will only return information relevant to the particular query. A user may have both an email address and a jabber address under the same identity, but does not want to reveal their jabber address to somebody who queries for their email encryption keys. Another case would be a user who has multiple email addresses under the same identity, and some are more public than others.

I do not understand. Why do you say, "under the same identity"? Identity, in this case, means identity certificate, yes? And we already established that we strip out other uids from these before they are endorsed.

There are four potential scenarios:

1. single address for single protocol: no ambiguity here.
2. multiple addresses for the same protocol: if I have multiple addresses I want to make sure there is a separate key for each one, and a separate endorsement process. For example, if I have elijah@riseup.net and an alias as sparrow@riseup.net, I don't want there to be any association between them in the notaries or directories. I have to prove ownership to the notary in both cases anyway, so it seems to me that one identity always maps to one address. This should hold true even if it ends up being the same key pair with multiple uids.
3. single address for multiple protocols: If I have one address elijah@riseup.net that happens to map onto multiple protocols (SMTP, XMPP, SIP, etc), I am not clear on what the benefit would be of hiding from anyone what protocols I support on that address. If they already know how to spam me with one protocol, I might as well let them spam me on other protocols.
4. multiple addresses for multiple protocols: If I have different addresses for different services, elijah@riseup.net for email and elijah@chat.riseup.net for jabber and @ecsparrow for chat, then yes, I suppose I might want other people to be able to know that they all correspond to the same person without publishing the connection. Because other uids are stripped from identity certificate prior to endorsement, I am not sure how this would work.

[nymsio]

How about a threshold where an identity certificate does get served by a directory until the identity certificate has three or more endorsements from the global list of recognized notaries (or one endorsement from a notary and one from the provider). This could also be enforced by the client.

Yes, this is the way the notary network is intended to work. The n-of-m endorsement requirement is enforced both by the directory servers and the clients. The reason it's important to also verify the endorsements on the server is that the system deliberately refuses to accept a record mapping (email address --> id certificate) which overwrites an existing record unless the certificate has expired or has been explicitly revoked. So, if the directory permitted an improperly endorsed certificate uploaded by an attacker to occupy an address slot this would prevent the legitimate user from correcting the problem. A 'better' certificate could be allowed to replace the bad certificate in this case but then the server is back to performing the verification it should have done in the first place.

[nymsio]

I very much like enforcing a single UID. The whole model rests on this, in some ways. However, I think the server can be smart enough to do this processing, making it easier to write clients.

There is no strong argument for not doing this on the server instead of the client. I only included this as defensive design to remove any ambiguity which could be leveraged into an attack if the server is implemented incorrectly.

Maybe it's not clear enough in the current description, but every client / server interaction is between the nyms client agent and the notary network. MUAs or other users of the system never interact directly with Nyms servers, rather they invoke an API provided by the client agent.

[nymsio]

I think it would be good to make this a one-way ratchet: Once a Certificate Endorsement Service discovers that provider X supports SPF or DKIM, all subsequent mail-backs with that provider should require it (i.e. further Mail Verification Protocol with that provider).

Yes, also with STARTTLS on the outgoing message.

I do not understand. Why do you say, "under the same identity"? Identity, in this case, means identity certificate, yes? And we already established that we strip out other uids from these before they are endorsed.

The other UIDs are stripped out only for the purposes of the endorsement protocol, but using multiple addresses on the same (master) key (ie. in the same certificate) is not only allowed, but a really important feature of the system. I'm using the word 'identity' here casually to mean both an identity certificate as well as the general idea of a public pseudonym of the user.

multiple addresses for the same protocol: if I have multiple addresses I want to make sure there is a separate key for each one, and a separate endorsement process.

If you have two email addresses which you want to represent under the same pseudonym then put them in the same certificate just like you've always done with GPG and endorse both addresses. Unlike SKS, somebody who queries for address A doesn't automatically find out about address B, which some users may consider to be a useful feature. This is implemented by the directory storing two separate records each of which only includes a single user id packet. If you know about both addresses however, you can verify that they are the same user because they're both self-signed by the same master key.

I don't want there to be any association between them in the notaries or directories.

In this case you want to create two different identity certificates, each of which can have as many addresses as you want to associate with the pseudonym.

then yes, I suppose I might want other people to be able to know that they all correspond to the same person without publishing the connection. Because other uids are stripped from identity certificate prior to endorsement, I am not sure how this would work.

You upload the endorsed certificate with a single user id to the directory and the directory serves it under that uid. Then you repeat the same process with a second uid. Now somebody who knows both uids can download both records from the directory and since both records are self-signed by the same openpgp master signing key, they are verified as belonging to the same user.

[elijh]

Maybe it's not clear enough in the current description, but every client / server interaction is between the nyms client agent and the notary network. MUAs or other users of the system never interact directly with Nyms servers, rather they invoke an API provided by the client agent.

That was my understanding, but the point of an open protocol is to have different implementations. Unless you want to write nym client agent code in every language, probably other people will also be writing agent code too.

[elijh]

If you have two email addresses which you want to represent under the same pseudonym then put them in the same certificate just like you've always done with GPG and endorse both addresses. Unlike SKS, somebody who queries for address A doesn't automatically find out about address B, which some users may consider to be a useful feature. This is implemented by the directory storing two separate records each of which only includes a single user id packet. If you know about both addresses however, you can verify that they are the same user because they're both self-signed by the same master key.

Ah, OK, that makes sense.