nymsio / nymsio.github.io Goto Github PK

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 [email protected] and an alias as [email protected], 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 [email protected] 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, [email protected] for email and [email protected] 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.