[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] XRD Boostrap & Discovery of Email Addresses -- A Workflow?
On Mon, Dec 15, 2008 at 11:40 AM, George Fletcher <george.fletcher@corp.aol.com> wrote: > In the case of following redirects... which URL is supposed to end up in the > final XRD document to maintain a valid binding between the resource > identifier and the document? The starting document. > If we use the initial resource identifier > (http://www.site-delegate.com/xrd?uri=beth@example.com) as the CanonicalID > and end up because of redirects on http://www.other-site.com/xrd/beth, then > the XRD needs to be signed with a cert that is valid for site-delegate.com > (use the SubjectAltName field with multiple entries?). Seems like this would > be problematic from a CA issuance perspective. Maybe if this kind of trusted > delegation is required, the mechanism would just use XRD for delegation > instead of HTTP redirects? Though this does require the intermediate sites > to each sign their XRD use in the delegation path. In practice I think we'll have to use XRD delegation for that. Imagine site-delegate needing to sign documents for a million users, then transfer the signed documents over to other-site.com. Much easier for site-delegate.com to sign a single statement that other-site.com is authoritative for those docs, and then other-site.com can use its own private key. > If we use the final URL (after redirects), then the resolution is subject to > redirect spoofing. This could be mitigated by ensuring that all fetches and > redirects are done over SSL. I'm not wild about this, too hard to implement, too easy to miss when it's wrong.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]