[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] RE: Delegation (was: trusted discovery workflow)
On Fri, Dec 5, 2008 at 12:27 PM, Ben Laurie <benl@google.com> wrote: > On Fri, Dec 5, 2008 at 7:10 PM, Breno de Medeiros <breno@google.com> wrote: >> And the endpoint would be signed because it is a legitimate endpoint >> for a different purpose? > > The endpoint would not need to be signed because it is already in the > current authority (which was the initial one). As far as I understand the current proposal, trustworthiness requires signatures even if the endpoint is in the same domain. > >> >> Sounds to me like a defacement type of attack (mapping some services >> in the domain to others). Probably less interesting to do than >> straight defacement or DoS. > > So, you are arguing that we should not defend against it because it is > less interesting than other attacks? We seem to have a different understanding of trustworthiness (see above), so the category of attacks that you are indicating is potentially larger than what I had in mind. But with proper caveats, yes. > >> >> On Fri, Dec 5, 2008 at 10:53 AM, Ben Laurie <benl@google.com> wrote: >>> On Fri, Dec 5, 2008 at 6:24 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote: >>>> This makes sense to me, but I think the challenge is how to codify this behavior in a way that is easy to understand and implement... It is way too easy to screw this up. >>> >>> It seems quite simple to me. At any point I have a current authority, >>> and until I hit an XRD signed by that authority, it doesn't change. >>> When I do, it becomes whatever the new XRD specifies. When I reach the >>> end, the current authority must be authoritative for whatever resource >>> I end up with. >>> >>> I do worry, though, that there could be some kind of attack where >>> (forged) unsigned delegations are used to point some service at the >>> wrong endpoint in the same domain, with the result that Bad Things >>> happen. >>> >>>> >>>> EHL >>>> >>>>> -----Original Message----- >>>>> From: Brian Eaton [mailto:beaton@google.com] >>>>> Sent: Friday, December 05, 2008 9:58 AM >>>>> To: Eran Hammer-Lahav >>>>> Cc: xri@lists.oasis-open.org >>>>> Subject: Re: [xri] RE: Delegation (was: trusted discovery workflow) >>>>> >>>>> On Fri, Dec 5, 2008 at 9:46 AM, Eran Hammer-Lahav <eran@hueniverse.com> >>>>> wrote: >>>>> > A domain delegating the management of their services to a third >>>>> party. Hosting and managing XRDs can and should become a product. Of >>>>> course, if you <ref> the entire XRD, you can as easily just point the >>>>> Link in that direction in the first place but it only works well with >>>>> Link header and element where you have a resource level control. If you >>>>> use a /site-meta map, it is impossible to point some XRD locations to >>>>> server A and some to server B (at least this is a use case I refuse to >>>>> support due to complexity). I much rather allow this to happen using a >>>>> simple <Ref> in the local XRD itself. >>>>> >>>>> This sounds like a reasonable use case, and I think it'll fit into the >>>>> trust workflow. >>>>> >>>>> - If the initial XRD is not signed or does not delegate to a new key >>>>> in the trust chain, the next XRD must be signed with a key >>>>> authoritative for the initial XRD. More concretely: if I don't >>>>> specify that somebody else can sign an XRD for me, that next XRD needs >>>>> to be signed by me. >>>>> >>>>> - If the intial XRD is signed, it can point to a new key that will be >>>>> used to sign the next XRD. >>>> >>>> --------------------------------------------------------------------- >>>> 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 >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> 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) >> > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]