[OpenID] Signing method for XRD

Mon Jun 15 16:58:51 UTC 2009

I first choose option 3, regarding 4 as the long termer solution.

3 is basically like pulling viewstate upon getting the form postback event.

4 reflects that highend NIC/IPS hardware in the high-end server farm will eventually be doing the work, for high-volume server-side apps designed for crypto/trust/TCP offloading. 4 wont happen till 3 has proven the case requiring hardware support for the actual volumes encountered, though.

A members only list would probably be a better place to get a formal liaison statement. general is an all-comers list, with zero standing in the governance process.

________________________________________
From: John Bradley [john.bradley at wingaa.com]
Sent: Monday, June 15, 2009 5:52 AM
To: Peter Williams
Cc: jpanzer at acm.org; general at openid.net
Subject: Re: [OpenID] Signing method for XRD

To the last part of your comment.

We (The OASIS TC) need to decide how the  XRD is cannonicalized for
signing before we can produce the schema, XSD, and spec.

We are looking for feedback on this topic from a number of communities.

Yes one of the use cases for signing Google has brought to the table
is a Site delegating its openID or other services to a 3rd party.

I don't know that anyone is against signing XRD's.   Signing is
supported in XRDS but is not used by openID or oAuth.

Now that people want signed XRDs we need to make sure that the method
we select works across all of the applications that use XRD/S.

John B.
On 15-Jun-09, at 7:08 AM, Peter Williams wrote:

> 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
>
>