Elaborate on multiple certificates & domains for session servers case
See also: ACTION-13
A user has a relationship with a person, or a company, not with a domain name. For the case where there is a one-to-one correspondence between domain name and user meaningful entity, the difference may be overlooked; however, many entities on the web use multiple domain names. Current use of SSL on the web authenticates domain names, and only vaguely identifies entities, so it is left to the user to figure out which domain names correspond to which entities. Ideally, the browser would do this work for the user and track when the user is interacting with a known acquaintance versus a stranger. For this user interface to be robust, identification of related domain names must move from the vague to the exact. In particular, an entity needs a standard way to express what domain names should be treated as equivalent by users.
Currently deployed SSL server certificates commonly provide the following attributes to identify the server: CN, the hostname; O, the organization name; OU, the organization unit; C, the country; ST, the state; L, the city. An SSL server certificate is also signed by some issuing certificate. Identification of related hosts could be accomplished by standardizing some subset of these certificate attributes for use as the entity identifier. For example, the Petname Tool uses the subset: root issuer public key, O, C, ST, L. The CN attributed is used in place of O when the certificate does not specify an O value, such as is common with a domain validated certificate. Similar tools are known to use different subsets.