Re: rsa ontology (in cert namespace?)

Ok, I am adding Thomas Roessler to the CC list, as he was involved with the http://www.w3.org/TR/xmldsig-core/ . Perhaps there are other people form that group we should ask.

So in short to bring those members up to date the WebID XG needs an ontology of public keys. We already have one for RSA

   http://www.w3.org/ns/auth/rsa

but we are thinking now of aligning it with the XML work, so that we can mesh better. The above ontology use the cert:hex datatype which we are finding is not ideal, and which we would like to deprecate in favour of xsd:hexBinary ( and therefore of xsd:base64Binary , since that is just another notation for binaries ). cert:hex is not ideal because it does not allow simple ASK queries such as the following to be made, and we want these queries to be as efficient and as easy to understand as possible:

PREFIX cert: <http://www.w3.org/ns/auth/cert#>
PREFIX rsa: <http://www.w3.org/ns/auth/rsa#>
ASK {
   <http://example.org/webid#public> cert:key [
      rsa:mod "9D79BFE2498..."^^xsd:hexBinary;
      rsa:exp 65537;
   ] .
}

( for more background on this see the latest WebID draft http://bblfish.net/tmp/2011/11/21/index-respec.html )

So here would be the updated set of relations for the rsa ontology over what we have now. We would deprecate
rsa:modulus and replace it with 

rsa:mod a owl:DatatypeProperty;
  rdfs:label "RSA modulus"@en;
  vs:term_status "unstable";
  rdfs:comment """    
  The modulus of an RSA public and private key. 
  This is defined mathematically as n = p*q
  The modulus is usually a very long integer which is most often displayed in crypto graphy tools in hexadecimal format.
  The object of this relation is therefore a binary which build as specified by the <a href="http://www.w3.org/TR/xmldsig-core/#sec-CryptoBinary">ds:CryptoBinary</a> in the xml:dsig spec, namely:
<quote cite="http://www.w3.org/TR/xmldsig-core/#sec-CryptoBinary">
The integer value is first converted to a "big endian" bitstring. The bitstring is then padded with leading zero bits so that the total number of bits == 0 mod 8 (so that there are an integral number of octets). If the bitstring contains entire leading octets that are zero, these are removed (so the high-order octet is always non-zero).
</quote>
  The encoding can be in hexBinary or in base64Binary formats. 
  For the WebID protocol, these currently MUST be in xsd:hexBinary, as those are easier to compare with encodings provided by tools such as opensso. As soon as the SPARQL group makes it possible to map each encoding to the other, the MUST can be lifted.
  """@en;
  rdfs:domain :RSAKey;
  rdfs:range xsd:hexBinary, xsd:base64Binary .



	Henry

PS. we can work on the DSA ontology later. 
PPS. I am trying to do minimal changes here



On 22 Nov 2011, at 10:51, Mo McRoberts wrote:

> 
>> Mhh, yes. I suppose the best is to look at what the 
>> XMLSignature group have come up with, since they have both in 
>> the same namespace
>> 
>>  http://www.w3.org/TR/xmldsig-core/#sec-KeyValue
>> 
>> They use Modulus and Exponent with capitals, and for dsa they use 
>> 
>> P
>> Q
>> G
>> Y
>> J
>> seed
>> pgenCounter
> 
> Okay, RFC3279 is probably your best reference for this stuff.
> 
> In RSA, the modulus and exponent tend to be called 'n' and 'e', respectively, but some variant on 'modulus' and 'exponent' are fine *if* you ony want to store public keys (if you want to cover private keys -- though I'm not sure why you would -- then they're ambiguous). The DER-encoded RSA public keys (as well as the PGP equivalent) may include additional values, but these are derived from 'n' and 'e' and are provided for computational convenience and shouldn't be included in a canonical representation.
> 
> DSA has the parameters 'p' (a modulus), 'q' (a divisor), and 'g' (a generator value); 'y' the a public key (you need all four of these). You shouldn't need 'J', 'seed' or 'pgenCounter' to canonically represent it. You could call these dsaModulus, dsaDivisor, dsaGenerator and dsaPublicKey in a unified (cert) ontology which is never going to include private keys.
> 
> All of these values are arbitary-precision integers.
> 
>> They encode both in 
>> http://www.w3.org/TR/xmldsig-core/#sec-CryptoBinary
>> 
>> [[
>> This specification defines the ds:CryptoBinary simple type 
>> for representing arbitrary-length integers (e.g. "bignums") 
>> in XML as octet strings. The integer value is first converted 
>> to a "big endian" bitstring. The bitstring is then padded 
>> with leading zero bits so that the total number of bits == 0 
>> mod 8 (so that there are an integral number of octets). If 
>> the bitstring contains entire leading octets that are zero, 
>> these are removed (so the high-order octet is always 
>> non-zero). This octet string is then base64 [MIME] encoded. 
>> (The conversion from integer to octet string is equivalent to 
>> IEEE 1363's I2OSP [1363] with minimal length).
>> ]]
> 
> That's a reasonable approach to encoding arbitarary-precision integers. I'd roll with that. Essentially, that's what you've been assuming the encoding as xsd:hexBinary actually is anyway.
> 
> As for ECC - I don't know enough about it to spec the properties required, but there's a spec in RFC3279 for their representation as ASN.1, so there's no technical reason why they couldn't be represnted as RDF.
> 
> M.
> 
> -- 
> Mo McRoberts - Data Analyst - Digital Public Space,
> Zone 1.08, BBC Scotland, 40 Pacific Quay, Glasgow G51 1DA,
> Room 7066, BBC Television Centre, London W12 7RJ,
> 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E
> 
> http://www.bbc.co.uk/
> This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
> 					

Social Web Architect
http://bblfish.net/

Received on Tuesday, 22 November 2011 11:42:14 UTC