[OpenID] [from Marketing] I object to OpenID whitelists

[Peter Williams]

Lets review what I believe are facts, found using classical security protocol analysis and spiced just a little conjecture concerning the role of PKI and certificate policy. The words control, grant, right, knowledge, data, confirm, share, release, agent etc are all technical terms, used professionally, as are PKI terms, and as are (hopefully) my use of formal OpenID terms.
 
The OpenID scheme distinguishes an OpenID- trust-point from the agent known as an OP Consumer. Indeed, the entity controlling an OP grants only to an identified (but poorly authenticated) OpenID-trust-point the right to receive the knowledge, recently confirmed by an OP Provider, that the user controls a given OP.  Similarly, an OP provider stores data that the entity has authorized the sharing of attribute information with that identified OpenID-trust-point, and may release stored attributes in line with that terms of the sharing-policy to the identified (but poorly authenticated) OP Consumer agent.
 
There are no standards in the OpenID family for expressing an OP =trust points policy impacting an OP Consumer's decision on which OP Provider(s) the consumer agent may or may not create or maintain OP-associations. The OpenID Authentication standard does not define such a policy role, furthermore; it does not  refer to such a role, it does not define the function of any such policy, and it does not define any notion of policy authority.
 
PKI, Common Critiera Protection Profiles for PKIs, IETF-styled CA certification practice statements, X.509 certificate policies, NIST-styled CA assurance levels, NIST-styled inter-PKI bridging metrics, and ABA-styled relying party agreements legally governing the use of digital signatures and certificates are evidently critical components of the security model of OpenID Authentication. The key distribution policy represented by those components control the creation, maintenance, use and reliance of the security properties of https channels (when SSL3 is protected using with PKI ciphersuites) over which OpenID Authentication protocol messages are exchanged. https supported by a hierarchical, policy-based PKI is a critical security enforcing function in the OpenID Authentication protocol. This SEF is neither specified nor standardized as formal security binding for the communication of OpenID Authentication messages.
 
Management of PKI trust points may be one implementation of an OP-Trust-Point's policy governing creation and maintenance of OP-Associations by one or more OP Consumers. For exanple, a security design might decide to imemnet such policy using the Microsoft wininet implementation of https - by issuing and mandating application of a signed CTL (a white list of PKI-root-trust-points) established by the OP Consumer agent  (and presumably signed by the OP-Trust-Point) that access the winninet library through a particular (OS-secure) handle. Determination that a given CA or end-entityt certificate is suspended or revoked during the conforming handling of https messages may be an implemnetation of athe notion of a "black list of OpenID Providers", or a class of such providers, with whom the OP Consumer policy suspends or revokes the right to create or maintain OP-Associations. The use of such PKI key distribution technique to implememt OP Consumer policy would be expressed in a custom-defined X.509 certificate policy supporting the security binding.
________________________________

From: Martin Paljak [mailto:martin at paljak.pri.ee]
Sent: Thu 7/5/2007 4:12 AM
To: Peter Williams
Cc: Meng Weng Wong; general at openid.net
Subject: Re: [OpenID] [from Marketing] I object to OpenID whitelists




On 05.07.2007, at 4:42, Peter Williams wrote:

> Issue 1: Which providers shall a trust point "accept"? Some think that
> the consumer agent associated with a trust point shall accept any and
> all providers. Others think that the agent supporting the trust point
> shall enforce a security policy limiting via such as black/white lists
> the providers with whom it is authorized to establish
> openid-associations.

You can't enforce the way applications are built or organizations 
work. You can't dictate the way OpenID is used. RP decides what is 
good, why is good and how is good enough for it to operate and 
there's nothing others can do.

White-blacklists are an implementation detail of the RP. If some of 
the white-blacklists happens to be  public ones (like botbouncer.com) 
then it is again just an implementation detail of the RP.