[OpenID] Xrd signing with username token

Santosh Rajan santrajan at gmail.com
Sun Jul 26 16:48:14 UTC 2009


Interesting because I had posted a few days back my wish to see XRD with
layers or levels of security. Something like
XRD with no security
XRD with SSL
XRD signed with generated association
XRD cert signed
XRD cert chain signed
I also think XMLDSig does not scale well in this kind of scenario and thats
the reason we are stuck with the current security model for XRD. Maybe this
is something the Crypto-XML folk need to work on.


Peter Williams wrote:
> 
> Interesting choice - because its the one that goes to heart of a UCI
> control system based on idp discovery supporting the OP portability of
> users.
> 
> Now, the question will be: how will the OASIS folks designing XRD to be
> signed by trusted THIRD parties now act to prevent the re-purposing and
> re-signing of the signed XRD by fourth parties?
> 
> Concerning the association handle/secret, I'm using the association
> handle/secret already agreed by the standardized protocol and method.
> 
> The point is: use the standard public system as a bootstrap into a private
> system. Use the "starter" XRD from some low-assurance source like a Google
> Apps-domain (hosted by Google cloud, now) and apply the existing
> association ...to negotiate a new discovery point and new association at a
> higher assurance level.
> 
> Such a system is only what folks do in military VPN land: having trust
> overlays within trust overlays so that the complexity of navigating the
> very trust fabric becomes part of the realtime key management for crypto.
> It's only what folks do in more conventional SSLVPN tunneling, where the
> certs used in the first handshake create a confidential channel -  over
> which a second round of certs are then shared as a stronger basis for
> agreeing the keys.
> 
> 
> 
> ________________________________________
> From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of
> Santosh Rajan [santrajan at gmail.com]
> Sent: Sunday, July 26, 2009 5:18 AM
> To: general at openid.net
> Subject: Re: [OpenID] Xrd signing with username token
> 
> The notion of a signed XRD being a security token. Is the association
> generated on the fly, like OpenID? How will it work?
> 
> 
> Peter Williams wrote:
>>
>>
>> Hey Santosh
>>
>> But you dont say what it is that you like!
>>
>> Is it the billion trust models?
>>
>> Is it the outsourcing of cert chain validation to the resolver hosted by
>> the OP?
>>
>> Is it the notion of a signed XRD being a securitytoken?
>>
>> Is it the translation of one securitytoken into another,doing
>> role/privilege mapping like a resource-STS?
>>
>>
>>
>>
>> ________________________________________
>> From: general-bounces at openid.net [general-bounces at openid.net] On Behalf
>> Of
>> Santosh Rajan [santrajan at gmail.com]
>> Sent: Saturday, July 25, 2009 10:20 PM
>> To: general at openid.net
>> Subject: Re: [OpenID] Xrd signing with username token
>>
>> Hey Peter I like the Idea.
>> I am not critisizing you here, what I want to tell you, is that I find it
>> difficult to understand what you are saying sometimes, because of the way
>> you write.
>> Does anyone else have the same problem reading Peter's writing, or is it
>> me
>> only?
>> Peter I suggest you use shorter sentences, and take things step by step,
>> like you were explaining to a fifth grader.
>> I like the idea and want to understand this better. Thanks.
>>
>> Peter Williams wrote:
>>>
>>> Precisely.
>>>
>>> Now you have the basis for two properties: data origin authentication
>>> to a specific audience (implied by the association handle), and the
>>> intentional expression of a signed xrd as a control construct -a
>>> "securitytoken" which that audience is entitled to rewrite/re-sign in
>>> line with uci-based governance.
>>>
>>> Let's recall the praxis of xri resolution. In practice, most rp sites
>>> use a proxy resolver (whose model, google notwithstanding, already
>>> addresses signed xrd about either xri or http identities). Now
>>> envision the proxy selected by an rp being operated by the op (for
>>> those identities it and its app domains provision, and for the
>>> identites other providers manage when the op has suitable cross
>>> references bridging the provider-managed namespaces). The proxy
>>> responder rewrites the rsa/cert-signed xrd it has just sourced from
>>> any reachable provider as a usernametoken/handle-signed securitytoken,
>>> playing the role of a resource sts.
>>>
>>> In a uci friendly op, rewriting would apply the rp's trust model for
>>> root anchors. If that op is verisign, say, it's job now is to enforce
>>> a billion trust networks, each expressed as a validation overlay -
>>> applied during token rewriting. In practice, the op (or more likely op
>>> (x)/rp(x) outsourcer) just ties a ctl to each association handle,
>>> listing the self signed root anchors selected by the rp.
>>>
>>> Eliminates:mandatory PKi support in rp systems for openid discovery,
>>> http response signatures, dependency on "browser/os" root stores.
>>> Facilitates: offloading trust management to op/op(x), each rp stays in
>>> control of choice of trust anchors, namespace cross references enables
>>> cloud provider bridging, rp retains power to choose different proxy
>>> resolvers as it's primary reference point ... or do it's own trusted
>>> name resolution.
>>>
>>> Of course, this should sound like xkms/xkiss in concept - but without
>>> the XML overhead. Rather than only tie outsourced trust management to
>>> XML dsig reference resolution, also allow it to be tied to the
>>> discovery handlers in openid rp's.
>>>
>>>
>>>
>>> On Jul 24, 2009, at 1:28 AM, "Hans Granqvist" <hans at granqvist.com>
>>> wrote:
>>>
>>>> Isn't the handle unique per association, which means no one outside
>>>> the association could verify the signature?
>>>>
>>>>
>>>> On Thu, Jul 23, 2009 at 12:01 PM, Peter
>>>> Williams<pwilliams at rapattoni.com
>>>> > wrote:
>>>>>
>>>>> Rather than sign the xrd wit rsa and public cert, can we also imagine
>>>>> signing with a username token, where the digested password is the
>>>>> existing openid association handle for that rp?
>>>>>
>>>>> (username token would have STD timestamp and nonce, to address
>>>>> replay)
>>>>>
>>>>> _______________________________________________
>>>>> general mailing list
>>>>> general at openid.net
>>>>> http://openid.net/mailman/listinfo/general
>>>>>
>>> _______________________________________________
>>> general mailing list
>>> general at openid.net
>>> http://openid.net/mailman/listinfo/general
>>>
>>>
>>
>>
>> -----
>>
>> Santosh Rajan
>> http://santrajan.blogspot.com http://santrajan.blogspot.com
>> --
>> View this message in context:
>> http://www.nabble.com/Xrd-signing-with-username-token-tp24632941p24664110.html
>> Sent from the OpenID - General mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>> _______________________________________________
>> general mailing list
>> general at openid.net
>> http://openid.net/mailman/listinfo/general
>>
>>
> 
> 
> -----
> 
> Santosh Rajan
> http://santrajan.blogspot.com http://santrajan.blogspot.com
> --
> View this message in context:
> http://www.nabble.com/Xrd-signing-with-username-token-tp24632941p24666510.html
> Sent from the OpenID - General mailing list archive at Nabble.com.
> 
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
> 
> 


-----

Santosh Rajan
http://santrajan.blogspot.com http://santrajan.blogspot.com 
-- 
View this message in context: http://www.nabble.com/Xrd-signing-with-username-token-tp24632941p24668435.html
Sent from the OpenID - General mailing list archive at Nabble.com.




More information about the general mailing list