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