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

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


H,

I'm not saying dont allow (limit) it in the spec - or dont try to work
out how to do it - or what the necessary security considerations are.
I think I am saying the opposite. I am sure it can be done and it will
be correct if certain conditions can be assured. Just suggesting some
people (myself included would want to signal an opt out). My concern
is not the spec given the skill of everyone here. My concern is about
the "implementation efficiencies" some may try to put in place.

Perhaps if I go thru a scenario that I was thinking about.

1. I create a certificate and link it correctly to a WebID via the SAN
and backlinking the RSA Public Key. All good.
   Only one entry in the SAN. Call this webid 1.

2. I log into site A with my certified WebID 1. All good.
   (Question what has this site recorded? Just my WebID or WebID and
Public Key. I have a feeling this is now a critical
    question. Not sure it is critical with one SAN entry - allows you
to change the Public Key at will etc)

3. I take my WebID down or Mr Hacker takes its down with a DoS.

4. Mr H now creates a Certificate with two entries in it. First one
pointing to my WebID (now down) and a second one to URI
  (webid 2) they control. Unlikely to be the same Public Key as on
webid 1. (But if not recorded you would never know public key
  - unless you are looking at other things).

5. Mr H now tries  Site A. What does Site A do? Unless Site A recorded
my public key i dont think it can say webid 1 and
   webid 2 are the same. We all know they are not and Site A never
saw webid 2 from me.

So I think your logic is correct if all webids in the SAN are checked
and correct.  I don't dispute your logic. I am wondering if it only
applies if at the moment of login everything and all back links are
checked and no efficiencies will be made. So i'm not sure what i have
gained that could not be done directly in the WebID 1. Sure my
certificate has a backup option but at quite a risk of verifying
agents implementation and caching of the public key. I have a feeling
only what the site saw when i logged in could be said to be
equivalent. So what have I gained.

I sort of feel the same way about the comments on caching now.
Although I would need  to look thru the emails and documentation a bit
more  closely. I would think I personally would want to signal that I
dont want a verifying agent to rely on cached results. (Not sure)

[The link to the previous thread I sent if you want a summary in
essence says I the owner of my WebID (certificate) permit the
following use of my WebID if you every see it this is the only
appropriate use.

WebID and Cert are sort of interchangeable in my view (maybe incorrectly)

I think the relevant section in RFC 5280 is
http://tools.ietf.org/html/rfc5280#section-4.2.1.4
Although there are a few others of interest ]

Happy if you tell me I am being  overly paranoid.

Thanks

On Sat, Aug 14, 2010 at 10:28 AM, Henry Story <henry.story@gmail.com> wrote:
> 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
>>>
>>>>
>>>> Cheers,
>>>> reto