[OpenID] XRI TC - An Outsiders perspective

[Peter Williams]

PKCS7 does not have some of the things that are cute about xmldsig. But, it does have counter-signatures (as used in authenticode, to enforce a 3-party validation logic controlling "_authorized_ signing") and parallel signatures. XMLDSIG goes further than PKCS#7 was designed to go, especially in the "on the spot/fly" stuff.

Rather than use PKCS7's signed ASN.1 type, let's see what we COULD do (easily) to apply signed XRDs (based on xmldsig) to its fullest potential - using whatever canonicalization scheme for signing that folks decide on. (Obviously, everything I say below about signed XRD and XRD paths also applies to signed FOAF files and FOAF paths.)

If an XRDS has two XRDs, the final XRD's signature can be hashing over the previous XRD in the path, too. This is a cute feature of xmldsig, allowing n inputs to the integrity function. Depending on how one formulates the URI-based data references in the signature block, the data source of the earlier XRD can be tied (or not) to the same data source as the XRD in question. And lets remember, that "data sources" can be access controlled by RP, using OAUTH/openid hybrid guards. Thus your capability as a "client" to even verify/rely on XRD#1 of a "server" can be gated on having due access to an unexpired superior XRD, in an XRD "path". You may also have to be a subscriber of the bus, to get it!

Now, lets assume the 2 XRD data sources are distinct. One is google bus for app domains, another is peter's actual app domain. Let's also assume that each of the 2 XRDs at data sources that need to be "linked" by https references are _independently_ mounted on http URLs, at 2 distinct (openxri) servers. We do this "becuase" the 2 (note always 2 [or more]) XRDs are not managed by the same authority or trust federation. However, as the admin of peter's domain, I want/need to express the delegation of my endpoints to Google bus. (Note, how I just inverted the power relationship, where the minor asymmetric party acts as "issuer".)

My domain's self-signed XRD "file" can have 2 references: to its own data stream  and to the XRD value mounted at that 2nd http mount point (google's current OP XRD, say).  Any signature "resolver" acting on XRD#1 MUST de-reference XRD#2 data stream - to verify the linking built into the signature process. Thus, a given signature block's references play the role that Google SEP for service-bus delegation plays.  If the client proxy doing such resolution cannot even get a session with Google Bus, then perhaps it cannot even see the Google OP XRD, and thus cannot even compute a route to my endpoints (via Google bus).

Having inverted the asymemtric power relationship, lets note that it's now crypto (vs SEP-centric app logic) that "epxresses" the validity logic for such a delegation relationship. Assume the client proxy reteives, validates and then puts the signed XRD of peter's (RP) domain into the outgoing request, much as one puts token into ws-security-style protocol. As this is received inbound by google bus, google can opt to rely or not - depending on whether it "recognizes" the domain's up-delegation to Google bus. TO rely, it has to verify the signed "path", and handle cert chain authorizations.

More conventionally, by now using the certs supporting the xmldsig values on the two XRDs, cert-based authorization and privilege parameters (security labels on the keys and privilege flags in the XRD) use to uses lattices to cross-authorize and cross-denote who and what has delegated to whom else and what else for which purpose - much as folks in the the US defense messaging system today to represent such as whether a given admin can read cetain parts of an officer's secure email for upto 2 weeks, while she vacations. If one were to get fancy, one could apply XDI conventions for addressing XRI arcs, and use such XRIs as references in the XMLDSIG block - classifying a given delegation link as a "delegation type D" relationship type. But, that's getting fanciful.

Id prefer this kind of world (not that I expect to get it) to the proposed model, as now a given domain could even be placing _parallel_ signatures in the XML DSIG block - each one pointing to the OP/Bus XRD of a _different_ service bus provider. That is: there is 1 up-delegation to Microsoft, and another up-delegation to Google.  Neither Microsoft not Google get to _control_ that domain's "portable" endpoints, that way. Of course, this competes with the current way do doing this kind of thing, where we place multiple SEPs in a signed XRD.

See what fun you can have with signed certs/XRDs for authentication, authorization AND delegation!
_____________________________________
From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of SitG Admin [sysadmin at shadowsinthegarden.com]
Sent: Sunday, July 12, 2009 2:07 PM
To: Santosh Rajan
Cc: general at openid.net
Subject: Re: [OpenID] XRI TC - An Outsiders perspective

>Whenever a new technology is released people react in one of two ways.
>1) Awesome! This is so simple. How come we never thought of this?
>2) Jeez! This is so complicated! Do I need this?

Or the oft-hushed "1.5) Finally, was wondering when someone would put
this into production." ;)

>I was suggesting we dont use XMLDSig at all. Maybe we should look at PKCS7
>which is available everywhere. Also transporting a signed document is not a
>problem if we were to select a proper Content Type.

And then translate "on the spot" every time we need to parse the
file? In the past, I have had to port a document between multiple
computers, operating systems, and applications, to get it into a
readable form, because the final (preferred) reader was not directly
compatible with the original format. XMLDSig provides a way for each
layer to translate it to "native" format as needed, without affecting
the ability of any layer (even the last) to verify its signature
later on.

-Shade
_______________________________________________
general mailing list
general at openid.net
http://openid.net/mailman/listinfo/general