- From: Peter Williams <home_pw@msn.com>
- Date: Thu, 1 Dec 2011 10:49:05 -0800
- To: <henry.story@bblfish.net>, <kidehen@openlinksw.com>
- CC: "public-xg-webid@w3.org" <public-xg-webid@w3.org>
- Message-ID: <SNT143-W558033EBCCB752F391265692B10@phx.gbl>
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: henry.story@bblfish.net
Date: Thu, 1 Dec 2011 19:29:00 +0100
CC: public-xg-webid@w3.org
To: kidehen@openlinksw.com
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: 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.
You cannot test this from your own machine on your own machine because presumably you know yourself. :)
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. 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.
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/
Received on Thursday, 1 December 2011 18:49:46 UTC