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