- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Tue, 19 Mar 2013 11:02:57 +0100
- To: Dominik Tomaszuk <ddooss@wp.pl>
- Cc: public-webid@w3.org
- Message-ID: <CAKaEYhKD6QmiUMAcOHS1VaxwHGJvis0OL1RrC=NWxOUUTr2zHA@mail.gmail.com>
On 19 March 2013 10:54, Dominik Tomaszuk <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 <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**>> 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 > > 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<melvincarvalho@gmail.com>>> >> wrote: >> > >> >> >> >> >> >> On 18 March 2013 19:44, Henry Story <henry.story@bblfish.net >> <mailto:henry.story@bblfish.**net <henry.story@bblfish.net>>> wrote: >> >> >> >> On 18 Mar 2013, at 18:08, Melvin Carvalho >> <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.**com<melvincarvalho@gmail.com>>> >> wrote: >> >> >> >>> >> >>> >> >>> On 17 March 2013 22:31, Henry Story <henry.story@bblfish.net >> <mailto:henry.story@bblfish.**net <henry.story@bblfish.net>>> wrote: >> >>> >> >>> On 17 Mar 2013, at 21:56, Melvin Carvalho >> <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.**com<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 > >
Received on Tuesday, 19 March 2013 10:03:41 UTC