[foaf-protocols] survey: encoding of integers in foaf+ssl ontology
Bruno.Harbulot at manchester.ac.uk
Sat Dec 19 17:59:54 CET 2009
Before going through a vote, I think we should state what the purpose of
this choice is: there are both practical and theoretical matters to
I'll try to clarify some of the points I was trying to make in , my
main concerns here being the consequences on the implementations and the
possibility to broaden the approach to a more general model for
certificates in RDF. (I also question why using hex notation at all to
In theory, -0x03 is fine, in practice I agree, but this notation is of
no use for what we do. It's not because wikipedia mentions it that we
should use it.
In theory, the base in which we write the modulus doesn't matter. In
practice, the hexadecimal notation is convenient:
1. Tools such as Firefox and OpenSSL show this number in hexadecimal
notation, so it's easier to debug when we (humans) look at something
like <https://foaf.me/simpleLogin.php> to see if it matches what's in
2. I'm not sure how library support is for parsing big decimal
numbers. BigInteger in Java works fine, but direct support for big
numbers in programming languages is likely to be a problem: that's the
reason we use sequences of bytes at this stage. The hexadecimal notation
has the advantages that the algorithm for parsing such a sequence is
fairly easy: each block of 2 characters make a byte, and more or less
all languages can support that.
If you don't think these reasons matter when making this choice, then
why use cert:hex at all? Decimal notation using xsd:integer would have
been just fine and we can drop cert:hex and its variants altogether.
After all, isn't it usually recommended on the semantic web not to
re-invent new vocabularies, but reuse what's well established?
If you do think these reasons matters, then that's why it becomes a bit
tricky. The main problems being (a) the ready-available implementations
to parse big numbers (or arrays of bytes) and (b) what happens if we
model more than the public key components, for example other attributes
or the entire certificate.
(a) The question here is do many languages support big integers more
or less natively (like Java's BigInteger) or should we rather assume
that we're going to have to compare the sequence of bytes (I suspect the
latter). I know comparing the sequence of bytes instead of the big
number doesn't sound very elegant from a semantic point of view, but
that's what happens in practice. It's not our fault if RDF isn't
well-suited for handling what's not text.
(b) I think we should aim to have a vocabulary to model everything
possible about an X.509 certificate, so as to be able to build a bridge
with existing certificate-based mechanisms (e.g. what Peter has been
investigating in the Windows world). This will be important to integrate
FOAF+SSL with existing enterprise solutions.
I'm not saying we should model everything in an X.509 certificate right
here, right now, but at least be able to write things. I'm not planning
to chase up all the semantics for all the OIDs of the extensions that
may be present in a certificate (associated with the fun of ASN.1
parsing), but there may be cases where it would be useful to store an
extension in an RDF store without losing information, if only to let
another tool that understand that extension use it at a later point.
This will required storing the arrays of bytes as they are, not as
integers. In this domain, zeros that are not significant in the
arithmetic context are actually significant.
This is also very important when it comes to modelling signatures: you
have to remember that one never signs the semantics but the
representations instead: how this information is encoded into a sequence
of bytes really matters then.
Story Henry wrote:
> I put a survey together for this question. Please take a bit of time to answer it. This will help us get a general feel for how the discussion has progressed.
> PS. I habe kept Peter Williams' proposal, even though he no longer supports it, because it was part of the discussion.
> Henry Story
> Social Web Architect
> Sun Microsystems
> Blog: http://blogs.sun.com/bblfish
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
More information about the foaf-protocols