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

---------- Forwarded message ----------
From: Stéphane Corlosquet <scorlosquet@gmail.com>
Date: Mon, Aug 9, 2010 at 8:48 PM
Subject: Re: Multiple URIs in SAN extension
To: foaf-protocols@lists.foaf-project.org


Hi,

Reto committed a change [1] suggesting a simple fix for the multiple SAN URI
entries issue which is to require exactly one URI entry, not sure if he
meant to postpone that issue to keep the spec simple for now or close it
entirely (there is still the same issue in 3.1 as well). There was a thread
[2] on this topic started by Bruno a while back but it only discussed the
other types of entries (like email) without reaching any consensus on the
multiple URI entries.


- Since there can be multiple entries (and some of us have created

certs with more than one SAN entry), are they all expected to be

dereference-able and contain the same public key? Should we impose a

limit of one entry in the SAN extension?


and from [2]

> - Should there be multiple entries of type URI in the S.A.N. extension?


> Possibly. We need to think of what this implies in terms of semantics too..


> I would suggest to allow multiple URI entries:

"The Identification Certificate MAY contain multiple URI entries in the

Subject Alternative Name extension. The Verification Agent MUST attempt

to verify at least one of these entries. It MAY verify more than one

entry. The Verification Agent MUST NOT consider an entry for which the

verification failed as authenticated, even if other entries have been

verified successfully."


> Do we then want to treat multiple successfully verified entries as

owl:sameAs, or should we leave that to the RDF?



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.

Steph.

[1]
http://github.com/retobg/webid-spec/commit/8dafaf5ed6c5e84f48b06e506f03a3d8fd3c1738
[2]
http://lists.foaf-project.org/pipermail/foaf-protocols/2010-July/002775.html


On Thu, Aug 5, 2010 at 12:55 PM, Stéphane Corlosquet
<scorlosquet@gmail.com>wrote:

> Hi,
>
> The WebID spec does not currently cover the case where there are more than
> one SAN URI entry in the same certificate. Do we have scenario where this
> would be useful?
>
> In a typical WebID authentication workflow, if your WebID provider is down
> for some reason, then you cannot authenticate with your WebID (leaving aside
> the particular cases of caching and trusted data sources). If your
> certificate contained another WebID URI, the Verification Agent could then
> dereference this other WebID URI to attempt authentication (provided the
> same public key was published at the second WebID Profile Document as well).
> The problem though is to know what your WebID URI is once you've
> authenticated via an alternate WebID URI. Should the Verification Agent
> trust that you are WebID URI #1 when the authentication sequence via WebID
> URI #1 didn't work and only WebID URI #2 worked? Clearly no, unless you can
> prove that you also own WebID URI #1 by having logged in via this URI in the
> past (in which case the Verification Agent would merge the two identities).
> Is this a good use case to justify the use of multiple WebID URIs in the
> same certificate? It would be equivalent to having to separate certificates,
> but the great advantage is that from user point of view you just have to
> choose one identity, however many WebID URIs you have associated with this
> identity (and you're pretty much sure at least one of your providers/servers
> will be up).
>
> <side-note>This raises a related issue. If we expect WebID to take off and
> to be easy to publish your own WebID, there ought to be ways to work around
> the fact the servers go down, that's one reason why there are so few OpenID
> providers and they are all big players providing decent QoS. In the case of
> WebID, even if you choose the best software implementation you can find on
> the market, you're still dependent on your hosting provider. WebID
> provisioning should work on cheap hosting to be truly decentralized avoid
> the same centralization OpenID has.</side-node>
>
> Do we have other scenario where it is useful to have multiple URIs? There
> might be cases where a URI entry of the SAN extension is not meant to be a
> WebID (think other protocols sticking a URI in a certificate like we do).
> This might be fine and play nicely with the above scenario as long as the
> Verification Agent tries the authentication sequence with each URI entry
> until it finds a matching public key in whatever document each URI
> dereferences to.
>
> thoughts? controversial opinions?
>
> Steph.
>