[OpenID] general Digest, Vol 31, Issue 37

[John Bradley]

I agree that DH should remain in the spec for non SSL connections.

In Sec 8.2.4 OPs that don't support a particular session type or  
association type can return a direct error message indicating the  
session and association type they do support.

Yahoo is not required to support DH on SSL connections now!  If a RP  
requests a DH association over SSL they can return a error code of  
"unsupported-type" and session_type=no- 
encryption&association_type=HMAC-SHA1 if they like.

Any RP that doesn't retry the association with the returned parameters  
is broken.

I see another RP test coming:)

The point being nothing needs to be removed, Yahoo can do as they like  
under the current spec, while leaving others free to run OPs without  
SSL.(I don't personally think that is a good idea on the open  
internet , but I am not going to stop anyone)

Regards
John Bradley

On 18-Mar-09, at 6:09 PM, general-request at openid.net wrote:

> Date: Wed, 18 Mar 2009 16:35:26 -0700
> From: Johannes Ernst <jernst+openid.net at netmesh.us>
> Subject: [OpenID] D-H vs SSL
> To: OpenID List <general at openid.net>
> Message-ID: <7E5665AE-565B-455F-9B68-F1961F2501E5 at netmesh.us>
> Content-Type: text/plain; charset="us-ascii"; Format="flowed";
> 	DelSp="yes"
>
>> Yahoo and others argue that since they only support associations
>> over SSL the DH encryption is redundant.
>
> It may be in some scenarios, it is not in others.
>
> For example, in a corporate behind-the-firewall deployment it may be
> unreasonably complicated to set up SSL for a departmental server.
>
> I would hate it if we had to tell those guys that they then have to
> send around their secrets in clear text.
>
>
>
> Johannes Ernst
> NetMesh Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2486 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20090318/1f759e4a/attachment-0002.bin>