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