Download The TIES final report

TIES PROJECT REPORT
the issuer DN of a certificate is used to identify the institution; this name is followed by a comma-separated list of
resources licensed to that institution:
University of Edinburgh||biosis,update
The empty field between the vertical bars is for the Athens migration information discussed in the previous
clause; the same file is used for both. Which authorisation mechanism is used, Athens or the licensing table, is
determined at run time by a switch in the code.
With the authorisation data thus separated from the login script, it was easy to verify that a certificateauthenticated user could access the test service when that service name was in the list of licensed resources but
was denied access when the test service was removed from the list of licensed resources:
Certificate Not Accepted
University of Edinburgh not authorised for UPDATE
A.8
Browser support
It was anticipated at the outset of the project that since large-scale deployments of client authentication using
X.509 certificates already exist in the US (University of California, University of Texas, etc.), current mainstream
desktop browsers must provide adequate support. This proved to be largely true in practice, with the partial
exception of the Mac platform.
Experiments were conducted on the principal desktop user platforms: Windows (98, XP), Linux 7.3, and Mac
OS-X. These showed that Netscape Navigator (Mozilla) was fully functional on all platforms, with Internet
Explorer also effective on Windows. The only surprise was that on the Mac neither Safari (Apple’s current
browser) nor IE 5.2 (also in widespread use) supported certificates. Therefore for Mac OS-X, only the Mozilla
browser was functional.
One major weakness found concerns CRL processing by browsers. This is disabled by default, thus weakening
the degree of confidence in the authenticity of the server the browser is accessing. The CP/CPS for the ac-PKI
should mandate browser use of CRLs to ensure that some safeguard exists in the event of key compromise of
trusted servers.
Platform
Browser
Result
Windows 98
IE6
Netscape 7.0
RedHat
Linux 7.3
Mozilla 0.9.9
Netscape 4.79
OK
OK. Must load both institutional CA & JISC root CA
certificates into browser for SSL handshake to work.
OK. Identical to Netscape 7.0 on Windows.
OK. As per Netscape 7.0 on Windows but refuses to
show http images embedded in https pages and when
loading CA certificates, user must tick at least one
option (e.g., “accept for web sites”) or it will silently
fail. Just “OK” will do in Netscape 7.0.
FAILED. Does not support <keygen> tag. “Key
generation in progress” pop-up appears but does not
terminate.
FAILED. Does not support <keygen> tag. Certificate
wizard appears but gives “not implemented” error.
Galeon 1.2.0
Konqueror 3.0.4
Table A.1 — Early cross-platform browser tests
We did not attempt to document in detail the usage procedures and peculiarities of the different browsers, since
this has already been done both by their publishers and by other academic users. See, for example:
— http://www.dartmouth.edu/~pkilab/pages/More_Using_Web_Res.html
— http://www.st-andrews.ac.uk/ITS/faq/security/ca.html
58