[foaf-protocols] Why exponent/modulus

Henry Story henry.story at bblfish.net
Sat Sep 18 02:27:28 CEST 2010


Creating an ontology for PEM and DER is not the big issue. It's a few lines of rdf
in a file. The issue is whether it simplifies things to tie people to publish
ASN.1 strings. My guess is that it won't get rid of the need to parse those files
anyway. So we might as well work on tweaking the tools to parse them correctly.

As far as adding DSA ontology or any other encryption I am for doing that too. 
We don't seem to have needed it until now, but we should probably provide for
it in a final spec, or as it turns out to be useful.

Henry


On 17 Sep 2010, at 21:39, Mitko Iliev wrote:

> Hi Melvin,
> 
> I have asked this question so long ago and didn't get answer :-(
> IMO the base64 or even PEM encoded public key would be nice to have in ontology in aspect of comparing various types of keys taking into account key, it could be DSA or something else which is not covered by current spec.  which solely talking about RSA. This is short term solution, long term to have different keys described by an ontology. 
> 
> Best Regards,
> Mitko
> 
> On Sep 17, 2010, at 11:26 PM, Melvin Carvalho wrote:
> 
>> 
>> 
>> On 17 September 2010 16:48, Nathan <nathan at webr3.org> wrote:
>> Hi All,
>> 
>> Similar to my previous question, why do we extract the modulus and
>> exponent of a public key and represent those in RDF, if we were instead
>> to store a PEM/DER encoded version of the public key, or even
>> certificate, in our profiles instead, what would break?
>> 
>> With this specific question, the main background thinking is that
>> implementations of WebID protocol would be much easier, with far less
>> dependencies, if we did simply throw a PEM/DER certificate in to our
>> profiles, all those Wordpress/Mediawiki/Drupal type plugins, and indeed
>> support in any language which had basic support for HTTP+TLS would
>> suddenly become a very easy hit.
>> 
>> By the way we already have in WOT:
>> 
>> Property: wot:pubkeyAddress
>> Address - The location of an ascii version of a public key. Status:    testing
>> Domain:    wot:PubKey
>> Range:    http://xmlns.com/foaf/0.1/Document
>> A link from a Public Key to an ascii version of said key. It is usually acceptable to include other content in this file as well: so long as the ascii signature has a newline before and after it, tools 
>> 
>> Property: wot:identity
>> Identity - A property linking a public key to the user of the key. Status:    testing
>> Domain:    wot:PubKey
>> Range:    wot:User
>> A term identifying the wot:User of a wot:PubKey - the inverse of wot:hasKey. Useful for providing identifying information about the owner of a Key.
>> 
>> Property: wot:length
>> Length - A numeric string representing the length, in bytes, of a public key. Status:    stable
>> Domain:    wot:PubKey
>> Range:    http://www.w3.org/2001/XMLSchema#integer
>> Keys can have a length attached to them. Typical sizes range from 1024-4096 bytes. Longer keys are typically considered more difficult to break. 
>> 
>> 
>> Could this also use literal versions of public keys, i wonder?
>>  
>> 
>> Best,
>> 
>> Nathan
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols at lists.foaf-project.org
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>> 
>> _______________________________________________
>> foaf-protocols mailing list
>> foaf-protocols at lists.foaf-project.org
>> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
> 
> 
> --
> Mitko Iliev
> Developer Virtuoso Team
> OpenLink Software
> http://www.openlinksw.com/virtuoso
> Cross Platform Web Services Middleware
> 
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

Social Web Architect
http://bblfish.net/



More information about the foaf-protocols mailing list