[foaf-protocols] Why SAN?

Melvin Carvalho 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
> certificate.

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.

> Best,
> Nathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100917/382b1442/attachment-0001.htm 

More information about the foaf-protocols mailing list