RE: TLS-Light

You CAN test on one machine. Using IE (and older Chrome), the users cert (ssl client) is in one cert store, not trusted by IIS for validation purposes. That cert can be self-signed, for all it matters, made on non-windows machines, and loaded into the so-called MY store - using .p12 or .cer or .pem file import. these details are largely hidden by IE UI, though. Using an import wizard, the advanced user could then *also* put the cert into a distinct store called something like "trusted persons". AS I recall from 2+ years ago, the ssl driver will (and thus IIS will appear to) regard such a cert when presented in support of CertVerify element of procedure in the SSL handshake as a (non-root-class) but valid client cert. This is classical https client authn (distinct from webid). Subtle stuff, but we are now DISTINGUISHING the semantic of https client authn using VeriSign digitalIDs  (that flunked the web-test) from webid (though about by W3C processes). The cert is self-signed. Its not a root. It requires no supproting chain. It cannot introduce other certs (in the windows validation context, not being in a "root" class store). And, it can/could support https client authn, with certain (supported) coding practices by the web app builder. This is what I proved and contributed 2 years ago. But none of this changes anything. Until its listed THERE (or some other places, with additional semantics), IE cannot connect over the loopback or any other adaptor. And that is the correct word: connect. Windows implements the connection-oriented abstraction of what used to be called the NTSC RedBook - for distributed trusted computing bases, with enforcement agents spread over nodes in the networking operating systems. Again, if you are UK educated/indoctrinated, you will hear nothing but ill of all that (since its not "in vogue", in UK security circles, for reasons folks cannot actually state, clearly). Meantime, its present in windows in a modern form...(which is all that really matters). Remember, this is not criticsim. If I was supporting an claim of original research, this is the kind of thing what Id be saying... distinguishig one tiny but incredibly material issue (that only 4 people on the planet understand or really care about; and 3 are in the exam room...)  From:
Date: Thu, 1 Dec 2011 19:29:00 +0100
Subject: Re: TLS-Light

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:


            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. 
You cannot test this from your own machine on your own machine because presumably you know yourself. :)
If in our diagram on
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. 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.



          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.




        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.











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

                                  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


                                  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"




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



                                    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
                                      - it can be used to check the
                                      validity of the certificate - is
                                      the public key still in the remote

                                    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


                                      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


                                              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


                                              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

                                                          Web Architect


                                                    Social Web






Kingsley Idehen	      
Founder & CEO 
OpenLink Software     
Company Web:
Personal Weblog:
Twitter/ handle: @kidehen
Google+ Profile:
LinkedIn Profile:


                                  Social Web Architect






Kingsley Idehen	      
Founder & CEO 
OpenLink Software     
Company Web:
Personal Weblog:
Twitter/ handle: @kidehen
Google+ Profile:
LinkedIn Profile:


Social Web Architect


Received on Thursday, 1 December 2011 18:49:46 UTC