W3C home > Mailing lists > Public > public-xg-webid@w3.org > December 2011

RE: TLS-Light

From: Peter Williams <home_pw@msn.com>
Date: Thu, 1 Dec 2011 13:47:43 -0800
Message-ID: <SNT143-W5231F265803838D637E88B92B10@phx.gbl>
To: "public-xg-webid@w3.org" <public-xg-webid@w3.org>

we are getting more and more into PKI themes, rather than not-PKI - the main mission of the group. At the same time, we are learning how to make a PKI-centric IE and IIS cooperate with webid, as it changes the landscape. What follows is for THAT purpose (not to go sell what clearly doesnt work on the open internet/web: PKI, DNSsec, DANE etc). IN the IE world, where IE is one HTTP client of many that leverages the PC's cryptosystem and a million web service desktop apps are others, its web-centered vs enterprise-centered culture assumes that the user first downloads the issuer authorities cert (typically self-signed) using a brower visit to the IA's site. the IA present a .cer file, whose issuer=subject is a hint to the import wizard that it shoudl be added to the users ROOT trust store. So, if fcns were an IA, it would have a link to its root cert on its page. Users signal their acceptance of the authority of fcns by locating and installing said root onto their PC. In times gone by, that cert had a link to an HTML page which enabled the site (FCNS) to pursuade the user of its trustworthiness, show meangingless American privacy policy assurances, and other legal controls. etc The windows cert import dialogs (in times gone by) would show that message . User  feedback objected to this webiness, and the feature was removed a decade ago (or more). Custom clients can still do it though, as can folks customizing IE (not that anyone does this anymore). Having done so, one "enrolls" with said authority, using a web enrollment page. This gets one ones own cert, with SAN fields should one so choose. If FCNS is some busy body type authority, it set terms and conditions, issues various legal threats, and otherwise acts as governing type body. But, thats its choice, as it is the choice of users who enroll/or not. Most such issuers tend to authoritarianism, being human nature one folks get a taste for control.  The purpose of the root is so that IE/PC can now negotiate trust points during SSL handshakes, based on agents' local enumerations of their roots stores on server and client ends. Kn Windows IIS, the list of issuers DNs is limited to 16k, so sending 10,000 user DNs for each USER cert FCNS  has ever minted is not practical; motivating some kind of hierachy (to FACILITATE scaling). Of course, the pundits rant about evil CAs, at this point. W3C has done its fair share of fear mongering here, based on its PGP biases. Of course, you can turn off the negotiation. IIS can also send no DNs. on the server, normally one would now issue a cross-certificate to the FCNS root, or logically 10,000 cross-certs to each user that FCNS ever issues. This will populate A cert in a cert store on the IIS, and said user can now talk to IIS (using webid). This is an act of pre-registration (that fails the webid test), don the natural way. Obviously, there is a choice between 1 cross-cert and n000 cross certs, for mass "recognition"; and you pick your pain points dependin on your view of life.. But, both work (to address FUD). Though the root of FCNS is NEVER installed into 100 servers in a windows server farm, link-chain discovery (pre semweb) by the windows kernel ties the users cert from the browser to the cross cert to the local root of trust, that ultimately tieds to the TPM chip in the motherboard of the server. Typically, the cross cert has as chaining limit control, so the the FCNS user cannot introduce further parties, by minting certs. But, again, this is an OPTIONAL control (in fun and friendly cer world) - to be decided as FCNS and the validation agent so decide. Perhaps the IIS site acting asd web validation agent is free minded... its controlling. Its upto the notion of link chains and "authority to introduce" that the parties see as appropriate. Hopefully, folks see that striping out discovery based on following URI fields in cert between issuers and using webid profile and foaf:knows chains intead is QUITE natural. Its perfectly ok in cert theory for webid/foaf metadata to drive link chain discovery. ot makes PERFECT sense for a sparql server to be doing remote discovery, given a library of discovery queries. Some old blobs (called cert blobs) then happen to drive older code, once sparql querying has decided a path through the trust network. ventually, one can dump the cert blob, entirely. This will happen QUICKER once metadata and linked data movement is ADDING value (vs bitching).          Date: Thu, 1 Dec 2011 13:56:06 -0500
From: kidehen@openlinksw.com
To: public-xg-webid@w3.org
Subject: Re: TLS-Light


  


    
  
  
    On 12/1/11 1:29 PM, Henry Story wrote:
    

      
        On 1 Dec 2011, at 18:51, Kingsley Idehen wrote:
        
        
          
           On 12/1/11 12:46 PM,
            Henry Story wrote:
            

              
                On 1 Dec 2011, at 18:24, Kingsley Idehen wrote:
                
                
                  
                   On 12/1/11
                    11:53 AM, Henry Story wrote:
                    Ok so simply put the problem is the
                      following (as I understand it): Windows is passing
                      certificates around, and it assumes that once they
                      have passed the Certificate verifier the
                      Certificate is trusted. They don't have a way to
                      have untrusted Certificates. What they need is a
                      way to have have Certificates be passed in objects
                      called Claims
                    

                    No, it means the Certificates must be signed by a
                    Root CA for the Windows Keystore(s) in question. If
                    you perform a simple test with IE you'll see the
                    issue. The solution is to generate a Root CA cert,
                    register with the target keystore, then make Certs
                    with WebID watermarks signed using the Root CA cert.
                    This is how Windows works for reasons already
                    explained by Peter. 

                    

                    Windows is military grade security. It's actually
                    very very secure. WebID works under Windows if
                    implementers follow the rules. This means Cert
                    Generators have to be able to make Root Certs and
                    persist to the Windows keystore. That's what we've
                    always offered via our native Cert. Generator Wizard
                    for Windows (a one-click app. sorta like the Java
                    equivalent re. app. deployment).

                    

                    My old demo: http://youtu.be/gzqHVUb3qrw
                    . 

                    

                    Note, at the very beginning I indicate the need for
                    CA Root cert. I'll soon make a new set of demos with
                    a much more end-user friendly narrative. 

                  
                
                

                
                Are you and Peter speaking of two different issues?
                  

                
              
            
            

            Same issues in different voices. 

            
              
                

                
                 (a)- I think you are speaking of generating your
                  own client certificates locally, signed by your own
                  CA.
              
            
            No, it includes registering the Cert (a CA Cert) as a Root
            Cert. with the Window native OS keystore. This is the key to
            it all. 

            

            
              
                 (b)- Peter is speaking of a windows server
                  accepting a connection from a remote client
                  identifying itself with a Certificate that is signed
                  by a CA it does not know about, i.e. the certificate
                  you generated above in (a). 

                
              
            
            

            Because the Cert. isn't a recognized Root Cert. in the eyes
            of the system until registered in the OS keystore. 

          
        
        

        
        And if that is correct it is a problem as Peter points out.
          Because if I had a Windows Machine and I generated a
          certificate the way you outline in (a)
        then connected to your IIS server the first time ever
          without us knowing each other, THEN you would now know about
          my CA root, and so IIS would reject the connection. 

        
      
    
    

    Simpler example using IE:

    

    1. You get a WebID from some IdP (not us) that produces x.509 certs
    with WebiD watermarks (e.g., in SAN) 

    2. You go to your own WebID verification service or the one by
    Andrei or even ours.

    

    It will fail.

    

    Repeat the steps above, but use our Wizard to perform two tasks:

    

    1. make a Cert and register it as a Root CA cert in your local
    Windows key store

    2. use the same Wizard to then generate an x.509 cert. that signed
    using the CA cert from #1.

    

    Go to any of the WebID verifiers in the failed test above, and it
    will work. 

    

    The issue boils down to the fact that you can self-certify and
    self-sign, but you have to do so in line with Windows security
    architecture which is a high grade implementation and exploitation
    of PKI. 

    

    

    
      
        

        
        You cannot test this from your own machine on your own
          machine because presumably you know yourself. :)
      
    
    

    I am on a Windows machine. I've registered my CA Root cert on my
    machine, because I know and trust myself. I have my WebID bearing
    Certs signed and saved to my local keystore. Then I go out using
    WebID to access protected resources wherever they might be.

    

    
      
        

        
        If in our diagram on http://webid.info/spec#authentication-sequence
        

        
        If Bob were running Windows and used your method (a) to
          create a certificate on his windows server, and then connected
          to Alice's Server who 
        also happens to run IIS, then Alice's TLS server would
          according to Peter refuse to accept Bob's certificate. 
      
    
    

    The WebID bearing certificates have to be signed using Root CA
    certificates (what we enable) or certs in normal CA trust chain,
    bottom line. 

    

    [IE] --- connects --- [any space that supports WebID authentication]
    . The failure will happen in IE since self-signed certs don't work.
    You need to self-certify and then sign these certs for it to work
    re. IE. 

    

    Note, the issue here is that WebID implementers on Windows need to
    be aware of this requirement. The good news for WebID is that
    Windows developers already understand this. 

    
      
        And again according to Peter there is nothing he can do
          about it because IIS does all its crypto in the kernel.
        

        
        Of course Alice can just download the Java server I am
          working on and not use IIS and then she will be fine.

        
      
    
    

    See my comments above. Take a spin with IE as per the steps I
    outlined.

    

    Kingsley

    

    
      
        

        
        
           

            
              
                

                
                  Peter is saying that unless he knows ahead of
                  time about the CA that signed your certificate in (a)
                  then the IIS server will not accept the client
                  certificate in (b). He could use Apache, but he wishes
                  to use IIS for some reason.
              
            
            

            No, IIS and Apache are the same. The issue is the Windows
            kernel and its coupling to the keystore. 

          
        
        

        
        I don't think there is an issue with Apache - only IIS .
          Read his mail carefully.
        

        
          
            
              
                

                
                

                
                Henry
                

                
                PS.In any case I have found that one can create
                  client certificates for Windows as you do in  (a) by
                  making a request to a WebID key generation server with
                  the windows equivalent of keygen, without needing to
                  use all these heavy tools you are using.
              
            
            

            This isn't about "heavy duty" anything. Its about
            understanding how you deploy this system on Windows. How is
            a one-click application heavy duty? Its about the code for
            actually achieving these tasks in line with how Windows
            works. 

            

            
              
                 the user experience there is 1 click cert creation
              
            
            

            Yes, but do you have a solution that then works with IE?
            Let's not speculate here. If the system in question works,
            just test WebID from IE.

          
        
        

        
        yes it worked. I'll set up a server and try it again some
          other time.
        

        
           

            Kingsley

            
              
                

                
                

                
                

                
                

                
                   

                    Kingsley

                    
                      

                      
                      

                      
                      
                        
                          
                            
                              
                                
                                  On 1 Dec 2011, at 17:24, Peter
                                    Williams wrote:
                                  
                                  
                                      
                                         

                                          In windows think, a DNS zone
                                          can be a "certificate store".
                                          Its a place were certs are
                                          stored. Having a replicated
                                          zone of DNS RRs servered from
                                          the local DNS endpoint
                                          supporting IIS now act as a
                                          cert store is no different to
                                          what happens today when a
                                          domain within the data partion
                                          of the very same
                                          activedireectory is a
                                          certificate store (remember,
                                          in windows DNS endpoints are
                                          serviced by the
                                          activeDirectory
                                          product). Files on the web can
                                          be cert stores (there is even
                                          a .tla for one). There is no
                                          reason why a webid profile
                                          cannot be a cert store, too,
                                          being a "file on the web" in
                                          some other format. In any cert
                                          store, one can already store
                                          self-signed certs.  cert
                                          stores and file formats, or
                                          where records are stored in
                                          some name server, is not the
                                          issue.

                                           

                                          The issue is that IIS natively
                                          only uses certain cert stores
                                          for SSL client certs, and
                                          until a client cert is in one
                                          of them, the kernel will not
                                          complete the ssl handshake.

                                        
                                      
                                    
                                  

                                  
                                  Does IIS not have an API which it
                                    uses to ask if a client cert is in a
                                    keystone? I would have thought with
                                    the desire to do lookups in one of
                                    Microsofts other products, there
                                    would be something like that - so
                                    that managers can have an ldap based
                                    client keystone somewhere, and not
                                    on every machine. In that case it's
                                    just a case of intercepting that
                                    request and running the WEbID
                                    Protocol on the sent certificate.
                                  

                                  
                                  

                                  
                                  
                                      
                                         

                                          DANE is irrelevant to the
                                          argument. DANE specifies the
                                          use of self-signed certs in
                                          RRs of a DNS zone that COULD
                                          already be deemed as cert
                                          store (once replicated). It is
                                          already covered, and does not
                                          address the requirement.

                                           

                                          The requirement that windows
                                          cannot address (natively) is
                                          that a client presents a
                                          self-signed client authn cert
                                          to a server in the (native)
                                          SSL handshake, and webid
                                          expects the handshake to not
                                          only complete but deliver said
                                          handshake to code ..tied to
                                          the server endpoint
                                          ..preregistered on an TCP or
                                          other type of network port
                                          over which SSL messages are
                                          being communiated (e.g. UDP
                                          for SSLVPN). This must happen
                                          when no cert store used by
                                          Windows  kernel lists the
                                          (self-signed) cert.

                                           

                                          Because the requirement does
                                          not satisfy this requirement,
                                          under the assurance objective
                                          Windows doesnt complete the
                                          handshake, and doesn't deliver
                                          it. This is correct (military)
                                          crypto. If one thinks about a
                                          DH cert used for client auth,
                                          it should be more apparent why
                                          the rule is present, since the
                                          keying material is
                                          contributing entropy to a key
                                          agreement process (unlike RSA
                                          client certs). The cert also
                                          bears a label, which
                                          constrains when its key can or
                                          cannot contribute said
                                          entropy, so certain lattice
                                          structures are enforced within
                                          the security policy.

                                           

                                          If the spec said (a) register
                                          a (self-signed) cert over
                                          https and then (b) starting
                                          using the webid validation
                                          protocol, THEN I could easily
                                          stick said self-signed cert in
                                          a cert store TODAY in step
                                          (a). Windows would then
                                          conform, natively. But, that
                                          is not what the spec says, and
                                          its not true to what the spec
                                          is about. The spec does not
                                          REQUIRE pre-registration
                                          (which would be a
                                          cryptopolitical nightmare.).
                                          You can hear the headline now:
                                          "W3C wants to oversee network
                                          for worldwide registration for
                                          user certs." Austrailian and
                                          UIK govt folks would love it
                                          though (since they always
                                          hated free certs).

                                        
                                      
                                    
                                  

                                  
                                  

                                  
                                  

                                  
                                      
                                         

                                          If you want to run tomcat on
                                          windows sitting on a TCP/IP,
                                          of course, you can do webid
                                          today ON windows - as
                                          specified. But, thats not
                                          "native" windows. 

                                          

                                           

                                          
                                            From:
                                            henry.story@bblfish.net

                                            Date: Thu, 1 Dec 2011
                                            15:41:40 +0100

                                            CC: public-xg-webid@w3.org

                                            To: home_pw@msn.com

                                            Subject: Re: TLS-Light

                                            

                                            As I see it when DANE
                                              comes out it is going to
                                              be very easy for every
                                              server/service to get a
                                              self signed certificate
                                              into the DNS, which can
                                              then be used to sign the
                                              certificates. Clearly at
                                              that point Windows will
                                              need to change to allow
                                              certificates signed by DNS
                                              backed signatures as
                                              being acceptable. They
                                              will have to do that
                                              because DANE is clearly
                                              going to increase
                                              security. 
                                            

                                            
                                            Now of course if one
                                              does have client
                                              certificates backed by
                                              DANE signed clients, then
                                              one can wonder: what is
                                              the role of the subject
                                              alternative name? Well it
                                              still has two roles:
                                            

                                            
                                              - it can be used to
                                              fetch attributed RESTfully
                                              about the Subject
                                              - it can be used to
                                              check the validity of the
                                              certificate - is the
                                              public key still in the
                                              remote profile?
                                            

                                            
                                            Having a certificate
                                              signed by a service backed
                                              by Dane has advantages
                                              that the server need not
                                              verify the public key at
                                              the WebID profile - this
                                              is the arguments given by
                                              the BrowserId folks.  It
                                              looks like it will have
                                              the advantage of also
                                              fitting into a more
                                              traditional Windows PKI
                                              model - even if they have
                                              to change their
                                              implementations then.
                                            

                                            
                                            The disadvantage of
                                              that way of doing things
                                              is that you still have
                                              what seems like an
                                              unnecessary company or
                                              organisational level
                                              signing process - i.e.:
                                              someone controlling the
                                              DNS needs to be asked to
                                              place a public key in
                                              there for the publication
                                              of identities, when we can
                                              in fact do quite a lot
                                              without asking that
                                              person. Since you could
                                              otherwise publish your
                                              keys yourself on an https
                                              web server. Giving someone
                                              access to writing
                                              something to a part of the
                                              domain of a web server is
                                              to make that person
                                              responsible for making
                                              claims. It seems simpler
                                              to give him access to a
                                              web server and less
                                              dangerous, then to also
                                              give him access to the
                                              private key of something
                                              published in DNS which
                                              then gives that person
                                              much wider access to make
                                              claims.
                                            

                                            
                                              Perhaps there are
                                              other ways of getting
                                              Windows to act
                                              intelligently and securely
                                              with certificates that
                                              require a WebID
                                              verification? Perhaps one
                                              would need to add
                                              something that is MUST
                                              understand to the signing
                                              certificate, which would
                                              be MUST UNERSTAND WEbID.
                                              Then Windows would not
                                              that certificate signed by
                                              such CAs need to be
                                              treated differently....
                                             
                                             Henry
                                            

                                            
                                            

                                            
                                            
                                              On 1 Dec 2011, at
                                                13:59, Peter Williams
                                                wrote:
                                              
                                                  
                                                    Ive
                                                      come to the
                                                      conclusion that
                                                      the current and
                                                      likely all
                                                      future versions of
                                                      windows, natively,
                                                      cannot be a
                                                      platform for the
                                                      webid validation
                                                      protocol - as
                                                      conceived. Any
                                                      native
                                                      implementation
                                                      cannot be complete
                                                      (and stay
                                                      consistent with
                                                      how windows
                                                      natively is
                                                      supposed to be
                                                      used). Windows
                                                      will support many
                                                      of the cases, but
                                                      not all. Per the
                                                      threads title, the
                                                      topic is indeed
                                                      SSL (where I have
                                                      lots of
                                                      expertise), and
                                                      certs (where I
                                                      have probably have
                                                      the most
                                                      continuous years
                                                      experience of
                                                      anyone on the
                                                      planet). Its a
                                                      specialized area
                                                      in which
                                                      handshakes, crypto
                                                      and certs combine,
                                                      to enforce
                                                      security policy in
                                                      an trusted
                                                      computing base.
                                                      From what I can
                                                      tell, few folks
                                                      here have any
                                                      knowhow in this
                                                      topic area - which
                                                      is quite normal -
                                                      and its not
                                                      driving the
                                                      standard. Folks
                                                      here are mostly
                                                      app programmers,
                                                      working outside
                                                      the a distributed
                                                      kernel - and are
                                                      not too concerned
                                                      with distributed
                                                      operating system
                                                      design.

                                                       

                                                      Windows and IIS 7
                                                      cannot naturally
                                                      take a self-signed
                                                      client cert on an
                                                      ssl handshake and
                                                      work with it. The
                                                      cert must be
                                                      rooted, somehow,
                                                      beforehand. There
                                                      are lots of ways
                                                      to root it
                                                      (including
                                                      cross-certs), but
                                                      rooted it must be.
                                                      This is becuase
                                                      windows is a
                                                      B3-equivalent
                                                      platform (see
                                                      Orange book for
                                                      what that means),
                                                      and information is
                                                      labelled
                                                      (essentially)
                                                      within the kernel
                                                      (B1), with
                                                      processes and
                                                      threads being
                                                      similarly
                                                      compartmentalized
                                                      as a result (B3).
                                                      Doing professional
                                                      crypto and
                                                      information
                                                      security, the
                                                      kernel uses certs
                                                      and keys and
                                                      handshakes and
                                                      decipherment to
                                                      enforce the rules
                                                      of a trusted
                                                      computing based
                                                      designed to impose
                                                      and enforce label
                                                      based integrity
                                                      and access
                                                      controls. These
                                                      are the things
                                                      that harden an OS,
                                                      and protect one
                                                      user from another
                                                      in the assumed
                                                      world of attacks
                                                      on the TCB's own
                                                      code. once crypto
                                                      for communications
                                                      enters a kernel,
                                                      it hardends a
                                                      network OS (or
                                                      NOS). Today, the
                                                      state of the art
                                                      is NOS at the
                                                      scale of a active
                                                      directory
                                                      federation
                                                      ("enterprise
                                                      class" windows).
                                                      This means.. MAN
                                                      scale, but not
                                                      national or web
                                                      scale.

                                                       

                                                      now none of that
                                                      is a criticism of
                                                      windows or the
                                                      webid project. Im
                                                      doing actually
                                                      what Im supposed
                                                      to be doing -
                                                      evaluating a
                                                      security standard
                                                      core claims and
                                                      design, as a
                                                      engineer (vs an
                                                      app programmer
                                                      writing scripts).

                                                       

                                                      There are two main
                                                      impacts. First,
                                                      the typical open
                                                      source 15 year old
                                                      with the usual
                                                      rancour will start
                                                      bleating about how
                                                      awful windows
                                                      therefore is,
                                                      without
                                                      understaning the
                                                      engineering
                                                      rationale for why
                                                      a properly
                                                      engineered trusted
                                                      computing base
                                                      imposes such hard
                                                      limits on certs
                                                      and key
                                                      management. This
                                                      will probably have
                                                      the consequence
                                                      that folks will go
                                                      back and put user
                                                      mode SSL onto
                                                      windows (using
                                                      some openssl class
                                                      library) to "solve
                                                      the problem" (and
                                                      just undo the
                                                      hardening, for
                                                      that class of app,
                                                      for that account).
                                                      Second, webid as a
                                                      standard has
                                                      mandatory modes
                                                      (self-signed certs
                                                      etc) that mean
                                                      *any* complete
                                                      implementation
                                                      will always need a
                                                      waiver, from
                                                      assurance
                                                      standards. Its
                                                      going to be rather
                                                      hard to even
                                                      formulate a webid
                                                      assurance
                                                      standard, as webid
                                                      is using keying
                                                      and crypto in a
                                                      way that
                                                      undermines
                                                      conventional
                                                      theories of
                                                      assured crypto.

                                                       

                                                      The conclusion is
                                                      that webid needs
                                                      to stay doing what
                                                      its doing; and i
                                                      do NOT want to see
                                                      it cede its user
                                                      centricity or fail
                                                      to require that
                                                      unregistered,
                                                      self-signed certs
                                                      MUST be usable.
                                                      Digital certs on
                                                      the open internet
                                                      failed, and we can
                                                      ultimately blame
                                                      the very
                                                      requirements of
                                                      and the concepts
                                                      of TCB-based
                                                      assurance for
                                                      that. A Webid
                                                      profile is NOT a
                                                      cert, and we are
                                                      not doing old
                                                      https client
                                                      authn. Webid must
                                                      not be seen as
                                                      being limited to
                                                      what client certs
                                                      are limited to
                                                      doing (when done
                                                      correctly, as
                                                      Microsoft did it). 

                                                       

                                                      I found the webid
                                                      project fun. I
                                                      learned lots about
                                                      semantic
                                                      web technologies,
                                                      met someone in
                                                      Kingsely who I
                                                      think will
                                                      revolutionize the
                                                      web, and learned
                                                      lots more more
                                                      about the state of
                                                      modern windows
                                                      (which can can
                                                      help US real
                                                      estate, still
                                                      catching up with
                                                      the web of 5 years
                                                      ago). I'm not sure
                                                      there is anything
                                                      left for me to do,
                                                      here, though. What
                                                      expertise and
                                                      experience I have,
                                                      I think I've
                                                      already
                                                      shared.       
                                                  
                                                
                                            
                                            

                                            
                                                  
                                                      
                                                          
                                                          
                                                          Social
                                                          Web Architect

                                                          http://bblfish.net/
                                                          
                                                          
                                                        
                                                    
                                                
                                          
                                        
                                      
                                    
                                
                                

                                 
                                      
                                          
                                              
                                                  
                                                          Social
                                                          Web Architect

                                                          http://bblfish.net/
                                                          
                                                
                                            
                                        
                                     
                                

                              
                            
                          
                        
                      
                    
                    

                    

                    -- 

Regards,

Kingsley Idehen	      
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen





                  
                
              
              

               
                    
                        
                            
                                
                                          Social Web Architect

                                            http://bblfish.net/
                                        
                              
                          
                      
                   
              

            
            

            

            -- 

Regards,

Kingsley Idehen	      
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen





          
        
      
      

      
        
            
                
                    
                        
                                  Social Web Architect

                                    http://bblfish.net/
                                
                      
                  
              
          
      
      

    
    

    

    -- 

Regards,

Kingsley Idehen	      
Founder & CEO 
OpenLink Software     
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen




 		 	   		  
Received on Thursday, 1 December 2011 21:48:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 1 December 2011 21:48:25 GMT