Re: [xri] XRD Boostrap & Discovery of Email Addresses -- A Workflow?

[Breno de Medeiros <breno@google.com>]

On Mon, Dec 15, 2008 at 12:27 PM, Brian Eaton <beaton@google.com> wrote:
> 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.

Yes, it is much more flexible and error-proof to assume that the
discovery flow is always insecure, allow all redirects, and then
obtain a document that can self-attest its validity (via signatures).

>
> I'm not wild about this, too hard to implement, too easy to miss when
> it's wrong.
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)