OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

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