[foaf-protocols] survey: encoding of integers in foaf+ssl ontology

[Bruno Harbulot]

Hi Henry,


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 
consider.

I'll try to clarify some of the points I was trying to make in [1], 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 
some extent.)


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 
our certificate.

  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.


Best wishes,

Bruno.


[1] 
http://lists.foaf-project.org/pipermail/foaf-protocols/2009-December/001210.html

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.
> 
>    http://www.surveymonkey.com/s/WX7DPYY
> 
> 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
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols