[foaf-protocols] Why SAN?
melvincarvalho at gmail.com
Fri Sep 17 17:48:43 CEST 2010
On 17 September 2010 17:41, Nathan <nathan at webr3.org> wrote:
> Melvin Carvalho wrote:
>> On 17 September 2010 16:41, Nathan <nathan at webr3.org> wrote:
>> Hi All,
>>> I'm not suggesting anything change, but I am interested to assess
>>> whether we *need* to put our WebID in our certificate(s)? This is fairly
>>> subjective in that it wouldn't work with the way the WebID protocol is
>>> mapped, but if subjectAltName had never been thought of, would all the
>>> constraints which make WebID what it is still be valid if we passed our
>>> WebID by some other means..
>> Your public key is a globally unique identifier.
>> The verifying agent needs to pointer as to where to look for your WebID.
>> SAN seems the logical choice.
> Indeed, SAN, or more accurately "in the certificate" is the logical choice
> (personally would still prefer a dedicated x509 extension rather than
> reusing SAN but that's a different issue) - however does it make a
> difference, all that's needed is that the verifying agent knows the WebID &
> public key and has done the TLS thing to prove (owner/holder)-ship of said
> public key.
> What "other means" could be suggested?
> Well as an example (not necessarily a good one) you could pass your webid
> in an HTTP header over HTTP+TLS. Even though this isn't the best example,
> the point is to figure out whether everything could still work without
> breaking anything fundamental, if so then when it comes to mapping WebID to
> other +TLS protocols now or in the future then a good example may pop up and
> we'll know a priori if it's an option to have WebID transported outside the
There's no fundamental reason, imho, that the webid reference need be
embedded in the certificate.
In fact there's no reason to send it at all, assuming there's a good
directory of public keys in the linked data cloud (think GPG servers)
I think it comes down to what is practical.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the foaf-protocols