W3C home > Mailing lists > Public > public-xg-webid@w3.org > November 2011

Re: rsa ontology in cert namespace

From: Mo McRoberts <mo.mcroberts@bbc.co.uk>
Date: Tue, 22 Nov 2011 13:27:19 +0000
Cc: Henry Story <henry.story@bblfish.net>, WebID XG <public-xg-webid@w3.org>
Message-Id: <E9A090CC-B043-4883-9F5E-D10380866979@bbc.co.uk>
To: Tim Berners-Lee <timbl@w3.org>

On 22 Nov 2011, at 13:17, Tim Berners-Lee wrote:

> On 2011-11 -21, at 12:58, Henry Story wrote:
>> If we move the rsa ontology to cert namespace we may need to add rsa prefixes, to distinguish an rsa parameter from a dsa or other parameter -- but perhaps we don't have to - I suppose this would be a good reason to have a DSA ontology, just to see if there are clashes. In any case here is what this would give the following 
> Is there a sense in which the exponent of an RSA key and that of a DSA key are the same property and 
> should just be cert:exponent?

You could take that view with the modulus — they are both integer values constituting the same thing, albeit as part of different sets of calculations (and I'm assuming there'll be cert:RSAPublicKey and cert:DSAPublicKey classes to differentiate them).

Given that, you could specify, covering the needs of both RSA & DSA:

cert:exponent (cert:RSAPublicKey)
cert:modulus (cert:RSAPublicKey, cert:DSAPublicKey)
cert:divisor (cert:DSAPublicKey)
cert:generator (cert:DSAPublicKey)
cert:keyValue (cert:DSAPublicKey) (I couldn't think of a better name)

…which seems to be a pretty reasonable approach.


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

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 13:27:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:48 UTC