Re: TLS-Light

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.

>
>   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.
>
>
> 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.

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 <mailto:henry.story@bblfish.net>
>>>> Date: Thu, 1 Dec 2011 15:41:40 +0100
>>>> CC: public-xg-webid@w3.org <mailto:public-xg-webid@w3.org>
>>>> To: home_pw@msn.com <mailto: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