Re: X509V3 Custom Extensions to support WebID

On 24 Jan 2013, at 16:35, Erich Bremer <erich@ebremer.com> wrote:

> Hi,
> I am relatively new to the WebID party so I apologized if this has been discussed already.  I didn't see any mentions of it in the group's e-mail archives.  When I was considering my response to the WebID hash questionnaire last night, to me, many of the arguments in the definition of WebID of whether to hash or not to hash stem from conflation of URI and URL in the X509v3 Subject Alternative Name.
>    Has the use of X509v3 Custom Extensions been considered to help support the location of the data about the URI as specified in Subject Alternative Name rather than infer it from the Subject Alternative Name itself?  Custom extensions are permissible in X509v3:
> 
> Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
> Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING }
> 
> references:
> http://www.openssl.org/docs/apps/x509v3_config.html#ARBITRARY_EXTENSIONS
> http://www.ietf.org/rfc/rfc3280.txt
> 
> Several custom extensions/OIDs could be created to tell the validating server *where* to find the data.  Roughly, create the following scenarios:
> 
> 1) No custom extensions listed - default behavior, use the URI in Subject Alternative Name as a URL for the profile (removing the hash if necessary)
> 
> 2) OID A.B.C.1 - explicitly specify a URL for the profile rather than infer it.
> 
> 3) OID A.B.C.2 - specify a SPARQL Endpoint URL - I don't see why a WebID could not be validated against a SPARQL endpoint and it would allow the validating server to pick ala cart what it wants rather than download the whole file.
> 
> 4) OID A.B.C.3 - specify a LDP
> 
> 5) OID A.B.C.4 - specify URL for the SPARQL 1.1 Graph Store HTTP Protocol
> 
>    Providing these data location hints to the validating server in the form of custom X509v3 extensions would appear to be useful and Subject Alternative Name could then just be a URI rather than a URI/URL.

Hi Erich, thanks for the input.

   Creating custom extensions is someting we'd like to avoid: they are not well 
supported by browsers, take a lot of time to get adopted, and lead to dicsussions,
etc....

Furthermore we don't have a problem where we need this to be solved.
The hash discussion issue was more in line with trying to make things as simple 
as possible for the WebID spec. This has nothing to do with any limitiations 
in the X509 Certificate SAN or IAN fields. Everyting works fine there. 

It would be much better for the WebID PRofile itself to point to any of those
resources: mostly because it is much easier to change  a web profile than
a web certificate :-)

	Thanks again, I look forward to your vote :-)

	Henry


> 
>            - Erich
> 
> http://www.ebremer.com

cool site!

> 
> 

Social Web Architect
http://bblfish.net/