Service Key Discovery 1.0

NISHITANI Masaki m-nishitani at nri.co.jp
Mon Jan 21 11:40:32 UTC 2008


Thank you Hans.

About RP->OP SSL connection, major web languages like Java, 
PHP, Rubt etc. has APIs or libraries about HTTP/HTTPS.
I believe in most case it is possible to configure web 
applications to trust only seceral certificates explicitly 
just modify certificate store those languages uses.

> Interesting idea.
> 
> Is there a way to do this via an RP-> OP SSL handshake? Web
> apps typically don't have access to SSL private keys, at least
> in larger deployments.
> 
> I wonder how your idea reduces network traffic, though. Don't
> you still have to retrieve the public key, which is likely
> larger than the "associate" message payload?

About traffic, I was wrong. As you pointed out, number of 
http request is basically same to assotiation mode of OpenID 
2.0.


> I think hurdles against your idea are:
> 
> 1.  availability of public key cryptography in the RP libraries, and
> 2.  fear that it's hard to correctly implement public key cryptography
> 
> Hans
> 
> 
> On 1/21/08, NISHITANI Masaki <m-nishitani at nri.co.jp> wrote:
>> Hi all.
>> What concerns me these days is about secure data exchange
>> over OpenID for serious services and about this theme, I
>> came upon an specification, "secure key discovery 1.0"
>>
>> For my understanding, this spec is about implementing
>> security framework on OpenID world and is still very draft.
>>
>> Now I'd like to figure out some point I found.
>>
>> - In this, the url of the public key is defined to be in the
>>   XRD document and entities will make another request for
>>   the url to retrieve the public key itself.
>>   This gives bad people a chance to pass off a fake key with
>>   poisoning the end-user's DNS. How about to put public key
>>   itself in the XRD or someone else the entity trusts (a
>>   key server)?
>>   The entity only has to manage SSL certificate fingerprints
>>   of XRD authorities or trusting key servers.
>>
>> - With "secure key discovery", we do have to use
>>   "association" or "verification message" no longer.
>>   I think we can optimize OpenID protocol using digital
>>   signature with public keys. This can be done with
>>   following procedure.
>>
>>   1. End-user enter its OpenID in RP site.
>>   2. RP resolve the id and select the user's OP.
>>   3. In the same time, RP retrieve the OP's public key.
>>   4. RP generate a challenge (maybe the user's http session
>>      id)
>>   5. RP send the id to the OP via http redirection.
>>   6. OP authenticate the user and sign to the challenge with
>>      OP's secret key.
>>   7. OP send the assertion including the signed challenge
>>      back to the RP via redirection.
>>   8. Now RP can verify the assertion with the signature
>>      using OP's public key.
>>
>>   The good thing about this sequence is not only reducing
>>   network traffic, but this can be a solution against
>>   man-in-the-middle attacks, to which OpenID has principle
>>   vulnerability.
>>
>> I think this spec can be quite useful for the next version
>> of OpenID protocol.
>> Does someone know the status of it?
>>
>>
>> =masaki
>>
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>>




More information about the specs mailing list