- From: Dominik Tomaszuk <ddooss@wp.pl>
- Date: Tue, 19 Mar 2013 16:48:56 +0100
- To: Henry Story <henry.story@bblfish.net>
- CC: Melvin Carvalho <melvincarvalho@gmail.com>, public-webid@w3.org
W dniu 19.03.2013 12:36, Henry Story pisze: > > On 19 Mar 2013, at 11:34, Dominik Tomaszuk <ddooss@wp.pl> wrote: > >> W dniu 19.03.2013 11:02, Melvin Carvalho pisze: >>> >>> >>> On 19 March 2013 10:54, Dominik Tomaszuk <ddooss@wp.pl >>> <mailto:ddooss@wp.pl>> wrote: >>> >>> W dniu 19.03.2013 10:27, Melvin Carvalho pisze: >>> >>> >>> >>> On 19 March 2013 10:20, Henry Story <henry.story@bblfish.net >>> <mailto:henry.story@bblfish.net> >>> <mailto:henry.story@bblfish.__net >>> <mailto:henry.story@bblfish.net>>> wrote: >>> >>> >>> On 19 Mar 2013, at 09:49, Mo McRoberts >>> <Mo.McRoberts@bbc.co.uk <mailto:Mo.McRoberts@bbc.co.uk> >>> <mailto:Mo.McRoberts@bbc.co.uk >>> <mailto:Mo.McRoberts@bbc.co.uk>__>> wrote: >>> >>> > curiously, the ASN.1 modules for RSA and DSA (in the >>> context of >>> PKIX) differ in terms of naming… >>> > >>> > where RSA speaks of 'modulus' and 'publicExponent', DSA is >>> exclusively 'p', 'q', and 'g' for the parameters and 'y' >>> for the key >>> itself. >>> > >>> > I can't help but wonder if consistency should perhaps >>> outweigh >>> friendlier naming (such that 'p' in an DSA key structure >>> maps to 'p' >>> in a set of RDF triples). >>> > >>> > rdfs:label and rdfs:comment within the ontology of >>> course can go >>> a long way in clarifying things… >>> >>> This seems to be what the XMLSIG standard does >>> >>> http://www.w3.org/TR/xmldsig-__core/#sec-DSAKeyValue >>> <http://www.w3.org/TR/xmldsig-core/#sec-DSAKeyValue> >>> >>> >>> Nice find! >>> >>> So we could simply go with g p q x y >>> >>> They all seem to be : ds:CryptoBinary (which is the same as the RSA >>> exponent) >>> >>> +1 >>> >>> >>> >>> So this I think would match to our use of xsd:hexBinary for all? >>> >>> I do not think so. Some values should be xsd:int >>> >>> >>> It would be nice, but i think xsd int can only store 32 bits or so, and >>> we'll need at least 100+ for each of these. >>> >>> xsd:int I think can only safely be applied to an RSA exponent >> OK, I don't focus on limits of xsd:int. So maybe unify all properties connected to DSA and RSA? There are two possibilities: >> 1. use xsd:base64, pros: XSD datatype >> 2. use ds:CryptoBinary, pros: compatibile with XMLSig. Note that this datatype is based on xsd:base64. > > I think xsd:base64 and xsd:hexBinary are interchangeable. Their domain is a binary sequence in each case. If we add this we would need to mention the equivalence as a note in the WebID over TLS spec, and we should improve our programs to accept both. > > If someone wants to put together the ontology in N3 for this and submitt it here for discussion we can then add it to the cert ontology when we get consensus. OK I can do it. BTW, it is good time to clear and rebuild cert ont. > > Henry > > PS. I have a bit of a flue so I can't do much just now. > >> >> Regards, >> Dominik 'domel' Tomaszuk >> >> >>> >>> Next one would have to specify what the types of the values >>> for each >>> of those relations are. Are they integers or hexBinaries, >>> hexBinaries for very long integers - since that is the only >>> way to >>> encode those in a hexadecidmal format that can save a bit >>> of space. >>> Ie: what is the domain of those values? >>> >>> > >>> > M. >>> > >>> > On Mon 2013-Mar-18, at 19:02, Melvin Carvalho >>> <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com> >>> <mailto:melvincarvalho@gmail.__com >>> <mailto:melvincarvalho@gmail.com>>> wrote: >>> > >>> >> >>> >> >>> >> On 18 March 2013 19:44, Henry Story >>> <henry.story@bblfish.net <mailto:henry.story@bblfish.net> >>> <mailto:henry.story@bblfish.__net >>> <mailto:henry.story@bblfish.net>>> wrote: >>> >> >>> >> On 18 Mar 2013, at 18:08, Melvin Carvalho >>> <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com> >>> <mailto:melvincarvalho@gmail.__com >>> <mailto:melvincarvalho@gmail.com>>> wrote: >>> >> >>> >>> >>> >>> >>> >>> On 17 March 2013 22:31, Henry Story >>> <henry.story@bblfish.net <mailto:henry.story@bblfish.net> >>> <mailto:henry.story@bblfish.__net >>> <mailto:henry.story@bblfish.net>>> wrote: >>> >>> >>> >>> On 17 Mar 2013, at 21:56, Melvin Carvalho >>> <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com> >>> <mailto:melvincarvalho@gmail.__com >>> <mailto:melvincarvalho@gmail.com>>> wrote: >>> >>> >>> >>>> http://www.w3.org/ns/auth/cert >>> >>>> >>> >>>> "The modulus of an RSA public and private key. Or the >>> modulus >>> of a DSA Key." >>> >>>> >>> >>>> Yet there is no class for a DSA public key. >>> >>>> >>> >>>> It would be great if this could be added as I'm currently >>> looking into an integration between WebID and a payments >>> system that >>> uses DSA. >>> >>> >>> >>> Sounds like a good idea. Would be worth opening an >>> issue for. >>> >>> >>> >>> Thanks for the advice, Henry. I've opened an issue. >>> >>> >>> >>> Could we break down what needs to be done to get this >>> actioned, >>> are there any bottle necks? >>> >> >>> >> There is probably very little to do. One needs to look >>> at how >>> DSA keys can be described, write out those relations, >>> verify them, >>> and then add them to the ontology. >>> >> >>> >> >>> >> Ah good. >>> >> >>> >> Well as you know, RSA keys are described as follows: >>> >> >>> >> Private key description: (n, d) is the (modulus, >>> private key >>> exponent) >>> >> Public key description: (n, e) is the (modulus, public key >>> exponent) >>> >> >>> >> In DSA as per: >>> >> >>> >> Private key description: (x, g, p, q) is the (private key, >>> generator, modulus, sub-group order) >>> >> Public key description: (y, g, p, q) is the (public key, >>> generator, modulus, sub-group order) >>> >> >>> >> Source: >>> https://www.dlitz.net/__software/pycrypto/api/current/__Crypto.PublicKey.DSA._DSAobj-__class.html >>> <https://www.dlitz.net/software/pycrypto/api/current/Crypto.PublicKey.DSA._DSAobj-class.html> >>> >> Source: >>> https://www.dlitz.net/__software/pycrypto/api/current/__Crypto.PublicKey.DSA-module.__html >>> <https://www.dlitz.net/software/pycrypto/api/current/Crypto.PublicKey.DSA-module.html> >>> >> >>> >> So I think the naming is doable. To start with what do you >>> think of the terms: >>> >> >>> >> g=generator >>> >> p=modulus >>> >> q=subGroupOrder >>> >> >>> >> >>> >> >>> >> >>> >>> >>> >>> >>> >>> Henry >>> >>> >>> >>> >>> >>> Social Web Architect >>> >>> http://bblfish.net/ >>> >>> >>> >>> >>> >> >>> >> Social Web Architect >>> >> http://bblfish.net/ >>> >> >>> >> >>> > >>> > >>> > >>> > >>> > -- >>> > Mo McRoberts - Analyst - BBC Archive Development, >>> > 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/ >>> >>> >>> >>> >>> -- >>> Dominik Tomaszuk >>> Research Fellow >>> University of Bialystok >>> Poland >>> >>> >> >> >> -- >> Dominik Tomaszuk >> Research Fellow >> University of Bialystok >> Poland >> > > Social Web Architect > http://bblfish.net/ > -- Dominik Tomaszuk Research Fellow University of Bialystok Poland
Received on Tuesday, 19 March 2013 15:49:27 UTC