Re: rsa ontology in cert namespace

On 22 Nov 2011, at 18:39, Mo McRoberts wrote:

> 
> On 22 Nov 2011, at 15:30, Henry Story wrote:
> 
>> I think the proof of the pudding is going to be what kind of definition we come up for those relations and just how convoluted they are going to be. Well it looks like the only overlap is with cert:modulus. So it could be defined as:
>> 
>> cert:modulus rdfs:label "RSA or DSA key public modulus"@en;
>> vs:term_status "unstable";
>> rdfs:comment """
>>     The number known as the modulus in either an RSA Key or a DSA Key
>>  """@en;
>> rdfs:domain :RSAPublicKey, DSAPublicKey;
>> rdfs:range xsd:hexBinary, xsd:base64Binary .
>> 
>> Notice that here we have to choose to either use a binary to represent the modulus or an integer type. The binary makes sense for the rsa public modulus, which is usually a very big number. But I am not sure if the DSA modulus is also a big number in the same way. It would be pure luck if it were.
>> 
>> Now with respect to the other DSA fields should those be xsd:integer or xsd:hexBinary (or base64Binary) ? The way we have decided in the case of the rsa exponent is that there it is usually a small number, and (therefore?) that  it is usually shown as an integer in base10 notation.
> 
> I would, to be honest, allow both ASCII-integer and encoded-binary formats for everything — although presumably this might cause problems in comparisons?

Well we want to only have one data-type, and a standard xsd one if possible in order to make a simple SPARQL ASK query possible. With a bit of server side code we can currently request all keys from a graph with a particular WebID and then iterate through each one of those and do all the transformations in code we like. But that means a lot more code and a lot more bandwidth used. The ASK Query will allow us to improve our claim of utter simplicity.
> 
> The reality is that these are all defined as 'arbitrary-precision unsigned integers', and by my reading of xsd-datatypes, xsd:integer can hold integers of *any* length (unlike xsd:long, xsd:int, etc.), represented in base 10. There's no fundamental reason why people shouldn't be allowed to write out the modulus and exponent in base-10 if they want to, other than it not being as compact as hex due to the digit-space.

The only reason is that 
 1. certificates tools tend to all display them in hex format, so that comparison is easier if one can do a quick comparison like that
 2. there is no xsd:hexInteger and xsd:base64Integer - that is what we are all missing
 3. it is a bit longer to write the numbers out in base 10

These are really silly issues, but we are kind of stuck with them. the xml-dsig people went to encode everything in base64. 

I tried coming up with cert:hex which looks nice, allows you to put peace symbols in your hex and does a lot of other cool things, but then we can't do a simple SPARQL ASK query because it is not standard. I am thinking here of large providers that would want their queries to be extremely efficient. 
Do you have a DSA certificate? Then we can quickly look up how these are displayed in openssl and in keychains on different operating systems?


> 
>> Do things get nasty where we then to add Elliptic Curve Cryptography?
> 
> From skimming the spec, I don't believe so, though it'll certainly need a few more properties being defined (and not all of them integers).

Ah ok. Again I think that ECC has a problem that there are ways to write out the same key (i.e., many different numbers), which means that one would have to be more careful in specifying how to do matches. I am pretty sure this is not the case with RSA, though I am not sure with DSA.

Henry


> 
> M.
> 
> -- 
> Mo McRoberts - Technical Lead - The Space,
> 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
> Project Office: Room 7083, BBC Television Centre, London W12 7RJ
> 
> 
> 

Social Web Architect
http://bblfish.net/

Received on Tuesday, 22 November 2011 17:55:08 UTC