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

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


On 14 Aug 2010, at 08:45, Akbar Hossain wrote:

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

Perhaps one way to get at this problem is to consider what the difference
between the following is

 a) an X.509 cert with 3 WebIDs (wid1, wid2 and wid3) in the Subject
Alternative Name (SAN)
 b) 3 X.509 cert with each with one of the above WebIDs in the SAN and each
certificate with the same public key

So let's imagine in scenario (b) you login with the first certificate
but your site is down, so it is rejected and then your browser asks
you for the next certificate, and that site is down too, so you send your
third and that is accepted. Here the site would know you as wid3.
It would not have confirmation that you were wid1 or wid2.

Call the ssl connection :conn123. The server agent then knows the following

{
  wid3 initiatorOf :conn123 .
} sessionFactsFor :conn123 .

>From there if it believes from some other source that

{
 wid3 = wid1 = wid2 .
}

Then any conclusions it makes by merging the first and the second graph
should be something it can assert with the a confidence that is some
function of the confidence it has in each graph. (We don't go into
confidence reasoning here, as this is way beyond the scope of the WebID
protocol.)

I think if all three SAN's were in the same X.509 certificate then
the exact same reasoning applies. If the verification of any of the WebID's
fail - or is not completely due to lack of interest or time - then the
Relying Party ends up with the identity in its sessionfacts graph for only
those in which verification succeeded.

there is something new though because from the session graph itself the
Relying Party can make a special deduction. Let us say wid3 and wid1
verification succeed. Then

{
  wid3 initiatorOf :conn123 .
  wid1 initiatorOf :conn123 .
  wid1 knowsPrivateKeyFor pk .
  wid3 knowsPrivateKeyFor pk .
} sessionFactsFor :conn123 .

Because we defined knowsPrivateKeyFor as being inverse functional, from this
it also knows that

  wid1 = wid3 .

In the scenario where three certificates are sent one after the other, the
user agent would only be able to infer something like this after merging
session information from two different sessions.


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

Then you only get a certificate with one WebID in the SAN.

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

Is the above explanation satisfactory?

>
> 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 understand your hesitation. That post is so long I lost the
direction of the argument. Can you summarise what it says that
is relevant to your question here?

>
> I find this post on the that thread pretty interesting too.
>
>
http://lists.foaf-project.org/pipermail/foaf-protocols/2010-February/001772..html

That's the same article.

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

Yes, but one should have justifications for limitations one imposes that are
more than just "we have not thought about it". And on the whole one should
avoid limiting things arbitrarily.


> 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