WebID-ISSUE-1: Multiple URI entries in the SAN extension

---------- Forwarded message ----------
From: Akbar Hossain <akkiehossain@gmail.com>
Date: Sat, Aug 14, 2010 at 2:45 AM
Subject: Re: [foaf-protocols] Multiple URIs in SAN extension
To: Henry Story <henry.story@gmail.com>
Cc: foaf-protocols@lists.foaf-project.org


Hi,

I personally would be very hestitant adding more than one deferencable
entry in a SAN. URI, email or any other deferenceable combination. So
personally I wouldnt do it but if the capability/allowance is added to
the spec I would probably want an ability to signal to the verify
agent that I want to opt out from this capability.

There are quite a few scenarios such as Henry mentioned related to
losing ownership of one or your webids. Allowing a verifying agent to
spin thru a list of deferenceable references in SAN may leave too much
authority with the verifying agent which would need to specified and
may not be what I would want the verifying agent to do anyway.

So if one of the entries doesnt match (ie can be deferenced but the
key doesnt match because you have been attacked or i am in the middle
of changing keys, or there is a DoS attack on your server) but the
next one on the list does work I probably wouldnt want the verifying
agent to give access to the resource I am trying to access or would I?
Not sure depends on the logic I think the verify agent has. I think
there was another chain that talks about the verifying agent keeping a
record of the public key it witnesses  as well as the webid when is
gave access to a webid. In this sceanrio maybe personally I would be
okay really not sure.

This is not logic I would want to leave to a verification agent unless
I knew exactly the logic it was using to work out the relationships
between the presented webids however deferenced and logic was
acceptable in to me peronsally. At the end of the day the resource I
am access is asserting that I accessed the resource.

Which raises an interesting question - if the spec says multiple SANs
are allowed how do I opt out of it. Given that the security the verify
agents may apply might not be up to the standard I would want.

I would prefer as an identifying agent specifying this type of logic
in the certificate (either the X.509 or webid) namely what is the
policy the verfying agent to observe when I present my certificate.

I think  this came up before on this thread.

http://lists.foaf-project.org/pipermail/foaf-protocols/2010-February/001772..html
from Peter Williams

I find this post on the that thread pretty interesting too.

http://lists.foaf-project.org/pipermail/foaf-protocols/2010-February/001772..html

Restricting to one entry in the SAN (at this time) avoids the
immediate need to look into this right now - IMHO

Regards

On Tue, Aug 10, 2010 at 9:04 AM, Henry Story <henry.story@gmail.com> wrote:
>
> On 10 Aug 2010, at 09:11, Reto Bachmann-Gmür wrote:
>
>> My latest draft, which I think you pulled mandates exactly one URI.
>>
>> I don't know about reasons or avantages of having multiple uris.
>
> One can have multiple URIs in a SAN that is a fact of X.509. We don't know
what the advantages may be of having multiple. So unless we can prove that
it is illogical, we should not mandate having only one.
>
> Furthermore I think there is a case to be made for having multiple URIs in
a SAN for failover.
>
> The way to deal with it is furthermore very simple.
>
> For every URI wid1, wid2, wid3, ... for which the WebID proof works it is
true that
>
>   pkey cert:identity wid, wid2, wid3 ...
>
>
> since cert:identity is (well it should be) an owl:functionalProperty, it
follows that
>
>    wid = wid2 = wid3 = ...
>
> This is useful for the RelyingAgent to know, as if at a later date one of
those
> fails to be dereferenceable it can use the others.
>
> Note that though this does give the user failover protection, it also
increases
> the number of ways he can be attacked.
>
> But it is not that easy to create one X509 cert with many WebIDs in it, if
it is not somehow coordinated by the same service, so there is reason to
think that when it is used, it is used conscientiously.
>
>        Henry