[foaf-protocols] Interview of Nathan on his PHP parser

[Henry Story]

As many of you probably, I have no idea of the state of parsers for php. So I Nathan  a few
questions:

Henry: What is the PHP code like? Is  complex?
Nathan: a little, but if this works for everybody I'm going to tidy it all up
        it's this: 
         http://github.com/webr3/x509/blob/master/X509Parser.php with another day spent on it
Henry Story: He! You're a real ASN.1 specialist now!
Nathan: don't think there is such a thing, it's a nasty specification
Henry Story: that's what I have heard people say. But that's good. We can give it to 
             hackers/security specialists for review If most of the work is done, I am 
         sure they will know who to give it to, to test it. 
         That can be useful to the PHP community for many other reasons I am sure
         say for example for opening an https connection to a server and reading the 
         received cert that might itself have a WebID
Nathan: indeed :) was speaking to manu before and dave's done a JS ASN.1 parser as well, 
         goignto have a go with it later on and beef up if needed
Nathan: http://github.com/digitalbazaar/forge/blob/master/js/asn1.js
Henry Story: well very nice. If that helps us get php developers  on board in large 
            numbers that could be the biggest contribution yet :-)
Nathan: btw, to summarise my thoughts on the thread - I think putting a full DER in our 
        profiles is a no go, because it carries additional info that may be private; 
        putting a DER of the public key only might be viable - but trying to just get 
        better support for exponent/modulus instead and try to change nothing
Henry Story: I agree. I think it is cleaner
Nathan: as you just said, that's what I'm hoping, if we can make libAuthenticate 
        portable with no dependencies all is cool
Henry Story: We can add DER support later if ever someone starts publishing that 
        in large volumes
Nathan agrees
Henry Story: those keys are meant to be public, but I agree, the problem is that they are too opaque
          someone could put something in there, and then we're all on headlines
          with hex encoding the user can look at the browser and check so he can feel 
          comfortable
Henry Story: does this code only raad or also write?
Nathan: only reads at the minute, if all works I could make a writer as well, but 
       would probably do that for ecmascript, as PHP already has very good 
       support for making certificate (excluding SAN of course, you have to hack like 
       hell to get that to work!). So maybe a PHP cert writer would be a good thing, 
      for now though focus is on reading
Henry Story: ah ok. Weird that they have support for Making certs but not to read them  :^)
Nathan: ahh they have support to read them, just not to the level we need, as in you 
        can get a public key out as a PEM/DER formatted string, you can't get exponent/modulus!
Nathan: and they have support to make them too, but SAN is a complete hack in openssl 
        which requires a custom config and firing in the SAN through and ENV :s which 
        isnt' very nice
Henry Story: so in PHP you have to use openssl to make your cert?
Nathan: PHP natively uses openssl libs to read and write certificates and provides a nice 
      interface ( http://php.net/manual/en/ref.openssl.php ) so when you use it 
      you're really using a low level api in to openssl itself (which gens certs and uses 
     it's own openssl.conf file etc)
Henry Story: ah ok, so it forks a process
Nathan: openssl doesn't support SAN over the command line or in it's API, the only support 
      is in the config file (ie you have to write the ASN in the config file :|) so to get
      it to work with variable SAN you must pass it in through an env and reference etc
Henry Story: yup
Nathan: not the nicest :p
        regardless, it works
Henry Story: is that a problem for deployers, or can they always rely on openssl being available?
Nathan: they can rely on it being there :) but certificate generation with SAN is still a 
       problem that requires a very custom setup - if this ASN.1 parser I've done passes all
       tests then read will be sorted, but write still has nasty dependencies
Henry Story: mhhh mind you writing a cert, would require signing it too
            But yes, this would make life easier for deployers. Sould be worth doing for 
           that reason alone then.
Henry Story: Ok. Thanks. I am sure that will be very helpful to others
             as it was to me. In Java it's all in the box, so my only problem was 
             understanding the apis