[foaf-protocols] Multiple URIs in SAN extension
akkiehossain at gmail.com
Sat Aug 14 22:54:14 CEST 2010
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
WebID and Cert are sort of interchangeable in my view (maybe incorrectly)
I think the relevant section in RFC 5280 is
Although there are a few others of interest ]
Happy if you tell me I am being overly paranoid.
On Sat, Aug 14, 2010 at 10:28 AM, Henry Story <henry.story at gmail.com> wrote:
> On 14 Aug 2010, at 08:45, Akbar Hossain wrote:
>> 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.
>> 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.
> 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.
>> On Tue, Aug 10, 2010 at 9:04 AM, Henry Story <henry.story at 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.
>>>> ----- Original message -----
>>>>> On 08/09/2010 08:48 PM, Stéphane Corlosquet wrote:
>>>>>> I'm on Bruno's side and I think we should not lock down the SAN to
>>>>>> exactly one URI. If there is time and interest tomorrow during the
>>>>>> call, I'd like to raise this issue.
>>>>> Can you log it as a bug against the spec?
>>>>> -- manu
More information about the foaf-protocols