RE: rsa ontology in cert namespace

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

Received on Tuesday, 22 November 2011 09:52:36 UTC