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