[OpenID] Signing method for XRD

[Peter Williams]

Somebody asked about use cases. For me:-

Today, Janrain detect that your "domain" is authorized to be served by their OP, cooperating with your RPs on their own myopenid.com domain.  Given that authorization, the OP will respond to subject claims issued by RPs about your domain space. E.g. for web2.0: please myopenid.com, provide an assertion about subject = openid2.blogger.com.  E.g. for carrier-class telematics: please google.com, provide an assertion to a phone handset over SS7 about subject = i-number issued by a telco carrier.

To test your authority in the web2.0 example (above), janrain pings a particular resource on your domain. If present, you have established domain delegation, from your domain to the OP's domain. Compared to DNS zone delegation, XRI namespace management, Active Directory parent-child delegation, or kerberos realm or federated trusts its all rather klutzy: but it is cheap and easy. (I tried it on the DNS records I could personally administer, thanks to my Google Apps account) . But, ultimately, this is all relying on DNS and the DNS Security model.

For me, signed XRD cleans that up - dumping the dependency on the public DNS.  It would allow janrain's myopenid to speak for both my vanity blog domain AND my canonical id from XRI land - for example. I dont need to register 2 delegations, with 2 sets of fees.

So, given a receipt of claim request for a given subject in namespace D from some RP, the OP can determine authoritatively (from the signature validation process) whether in the UCI model the user has delegated namespace D to the OP. Much as the RP does discovery to locate an SEP, so the OP can detect the namespace delegation rights. This is the complement of vanity URLs and delegation, of course.

Before someone start talking about the inherent PKI root key chicken and egg problem facing those who must verify the XRD signature, Im not assuming a world in which all XRDs are signed statically using public key.  Im assuming a mixed world, to which one has added dynamically signed XRDs. Signed by derived keys, a transitive trust regime similar to kerberos federated trusts can be validating such signing keys (as can saml tokens from an STS, equivalently).

This is all rather similar to Rivest and Lampson's IETF model for SPKI, expect you dont need a big brain to understand how local naming authority are supported by well known public access trees (located by DNS). The pea-size brain of Peter can understand that the validation key for a signed XRD may come from a key derived from a kerberos service ticket, which is resolved into the security domain of the OP through classical kerberos inter-domain tree walking across namespaces. When kerberos is used for tree walking, and PKI is used to authenticate the well known access points (what Active Directory would call the federation root domain), you get a powerful combination.

now, turning back to "enhaced" delegation, what I still cannot grasp from the snippets of info being disclosed is what the relationship is between the public keys (self) certified in the XRD, the semantics of the issuer URL in the XRD, the domain of the http endpoint serving the XRD, and the cert path of the https endpoint. This is to me is where openid general-level discussion need to focus its attention, not on what blob format or canonicalization issues are involved in signing. We can delegate those minor issue to an engineering team, focused on libraries, adoption, W3C politics, etc.



________________________________
From: general-bounces at openid.net [general-bounces at openid.net] On Behalf Of John Panzer [jpanzer at acm.org]
Sent: Sunday, June 14, 2009 9:47 AM
To: John Bradley
Cc: general at openid.net
Subject: Re: [OpenID] Signing method for XRD

John Bradley wrote:
Peter,

Yes some of us see the possibility of XRD as signed meta-data being a useful alternative to X.509 eventually.

If we have an signature method that supports enveloping signatures,  XRD will be more useful for those applications.

We can opt for the simplest signing, that of signing the binary representation of the XRD and keeping the signature in a detached file.
This may make life simpler for scripting languages dealing with cannonicalization  but at the cost of making it awkward to deal with in other environments where having the signature in the same document is very useful.
For the record, and for those of us not versed in X.509, can provide some use cases and details on how having the signature in the XRD doc is necessary/useful for  for XRD?



Full XMLDsig is ugly because of qnames and other issues.   We are proposing a constrained implementation that eliminates most of the cannonicalization complexities,  but is still compatible with existing libraries.

John B.
On 10-Jun-09, at 12:10 PM, general-request at openid.net<mailto:general-request at openid.net> wrote:

Date: Wed, 10 Jun 2009 09:10:44 -0700
From: Peter Williams <pwilliams at rapattoni.com<mailto:pwilliams at rapattoni.com>>
Subject: Re: [OpenID] Signing method for XRD
To: Santosh Rajan <santrajan at gmail.com<mailto:santrajan at gmail.com>>, "general at openid.net<mailto:general at openid.net>"
<general at openid.net<mailto:general at openid.net>>
Message-ID:
<BFBC0F17A99938458360C863B716FE46398DCE8FDD at simmbox01.rapnt.com<mailto:BFBC0F17A99938458360C863B716FE46398DCE8FDD at simmbox01.rapnt.com>>
Content-Type: text/plain; charset="us-ascii"


my first reaction was ugh - xml-dsig has its own inband mechanism for referencing keying material - and here is openid/xrd doing yet another standard for verifying signatures and validating the supporting keying material (probably poorly).

My second reaction on reflection was that xml-dsig is rarely used to its full potential. Its typically used as a PKCS7 signing and sealing emulation modes, with an XML centric view of the world - with no particular benefit. But, if xml dsig fully uses its external references, and the references are to a world of XRD files which are TRUSTED to act as a key distribution mechanism, things get rather more interesting. In that world, the XRD is becoming a certificate, as we know it - and one whose format and semantics would enable it to go beyond the staid ol X.509 cert chains and benefit the full expression power of xri queries and XRI resolution.

What the X.509 v3 format work took part (divorcing asymmetric key management from dap/ldap resolution), XRI/XRD may be putting back together: query-based named-key resolution supporting trust fabric meshes.



________________________________

_______________________________________________
general mailing list
general at openid.net<mailto:general at openid.net>
http://openid.net/mailman/listinfo/general