Service Key Discovery 1.0
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@openid.net http://openid.net/mailman/listinfo/specs
Re: Service Key Discovery 1.0
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? 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 [EMAIL PROTECTED] 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@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Service Key Discovery 1.0
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 [EMAIL PROTECTED] 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@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
PGP Key as OpenID
Hallo would it be possible to have the PGP key with a password as well as an entry point for the OpenID defined? So why a username and password, the PGP key with a password should be added. What has to be done, to get this into the definitions? Thanks Mike ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: PGP Key as OpenID
On Jan 21, 2008, at 4:05 AM, Michael Schmidt wrote: Hallo would it be possible to have the PGP key with a password as well as an entry point for the OpenID defined? So why a username and password, the PGP key with a password should be added. What has to be done, to get this into the definitions? Thanks Mike Mike, The OpenID Authentication spec intentionally doesn't define how an OpenID provider authenticates users. You can use whatever mechanism you want at the provider instead of a username and password. -- Trevor Johns http://tjohns.net ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
Re: Service Key Discovery 1.0
FWIW, the XRI form of openID's provides just such a mechanism, where- by the publisher of the XRD signs all (or a part of) the XRDS, tho i know of few libraries today which support trusted resolution[1]. =peterd [1] http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0- cd-02.pdf On Jan 21, 2008, at 5:38 AM, NISHITANI Masaki 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@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
RE: Service Key Discovery 1.0
Masaki, Peter has a good point -- the XRDS keyinfo discovery mechanism, specified in section 10.2 (SAML Trusted Resolution) of XRI Resolution 2.0 Committee Draft 02 (http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0-cd-02.pdf ), deals with DNS poisoning by using signed SAML assertions (including the ds:keyInfo element) for each authority in the resolution chain. So presuming HTTPS is used for the first root authority call, you should be good all the way down the chain as long as signatures verify. (Peter's also right that libraries have not implemented it yet, but that may be changing soon as demand for secure key discovery rises...) =Drummond -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Davis Sent: Monday, January 21, 2008 6:33 AM To: NISHITANI Masaki Cc: specs@openid.net Subject: Re: Service Key Discovery 1.0 FWIW, the XRI form of openID's provides just such a mechanism, where- by the publisher of the XRD signs all (or a part of) the XRDS, tho i know of few libraries today which support trusted resolution[1]. =peterd [1] http://docs.oasis-open.org/xri/2.0/specs/cd02/xri-resolution-V2.0- cd-02.pdf On Jan 21, 2008, at 5:38 AM, NISHITANI Masaki 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@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs ___ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
