[foaf-protocols] Why exponent/modulus

Henry Story henry.story at bblfish.net
Sat Sep 18 14:03:05 CEST 2010

I very much agree with Akbar's position.

Here is small initial table of pros and cons for different solutions

1. pub key mod/exp:

 a. mathematically clean
   -> interoperable with PEM, DER and any other encoding
   -> will be useable with PGP or X.509 certificates or no certs in fact
   -> not tied to a complex encoding ASN.1
   -> algorithm printable on T-Shirt (RSA)
 d. no hidden information the user may be shocked to discover in his cert
 e. the user can open his browser and see the public key there in the browser
    and see exactly the same information on his home page: that's clean
 f. much more extensible
 g. is a neat way to start thinking of a foaf profile as a certificate itself
 h. It's working! 

 a. we had to develop an ontology for RSA
 b. we will need to develop one for DSA I suppose
 c. encoding questions cert:int, cert:hex
 d. comparison is not just a string comparison, but two BigInt comparisons
 e. It's not working well enough for some php installations

  a. could be easy to publish (no ASN.1 parsing libraries, if servers receive)
  b. comparison is a string comparison
  c. no need to delve into more subtle ontological issues, they are hidden in
     the 'unparseable' ASN.1
  d. magic: 
     + because people will think that the cert is signed they will think it 
       will work better
     + it is more widely understood by the types of developers who we (may) 
       need to get on board (but watch out here, they may just as well have 
       more important issues such as the ssl connection)

  a. which of PEM or DER? (Do all web servers produce PEM?)
  b. what about PGP - won't they be against this, and say we have bought our
     way into the CA thing
  c. if some servers start doing string comparison, will that not forever 
     tie us to that format and force all users to publish either PEM or DER
  d. Lack of transparency: the user cannot see the link between what his browser 
     shows him and what is published on his personal profile page. 
  e. Not tested yet: do all servers give PEM access to their apps? Others DER? 


So I am with Akbar on the following: I don't mind using the wot ontology 
relations in my parser as another way of writing out the public key. That 
will make my code a little more complex, but not much really. Then we can 
see if people find publishing the PEM more easy and if that makes a difference.

On the other hand if everyone just does string comparison then we will all be 
forced to publish in PEM or DER format (whichever one wins), or not be able to 
login to those WordPress, Drupal or other sites that require it. Perhaps *if* it
really is the piece that is stopping distribution to WordPress, Drupal, etc..
that won't be such an issue because they can also be upgraded with an ASN.1 
parser when it comes out. In the meantime the foaf+ssl concept can spread.

Do PEM or DER have mime types? Then one's profile could point to a cert document
and that could return one of the many cert types, at the cost of an extra https

On the other hand, how much work is it really to get that ASN.1 parser finished 
in php? If Wordpress, et all can also understand what we have now, I have no trouble 
adding support for wot. Then for the price of increasing the complexity of the code
somewhat we get some potential political advantage. We could even support PGP. Then
we can allow every weird syntax group to express their arbitrary but religiously held
preferences, and yet interoperate. In any case I think long term that will be

Imagine: we allow people to publish their PGP key, and show them how they
can then use that to tie it to an X.509 certificate so that they use the same
private key! There are many people who are very passionate about PGP!
(Btw. right after that one should get the PGP community to add a URI field
to their key too)


On 18 Sep 2010, at 08:32, Akbar Hossain wrote:

> On Fri, Sep 17, 2010 at 11:55 PM, Mitko Iliev <imitko at openlinksw.co.uk> wrote:
>> In same way as they know exponent and modulus for RSA key ;-)
>> This is not a duty of the user, it is duty of the IdP.
> Yes true :) Need to get with the program and forget about being my own IdP ;)
> We could all agree to generate the PEM file in the one format (the
> most obvious format) as per Nathans script.
> Namely the one sent over the TLS connection.
> However, if I put that in my foaf file I have now published other
> things as well as modulus and exponent.
> For example I may have published my email address. (granted that is my
> choice to add it in the first place).
> Having my email in my SAN in my certificate that I reveal to services
> when I wish to use them and when I positively agree to reveal my email
> to them is different to publishing in public. (granted I could put
> this behind https with ACL)
> We also all have to agree to publish our PEM (instead of or as well as
> the modulus/exponent) to get any dependency reduction unless I have
> missed something.  Joe seems to have the making of an ASN.1 parser in
> PHP maybe an idea to complete that out (its the most advance  ASN.1
> implementation in PHP I have seen - nice job). Run it over the
> certificate that comes across the certificate that comes across the
> TLS connection and then run the same parser over any PEM people may
> add to their webid (if added to the ontology)
> If optionally added not sure what we have gained. Other than perhaps
> easier understanding amongst a few developers. I guess market forces
> may make people move toward the PEM encoding. Getting a few more devs
> onboard has got to be good thing.
> So... no objection to adding PEM encoding but I'm not sure it will
> simplify things unless everyone switches (ie not manadatory - as well
> as or instead of). Personally I dont mind putting my certificate up
> either (as is) but then I dont intend to put things in my certificate
> which are not public anyway.
> Thanks
>> On Sep 18, 2010, at 1:24 AM, Akbar Hossain wrote:
>>> I am unsure how people would create the PEM file to embed in their foaf file.
>> --
>> 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

More information about the foaf-protocols mailing list