X509V3 Custom Extensions to support WebID

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.

             - Erich

http://www.ebremer.com

Received on Thursday, 24 January 2013 15:37:23 UTC