[foaf-protocols] Multiple URIs in SAN extension

Reto Bachmann-Gmür me at farewellutopia.com
Tue Aug 10 09:20:55 CEST 2010


----- Original message -----
> 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 missed this mail ans missread the next one. I can very well live with the proposal above too. As for identity I don't think the verified claimed webids should be threated as owl sameAs. But rather as potentially different identities the holder of the key pair may legitimately represent. I'm thinking at a collective profile cotaining public keys of its members that may subsequently act with both there individual as well as with the rights of that collective.

Cheers,
reto
> 
> 
> 
> 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 at 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.
> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100810/965d246b/attachment.htm 


More information about the foaf-protocols mailing list