[foaf-dev] # # in urls
tai at g5n.co.uk
Tue Sep 29 00:16:05 CEST 2009
On Mon, 2009-09-28 at 08:53 -0700, Peter Williams wrote:
> As is typical for ignorant Peter, I misnamed the feature I
> half-understood – improperly calling it “multiple” fragments. >From
> the URL syntax, there is only one fragment (whose delimiter is #).
> But, as used in the Microsoft example, additional (#) delimiters can
> be correctly and properly used within the fragment tag. Internal tag
> parsing (using a lexer defined by the resource authority) can signal
> meaning(s) of delimited sub-components.
However, according to RFC 3986 ("URI: Generic Syntax") the "#" character
is not allowed within a fragment. Section 3.5 defines a fragment as zero
or more characters from the set "pchar" or "/" or "?". "pchar" itself is
defined in section 3.3 in terms of other collections of characters, and
so forth, but if you chase them around, it does not include "#".
If you want to use a delimiter withing a fragment identifier, there are
plenty which are allowed. "/" is my favourite, but other good ones
Ultimately what I think you want to do is embed a hash for the FOAF file
into the certificate. (This poses some practical problems as the FOAF
file itself needs to include some information about the certificate. You
could end up in a chicken-and-egg situation. But we'll put that aside
One possible way I see of doing this is to take a SHA1 hash of the FOAF
file, turn it into a URI like this:
(Yes, SHA1 is an unregistered URN scheme, but quite widely used.) Then
include the same hash fragment at the end of that, and include that as a
subjectAltName. (The subjectAltName field in X.509 certificates is a
*list* of values.)
So, assuming that <http://tobyinkster.co.uk/> had a SHA1 hash
of "c70e773f954a522ba14a1ee32c192eea20f096e1", then the subjectAltName
of my X.509 certificate might be:
subjectAltName: email:mail at tobyinkster.co.uk,
The main problem of that, as I see it, is determining what is the SHA1
hash of <http://tobyinkster.co.uk/>? Requesting that URL with an HTTP
Accept header of "text/html" will result in a different stream of bytes
than if you request it as "text/turtle".
And if you change your FOAF file frequently?
No, there must be a better way of doing this. Here's an idea, and I
don't know if it would work, but how about you serve your FOAF file up
using HTTPS instead of plain old HTTP? (If you've got an "http://"
WebID, then you can simply throw an HTTP redirect.) That way, the
transaction between the server that hosts your FOAF, and any clients
that request it, is transmitted over HTTPS - therefore *signed* by the
server's key. The server's key can then be signed by your personal X.509
So, typical use case... you request protected resource A with your X.509
key. The server hosting A checks your X.509 key's subjectAltName and
finds your WebID. It does a request for this WebID and gets a 303
redirect to an HTTPS address we'll call B. The server hosting A requests
B and gets back a FOAF file as response; it checks B's server
certificate is signed by the same certificate that originally requested
A; and it checks that the exponent and modulus in the FOAF data match
the X.509 certificate that originally requested A.
It should work; and it should be compatible with the existing FOAF+SSL
model, just providing an extra level of security for those who want it.
Toby A Inkster
<mailto:mail at tobyinkster.co.uk>
More information about the foaf-dev