Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(171)

Issues Search
    My Issues | Starred     Open | Closed | All

Unified Diff: third_party/tlslite/test/index.html

Issue 210323002: Update tlslite to 0.4.6. (Closed) Base URL: svn://svn.chromium.org/chrome/trunk/src
Patch Set: Executable bit and --similarity=80 Created 6 years, 8 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
« no previous file with comments | « third_party/tlslite/test/httpsserver.py ('k') | third_party/tlslite/test/serverCryptoIDChain.xml » ('j') | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
Index: third_party/tlslite/test/index.html
diff --git a/third_party/tlslite/test/index.html b/third_party/tlslite/test/index.html
deleted file mode 100644
index e7f02cc90daaa65cacc0b44be4cfb65a17d074ed..0000000000000000000000000000000000000000
--- a/third_party/tlslite/test/index.html
+++ /dev/null
@@ -1,649 +0,0 @@
-<html>
-<head>
-<title>Trevor Perrin</title>
-</head>
-<body>
-<H1>Trevor Perrin</H1>
-<b>Email:</b> trevp at trevp.net<br>
-<b>PGP Key:</b> <a href="pgp/key.asc">8035 47B9 D1F9 C148 619A 7948 D8C0 0F11 2F2F F9E3</a>
-<p>I'm a programmer, here are some projects I'm involved in.
-
-<p>My current interest is cryptographic key management and alternatives to PKI.
-<p>
-
-<a name="cryptoID">
-<H2><a href="cryptoID/">CryptoIDs</a></H2>
-<b>Paper 1:</b> Public Key Distribution through "cryptoIDs" (<a href="cryptoID/cryptoID.pdf">.pdf</a>, <a href="cryptoID/cryptoID.html">.html</a>) <i>(presented at <a href="http://www.nspw.org/2003/">NSPW 2003</a>)</i><br>
-<b>Paper 2:</b> The CryptoID Key Management Protocols (<a href="cryptoID/cryptoID2.pdf">.pdf</a>) <i>(the best introduction)</i><br>
-<b>Schema:</b> XML Schema for &lt;certChain&gt; (<a href="cryptoID/cryptoID.xsd">.xsd</a>)<br>
-<b>Code:</b> CryptoIDlib Python and Java library and command-line tool v0.1.8 (<a href="cryptoID/cryptoIDlib-0.1.8.zip">.zip</a>, <a href="cryptoID/readme.txt">readme.txt</a>)
-<p>PKI isn't working for person-to-person communications. Few people use
-secure email, voice, instant-messaging, or anything else.
-<p>CryptoIDs are an alternative. The idea is for people to exchange small,
-user-friendly fingerprints (aka "cryptoIDs") like 'cyhf4.9ajd8.kbdx4.rk98c'.
-These could be passed around and stored in address books as if they were phone
-numbers or postal addresses.
-<p>The cryptoID for each user would correspond to that user's <i>root key</i>.
-The user would keep his root key in a safe place - his employer or
-some commercial service might hold it for him. The rootholder would operate
-an online service which would issue short-lived <i>subkey certificates</i> or <i>validation signatures</i> to the user.
-<p>CryptoIDs, then, are about combining <i>fingerprint-based public-key distribution</i> with
-<i>certificate-based private-key management</i>. The first paper above presents the
-cryptoID fingerprint and certificate formats, which are designed specifically for
-this. CryptoIDlib lets you test-drive these formats.
-<p>The second paper presents private-key management protocols for use with online servers.
-Support for these is being added to cryptoIDlib.
-
-<a name="tls_lite">
-<H2><a href="tls_lite/">TLS Lite</a></H2>
-<b>Code:</b> tls_lite python library v0.1.8 (<a href="tls_lite/tls_lite-0.1.8.zip">.zip</a>, <a href="tls_lite/readme.txt">readme.txt</a>)<br>
-<p>
-TLS Lite is a free python library that implements SSL 3.0 and <a href="http://www.ietf.org/rfc/rfc2246.txt">TLS 1.0</a>.
-TLS Lite supports non-traditional authentication methods such as <a href="http://trevp.net/tls_srp/index.html">SRP</a>,
-<a href="http://www.ietf.org/internet-drafts/draft-ietf-tls-sharedkeys-02.txt">shared keys</a>,
-and <a href="http://trevp.net/cryptoID/index.html">cryptoIDs</a>, in addition to X.509 certificates. TLS Lite is pure
-<a href="http://www.python.org">Python</a>, however it can access <a href="http://www.openssl.org/">OpenSSL</a> or
-<a href="http://www.cs.auckland.ac.nz/~pgut001/cryptlib/">cryptlib</a> for faster crypto operations.
-
-<a name="tlssrp">
-<H2><a href="tls_srp/">TLS/SRP</a></H2>
-<b>Internet-Draft:</b> Using SRP for TLS Authentication (<a href="tls_srp/draft-ietf-tls-srp-06.txt">.txt</a>, <a href="tls_srp/draft-ietf-tls-srp-06.html">.html</a>)
-<p><a href="http://srp.stanford.edu">SRP</a> is the best way to do password authentication
-across a network. <a href="http://www.ietf.org/html.charters/tls-charter.html">TLS</a> (aka SSL v3.1)
-is the best way to do channel security. What could go better together?
-<p>This draft modifies the TLS handshake to use SRP. This combination of
-password-based mutual authentication and the TLS record layer is
-ideal for protecting protocols like POP3 and HTTP.
-
-<a name="dss">
-<H2>DSS</H2>
-<b>Requirements:</b> DSS Use Case Requirements Analysis (<a href="dss/oasis-dss-1.0-requirements-wd-12.pdf">.pdf</a>, <a href="dss/oasis-dss-1.0-requirements-wd-12.doc">.doc</a>)<br>
-<b>Specification Working Draft:</b> Digital Signature Service Core Protocol and Elements (<a href="dss/oasis-dss-1.0-core-spec-wd-10.pdf">.pdf</a>, <a href="dss/oasis-dss-1.0-core-spec-wd-10.doc">.doc</a>)<br>
-<b>Schema Working Draft:</b> oasis-dss-1.0-core-schema-wd-10 (<a href="dss/oasis-dss-1.0-core-schema-wd-10.xsd">.xsd</a>)<br>
-<b>Somewhat Related Paper:</b> Delegated Cryptography, Online Trusted Third Parties, and PKI
-(<a href="delegatedCrypto/delegatedCrypto.pdf">.pdf</a>, <a href="delegatedCrypto/delegatedCrypto.html">.html</a>)<br>
-<i>(presented at the <a href="http://www.cs.dartmouth.edu/~pki02/">1st Annual PKI Research Workshop</a>)</i>
-<p>The <a href="http://www.oasis-open.org/">OASIS</a> <a href="http://www.oasis-open.org/committees/dss/">Digital Signature Service Technical Committee</a>
-is designing protocols for signing, verifying, and
-time-stamping of XML documents and other data. The idea is to perform these
-operations on servers, thus freeing clients from having to manage private
-keys, calculate certificate paths, and so on.
-<p>Also listed is a paper arguing for the server-based approach vs. client-side PKI.
-
-<a name="cryptoURL">
-<H2>CryptoURLs</H2>
-<b>Draft of potential Internet-Draft:</b> The "crypto" URL scheme (<a href="cryptoURL/draft-ietf-cryptoURL-01.txt">.txt</a>, <a href="cryptoURL/draft-ietf-cryptoURL-01.html">.html</a>)<br>
-<p>
-CryptoURLs add "crypto metadata" like content hashes and key fingerprints to normal URLs.
-The resulting URLs are <a href="http://zooko.com/distnames.html">self-authenticating</a>,
-like <a href="http://citeseer.nj.nec.com/mazieres99separating.html">SFS file names</a> or
-<a href="http://research.microsoft.com/users/tuomaura/CGA/">Cryptographically Generated Addresses</a>.
-These could be useful in:
-<dir>
-<LI>web pages:
- <dir>
- <LI>a page could link to software binaries and include their hash
- <LI>a portal could provide secure introductions to a community of sites
- </dir>
-<LI>XML documents (e.g. extending an <a href="http://www.w3.org/TR/xmldsig-core/">XML-DSIG</a> over external references)
-<LI>protocols (e.g. HTTP Redirects or LDAP Referrals)
-<LI>software configuration (you could configure a client with the address and fingerprint of a server in one step)
-</dir>
-<a href="http://www.waterken.com/dev/YURL/">YURLs</a> are another approach to self-authenticating URLs.
-
-<a name="cryptlibConverter">
-<H2><a href="cryptlibConverter/">CryptlibConverter</a></H2>
-<b>Code:</b> Version 5 for cryptlib 3.1 (<a href="cryptlibConverter/cryptlibConverter5_cl31.zip">.zip</a>, <a href="cryptlibConverter/readme.txt">readme.txt</a>)
-<p>This is a python script that generates java, python, and C# wrappers for
-<a href="http://www.cs.auckland.ac.nz/~pgut001/cryptlib/">cryptlib</a>. A set of wrappers for
-cryptlib 3.1 is included in the .zip file. The python and C# wrappers are also included in the latest cryptlib distribution.
-<br>
-<a name="cryptoID">
-<H2><a href="cryptoID/">CryptoIDs</a></H2>
-<b>Paper 1:</b> Public Key Distribution through "cryptoIDs" (<a href="cryptoID/cryptoID.pdf">.pdf</a>, <a href="cryptoID/cryptoID.html">.html</a>) <i>(presented at <a href="http://www.nspw.org/2003/">NSPW 2003</a>)</i><br>
-<b>Paper 2:</b> The CryptoID Key Management Protocols (<a href="cryptoID/cryptoID2.pdf">.pdf</a>) <i>(the best introduction)</i><br>
-<b>Schema:</b> XML Schema for &lt;certChain&gt; (<a href="cryptoID/cryptoID.xsd">.xsd</a>)<br>
-<b>Code:</b> CryptoIDlib Python and Java library and command-line tool v0.1.8 (<a href="cryptoID/cryptoIDlib-0.1.8.zip">.zip</a>, <a href="cryptoID/readme.txt">readme.txt</a>)
-<p>PKI isn't working for person-to-person communications. Few people use
-secure email, voice, instant-messaging, or anything else.
-<p>CryptoIDs are an alternative. The idea is for people to exchange small,
-user-friendly fingerprints (aka "cryptoIDs") like 'cyhf4.9ajd8.kbdx4.rk98c'.
-These could be passed around and stored in address books as if they were phone
-numbers or postal addresses.
-<p>The cryptoID for each user would correspond to that user's <i>root key</i>.
-The user would keep his root key in a safe place - his employer or
-some commercial service might hold it for him. The rootholder would operate
-an online service which would issue short-lived <i>subkey certificates</i> or <i>validation signatures</i> to the user.
-<p>CryptoIDs, then, are about combining <i>fingerprint-based public-key distribution</i> with
-<i>certificate-based private-key management</i>. The first paper above presents the
-cryptoID fingerprint and certificate formats, which are designed specifically for
-this. CryptoIDlib lets you test-drive these formats.
-<p>The second paper presents private-key management protocols for use with online servers.
-Support for these is being added to cryptoIDlib.
-
-<a name="tls_lite">
-<H2><a href="tls_lite/">TLS Lite</a></H2>
-<b>Code:</b> tls_lite python library v0.1.8 (<a href="tls_lite/tls_lite-0.1.8.zip">.zip</a>, <a href="tls_lite/readme.txt">readme.txt</a>)<br>
-<p>
-TLS Lite is a free python library that implements SSL 3.0 and <a href="http://www.ietf.org/rfc/rfc2246.txt">TLS 1.0</a>.
-TLS Lite supports non-traditional authentication methods such as <a href="http://trevp.net/tls_srp/index.html">SRP</a>,
-<a href="http://www.ietf.org/internet-drafts/draft-ietf-tls-sharedkeys-02.txt">shared keys</a>,
-and <a href="http://trevp.net/cryptoID/index.html">cryptoIDs</a>, in addition to X.509 certificates. TLS Lite is pure
-<a href="http://www.python.org">Python</a>, however it can access <a href="http://www.openssl.org/">OpenSSL</a> or
-<a href="http://www.cs.auckland.ac.nz/~pgut001/cryptlib/">cryptlib</a> for faster crypto operations.
-
-<a name="tlssrp">
-<H2><a href="tls_srp/">TLS/SRP</a></H2>
-<b>Internet-Draft:</b> Using SRP for TLS Authentication (<a href="tls_srp/draft-ietf-tls-srp-06.txt">.txt</a>, <a href="tls_srp/draft-ietf-tls-srp-06.html">.html</a>)
-<p><a href="http://srp.stanford.edu">SRP</a> is the best way to do password authentication
-across a network. <a href="http://www.ietf.org/html.charters/tls-charter.html">TLS</a> (aka SSL v3.1)
-is the best way to do channel security. What could go better together?
-<p>This draft modifies the TLS handshake to use SRP. This combination of
-password-based mutual authentication and the TLS record layer is
-ideal for protecting protocols like POP3 and HTTP.
-
-<a name="dss">
-<H2>DSS</H2>
-<b>Requirements:</b> DSS Use Case Requirements Analysis (<a href="dss/oasis-dss-1.0-requirements-wd-12.pdf">.pdf</a>, <a href="dss/oasis-dss-1.0-requirements-wd-12.doc">.doc</a>)<br>
-<b>Specification Working Draft:</b> Digital Signature Service Core Protocol and Elements (<a href="dss/oasis-dss-1.0-core-spec-wd-10.pdf">.pdf</a>, <a href="dss/oasis-dss-1.0-core-spec-wd-10.doc">.doc</a>)<br>
-<b>Schema Working Draft:</b> oasis-dss-1.0-core-schema-wd-10 (<a href="dss/oasis-dss-1.0-core-schema-wd-10.xsd">.xsd</a>)<br>
-<b>Somewhat Related Paper:</b> Delegated Cryptography, Online Trusted Third Parties, and PKI
-(<a href="delegatedCrypto/delegatedCrypto.pdf">.pdf</a>, <a href="delegatedCrypto/delegatedCrypto.html">.html</a>)<br>
-<i>(presented at the <a href="http://www.cs.dartmouth.edu/~pki02/">1st Annual PKI Research Workshop</a>)</i>
-<p>The <a href="http://www.oasis-open.org/">OASIS</a> <a href="http://www.oasis-open.org/committees/dss/">Digital Signature Service Technical Committee</a>
-is designing protocols for signing, verifying, and
-time-stamping of XML documents and other data. The idea is to perform these
-operations on servers, thus freeing clients from having to manage private
-keys, calculate certificate paths, and so on.
-<p>Also listed is a paper arguing for the server-based approach vs. client-side PKI.
-
-<a name="cryptoURL">
-<H2>CryptoURLs</H2>
-<b>Draft of potential Internet-Draft:</b> The "crypto" URL scheme (<a href="cryptoURL/draft-ietf-cryptoURL-01.txt">.txt</a>, <a href="cryptoURL/draft-ietf-cryptoURL-01.html">.html</a>)<br>
-<p>
-CryptoURLs add "crypto metadata" like content hashes and key fingerprints to normal URLs.
-The resulting URLs are <a href="http://zooko.com/distnames.html">self-authenticating</a>,
-like <a href="http://citeseer.nj.nec.com/mazieres99separating.html">SFS file names</a> or
-<a href="http://research.microsoft.com/users/tuomaura/CGA/">Cryptographically Generated Addresses</a>.
-These could be useful in:
-<dir>
-<LI>web pages:
- <dir>
- <LI>a page could link to software binaries and include their hash
- <LI>a portal could provide secure introductions to a community of sites
- </dir>
-<LI>XML documents (e.g. extending an <a href="http://www.w3.org/TR/xmldsig-core/">XML-DSIG</a> over external references)
-<LI>protocols (e.g. HTTP Redirects or LDAP Referrals)
-<LI>software configuration (you could configure a client with the address and fingerprint of a server in one step)
-</dir>
-<a href="http://www.waterken.com/dev/YURL/">YURLs</a> are another approach to self-authenticating URLs.
-
-<a name="cryptlibConverter">
-<H2><a href="cryptlibConverter/">CryptlibConverter</a></H2>
-<b>Code:</b> Version 5 for cryptlib 3.1 (<a href="cryptlibConverter/cryptlibConverter5_cl31.zip">.zip</a>, <a href="cryptlibConverter/readme.txt">readme.txt</a>)
-<p>This is a python script that generates java, python, and C# wrappers for
-<a href="http://www.cs.auckland.ac.nz/~pgut001/cryptlib/">cryptlib</a>. A set of wrappers for
-cryptlib 3.1 is included in the .zip file. The python and C# wrappers are also included in the latest cryptlib distribution.
-<br>
-<a name="cryptoID">
-<H2><a href="cryptoID/">CryptoIDs</a></H2>
-<b>Paper 1:</b> Public Key Distribution through "cryptoIDs" (<a href="cryptoID/cryptoID.pdf">.pdf</a>, <a href="cryptoID/cryptoID.html">.html</a>) <i>(presented at <a href="http://www.nspw.org/2003/">NSPW 2003</a>)</i><br>
-<b>Paper 2:</b> The CryptoID Key Management Protocols (<a href="cryptoID/cryptoID2.pdf">.pdf</a>) <i>(the best introduction)</i><br>
-<b>Schema:</b> XML Schema for &lt;certChain&gt; (<a href="cryptoID/cryptoID.xsd">.xsd</a>)<br>
-<b>Code:</b> CryptoIDlib Python and Java library and command-line tool v0.1.8 (<a href="cryptoID/cryptoIDlib-0.1.8.zip">.zip</a>, <a href="cryptoID/readme.txt">readme.txt</a>)
-<p>PKI isn't working for person-to-person communications. Few people use
-secure email, voice, instant-messaging, or anything else.
-<p>CryptoIDs are an alternative. The idea is for people to exchange small,
-user-friendly fingerprints (aka "cryptoIDs") like 'cyhf4.9ajd8.kbdx4.rk98c'.
-These could be passed around and stored in address books as if they were phone
-numbers or postal addresses.
-<p>The cryptoID for each user would correspond to that user's <i>root key</i>.
-The user would keep his root key in a safe place - his employer or
-some commercial service might hold it for him. The rootholder would operate
-an online service which would issue short-lived <i>subkey certificates</i> or <i>validation signatures</i> to the user.
-<p>CryptoIDs, then, are about combining <i>fingerprint-based public-key distribution</i> with
-<i>certificate-based private-key management</i>. The first paper above presents the
-cryptoID fingerprint and certificate formats, which are designed specifically for
-this. CryptoIDlib lets you test-drive these formats.
-<p>The second paper presents private-key management protocols for use with online servers.
-Support for these is being added to cryptoIDlib.
-
-<a name="tls_lite">
-<H2><a href="tls_lite/">TLS Lite</a></H2>
-<b>Code:</b> tls_lite python library v0.1.8 (<a href="tls_lite/tls_lite-0.1.8.zip">.zip</a>, <a href="tls_lite/readme.txt">readme.txt</a>)<br>
-<p>
-TLS Lite is a free python library that implements SSL 3.0 and <a href="http://www.ietf.org/rfc/rfc2246.txt">TLS 1.0</a>.
-TLS Lite supports non-traditional authentication methods such as <a href="http://trevp.net/tls_srp/index.html">SRP</a>,
-<a href="http://www.ietf.org/internet-drafts/draft-ietf-tls-sharedkeys-02.txt">shared keys</a>,
-and <a href="http://trevp.net/cryptoID/index.html">cryptoIDs</a>, in addition to X.509 certificates. TLS Lite is pure
-<a href="http://www.python.org">Python</a>, however it can access <a href="http://www.openssl.org/">OpenSSL</a> or
-<a href="http://www.cs.auckland.ac.nz/~pgut001/cryptlib/">cryptlib</a> for faster crypto operations.
-
-<a name="tlssrp">
-<H2><a href="tls_srp/">TLS/SRP</a></H2>
-<b>Internet-Draft:</b> Using SRP for TLS Authentication (<a href="tls_srp/draft-ietf-tls-srp-06.txt">.txt</a>, <a href="tls_srp/draft-ietf-tls-srp-06.html">.html</a>)
-<p><a href="http://srp.stanford.edu">SRP</a> is the best way to do password authentication
-across a network. <a href="http://www.ietf.org/html.charters/tls-charter.html">TLS</a> (aka SSL v3.1)
-is the best way to do channel security. What could go better together?
-<p>This draft modifies the TLS handshake to use SRP. This combination of
-password-based mutual authentication and the TLS record layer is
-ideal for protecting protocols like POP3 and HTTP.
-
-<a name="dss">
-<H2>DSS</H2>
-<b>Requirements:</b> DSS Use Case Requirements Analysis (<a href="dss/oasis-dss-1.0-requirements-wd-12.pdf">.pdf</a>, <a href="dss/oasis-dss-1.0-requirements-wd-12.doc">.doc</a>)<br>
-<b>Specification Working Draft:</b> Digital Signature Service Core Protocol and Elements (<a href="dss/oasis-dss-1.0-core-spec-wd-10.pdf">.pdf</a>, <a href="dss/oasis-dss-1.0-core-spec-wd-10.doc">.doc</a>)<br>
-<b>Schema Working Draft:</b> oasis-dss-1.0-core-schema-wd-10 (<a href="dss/oasis-dss-1.0-core-schema-wd-10.xsd">.xsd</a>)<br>
-<b>Somewhat Related Paper:</b> Delegated Cryptography, Online Trusted Third Parties, and PKI
-(<a href="delegatedCrypto/delegatedCrypto.pdf">.pdf</a>, <a href="delegatedCrypto/delegatedCrypto.html">.html</a>)<br>
-<i>(presented at the <a href="http://www.cs.dartmouth.edu/~pki02/">1st Annual PKI Research Workshop</a>)</i>
-<p>The <a href="http://www.oasis-open.org/">OASIS</a> <a href="http://www.oasis-open.org/committees/dss/">Digital Signature Service Technical Committee</a>
-is designing protocols for signing, verifying, and
-time-stamping of XML documents and other data. The idea is to perform these
-operations on servers, thus freeing clients from having to manage private
-keys, calculate certificate paths, and so on.
-<p>Also listed is a paper arguing for the server-based approach vs. client-side PKI.
-
-<a name="cryptoURL">
-<H2>CryptoURLs</H2>
-<b>Draft of potential Internet-Draft:</b> The "crypto" URL scheme (<a href="cryptoURL/draft-ietf-cryptoURL-01.txt">.txt</a>, <a href="cryptoURL/draft-ietf-cryptoURL-01.html">.html</a>)<br>
-<p>
-CryptoURLs add "crypto metadata" like content hashes and key fingerprints to normal URLs.
-The resulting URLs are <a href="http://zooko.com/distnames.html">self-authenticating</a>,
-like <a href="http://citeseer.nj.nec.com/mazieres99separating.html">SFS file names</a> or
-<a href="http://research.microsoft.com/users/tuomaura/CGA/">Cryptographically Generated Addresses</a>.
-These could be useful in:
-<dir>
-<LI>web pages:
- <dir>
- <LI>a page could link to software binaries and include their hash
- <LI>a portal could provide secure introductions to a community of sites
- </dir>
-<LI>XML documents (e.g. extending an <a href="http://www.w3.org/TR/xmldsig-core/">XML-DSIG</a> over external references)
-<LI>protocols (e.g. HTTP Redirects or LDAP Referrals)
-<LI>software configuration (you could configure a client with the address and fingerprint of a server in one step)
-</dir>
-<a href="http://www.waterken.com/dev/YURL/">YURLs</a> are another approach to self-authenticating URLs.
-
-<a name="cryptlibConverter">
-<H2><a href="cryptlibConverter/">CryptlibConverter</a></H2>
-<b>Code:</b> Version 5 for cryptlib 3.1 (<a href="cryptlibConverter/cryptlibConverter5_cl31.zip">.zip</a>, <a href="cryptlibConverter/readme.txt">readme.txt</a>)
-<p>This is a python script that generates java, python, and C# wrappers for
-<a href="http://www.cs.auckland.ac.nz/~pgut001/cryptlib/">cryptlib</a>. A set of wrappers for
-cryptlib 3.1 is included in the .zip file. The python and C# wrappers are also included in the latest cryptlib distribution.
-<br>
-<a name="cryptoID">
-<H2><a href="cryptoID/">CryptoIDs</a></H2>
-<b>Paper 1:</b> Public Key Distribution through "cryptoIDs" (<a href="cryptoID/cryptoID.pdf">.pdf</a>, <a href="cryptoID/cryptoID.html">.html</a>) <i>(presented at <a href="http://www.nspw.org/2003/">NSPW 2003</a>)</i><br>
-<b>Paper 2:</b> The CryptoID Key Management Protocols (<a href="cryptoID/cryptoID2.pdf">.pdf</a>) <i>(the best introduction)</i><br>
-<b>Schema:</b> XML Schema for &lt;certChain&gt; (<a href="cryptoID/cryptoID.xsd">.xsd</a>)<br>
-<b>Code:</b> CryptoIDlib Python and Java library and command-line tool v0.1.8 (<a href="cryptoID/cryptoIDlib-0.1.8.zip">.zip</a>, <a href="cryptoID/readme.txt">readme.txt</a>)
-<p>PKI isn't working for person-to-person communications. Few people use
-secure email, voice, instant-messaging, or anything else.
-<p>CryptoIDs are an alternative. The idea is for people to exchange small,
-user-friendly fingerprints (aka "cryptoIDs") like 'cyhf4.9ajd8.kbdx4.rk98c'.
-These could be passed around and stored in address books as if they were phone
-numbers or postal addresses.
-<p>The cryptoID for each user would correspond to that user's <i>root key</i>.
-The user would keep his root key in a safe place - his employer or
-some commercial service might hold it for him. The rootholder would operate
-an online service which would issue short-lived <i>subkey certificates</i> or <i>validation signatures</i> to the user.
-<p>CryptoIDs, then, are about combining <i>fingerprint-based public-key distribution</i> with
-<i>certificate-based private-key management</i>. The first paper above presents the
-cryptoID fingerprint and certificate formats, which are designed specifically for
-this. CryptoIDlib lets you test-drive these formats.
-<p>The second paper presents private-key management protocols for use with online servers.
-Support for these is being added to cryptoIDlib.
-
-<a name="tls_lite">
-<H2><a href="tls_lite/">TLS Lite</a></H2>
-<b>Code:</b> tls_lite python library v0.1.8 (<a href="tls_lite/tls_lite-0.1.8.zip">.zip</a>, <a href="tls_lite/readme.txt">readme.txt</a>)<br>
-<p>
-TLS Lite is a free python library that implements SSL 3.0 and <a href="http://www.ietf.org/rfc/rfc2246.txt">TLS 1.0</a>.
-TLS Lite supports non-traditional authentication methods such as <a href="http://trevp.net/tls_srp/index.html">SRP</a>,
-<a href="http://www.ietf.org/internet-drafts/draft-ietf-tls-sharedkeys-02.txt">shared keys</a>,
-and <a href="http://trevp.net/cryptoID/index.html">cryptoIDs</a>, in addition to X.509 certificates. TLS Lite is pure
-<a href="http://www.python.org">Python</a>, however it can access <a href="http://www.openssl.org/">OpenSSL</a> or
-<a href="http://www.cs.auckland.ac.nz/~pgut001/cryptlib/">cryptlib</a> for faster crypto operations.
-
-<a name="tlssrp">
-<H2><a href="tls_srp/">TLS/SRP</a></H2>
-<b>Internet-Draft:</b> Using SRP for TLS Authentication (<a href="tls_srp/draft-ietf-tls-srp-06.txt">.txt</a>, <a href="tls_srp/draft-ietf-tls-srp-06.html">.html</a>)
-<p><a href="http://srp.stanford.edu">SRP</a> is the best way to do password authentication
-across a network. <a href="http://www.ietf.org/html.charters/tls-charter.html">TLS</a> (aka SSL v3.1)
-is the best way to do channel security. What could go better together?
-<p>This draft modifies the TLS handshake to use SRP. This combination of
-password-based mutual authentication and the TLS record layer is
-ideal for protecting protocols like POP3 and HTTP.
-
-<a name="dss">
-<H2>DSS</H2>
-<b>Requirements:</b> DSS Use Case Requirements Analysis (<a href="dss/oasis-dss-1.0-requirements-wd-12.pdf">.pdf</a>, <a href="dss/oasis-dss-1.0-requirements-wd-12.doc">.doc</a>)<br>
-<b>Specification Working Draft:</b> Digital Signature Service Core Protocol and Elements (<a href="dss/oasis-dss-1.0-core-spec-wd-10.pdf">.pdf</a>, <a href="dss/oasis-dss-1.0-core-spec-wd-10.doc">.doc</a>)<br>
-<b>Schema Working Draft:</b> oasis-dss-1.0-core-schema-wd-10 (<a href="dss/oasis-dss-1.0-core-schema-wd-10.xsd">.xsd</a>)<br>
-<b>Somewhat Related Paper:</b> Delegated Cryptography, Online Trusted Third Parties, and PKI
-(<a href="delegatedCrypto/delegatedCrypto.pdf">.pdf</a>, <a href="delegatedCrypto/delegatedCrypto.html">.html</a>)<br>
-<i>(presented at the <a href="http://www.cs.dartmouth.edu/~pki02/">1st Annual PKI Research Workshop</a>)</i>
-<p>The <a href="http://www.oasis-open.org/">OASIS</a> <a href="http://www.oasis-open.org/committees/dss/">Digital Signature Service Technical Committee</a>
-is designing protocols for signing, verifying, and
-time-stamping of XML documents and other data. The idea is to perform these
-operations on servers, thus freeing clients from having to manage private
-keys, calculate certificate paths, and so on.
-<p>Also listed is a paper arguing for the server-based approach vs. client-side PKI.
-
-<a name="cryptoURL">
-<H2>CryptoURLs</H2>
-<b>Draft of potential Internet-Draft:</b> The "crypto" URL scheme (<a href="cryptoURL/draft-ietf-cryptoURL-01.txt">.txt</a>, <a href="cryptoURL/draft-ietf-cryptoURL-01.html">.html</a>)<br>
-<p>
-CryptoURLs add "crypto metadata" like content hashes and key fingerprints to normal URLs.
-The resulting URLs are <a href="http://zooko.com/distnames.html">self-authenticating</a>,
-like <a href="http://citeseer.nj.nec.com/mazieres99separating.html">SFS file names</a> or
-<a href="http://research.microsoft.com/users/tuomaura/CGA/">Cryptographically Generated Addresses</a>.
-These could be useful in:
-<dir>
-<LI>web pages:
- <dir>
- <LI>a page could link to software binaries and include their hash
- <LI>a portal could provide secure introductions to a community of sites
- </dir>
-<LI>XML documents (e.g. extending an <a href="http://www.w3.org/TR/xmldsig-core/">XML-DSIG</a> over external references)
-<LI>protocols (e.g. HTTP Redirects or LDAP Referrals)
-<LI>software configuration (you could configure a client with the address and fingerprint of a server in one step)
-</dir>
-<a href="http://www.waterken.com/dev/YURL/">YURLs</a> are another approach to self-authenticating URLs.
-
-<a name="cryptlibConverter">
-<H2><a href="cryptlibConverter/">CryptlibConverter</a></H2>
-<b>Code:</b> Version 5 for cryptlib 3.1 (<a href="cryptlibConverter/cryptlibConverter5_cl31.zip">.zip</a>, <a href="cryptlibConverter/readme.txt">readme.txt</a>)
-<p>This is a python script that generates java, python, and C# wrappers for
-<a href="http://www.cs.auckland.ac.nz/~pgut001/cryptlib/">cryptlib</a>. A set of wrappers for
-cryptlib 3.1 is included in the .zip file. The python and C# wrappers are also included in the latest cryptlib distribution.
-<br>
-<a name="cryptoID">
-<H2><a href="cryptoID/">CryptoIDs</a></H2>
-<b>Paper 1:</b> Public Key Distribution through "cryptoIDs" (<a href="cryptoID/cryptoID.pdf">.pdf</a>, <a href="cryptoID/cryptoID.html">.html</a>) <i>(presented at <a href="http://www.nspw.org/2003/">NSPW 2003</a>)</i><br>
-<b>Paper 2:</b> The CryptoID Key Management Protocols (<a href="cryptoID/cryptoID2.pdf">.pdf</a>) <i>(the best introduction)</i><br>
-<b>Schema:</b> XML Schema for &lt;certChain&gt; (<a href="cryptoID/cryptoID.xsd">.xsd</a>)<br>
-<b>Code:</b> CryptoIDlib Python and Java library and command-line tool v0.1.8 (<a href="cryptoID/cryptoIDlib-0.1.8.zip">.zip</a>, <a href="cryptoID/readme.txt">readme.txt</a>)
-<p>PKI isn't working for person-to-person communications. Few people use
-secure email, voice, instant-messaging, or anything else.
-<p>CryptoIDs are an alternative. The idea is for people to exchange small,
-user-friendly fingerprints (aka "cryptoIDs") like 'cyhf4.9ajd8.kbdx4.rk98c'.
-These could be passed around and stored in address books as if they were phone
-numbers or postal addresses.
-<p>The cryptoID for each user would correspond to that user's <i>root key</i>.
-The user would keep his root key in a safe place - his employer or
-some commercial service might hold it for him. The rootholder would operate
-an online service which would issue short-lived <i>subkey certificates</i> or <i>validation signatures</i> to the user.
-<p>CryptoIDs, then, are about combining <i>fingerprint-based public-key distribution</i> with
-<i>certificate-based private-key management</i>. The first paper above presents the
-cryptoID fingerprint and certificate formats, which are designed specifically for
-this. CryptoIDlib lets you test-drive these formats.
-<p>The second paper presents private-key management protocols for use with online servers.
-Support for these is being added to cryptoIDlib.
-
-<a name="tls_lite">
-<H2><a href="tls_lite/">TLS Lite</a></H2>
-<b>Code:</b> tls_lite python library v0.1.8 (<a href="tls_lite/tls_lite-0.1.8.zip">.zip</a>, <a href="tls_lite/readme.txt">readme.txt</a>)<br>
-<p>
-TLS Lite is a free python library that implements SSL 3.0 and <a href="http://www.ietf.org/rfc/rfc2246.txt">TLS 1.0</a>.
-TLS Lite supports non-traditional authentication methods such as <a href="http://trevp.net/tls_srp/index.html">SRP</a>,
-<a href="http://www.ietf.org/internet-drafts/draft-ietf-tls-sharedkeys-02.txt">shared keys</a>,
-and <a href="http://trevp.net/cryptoID/index.html">cryptoIDs</a>, in addition to X.509 certificates. TLS Lite is pure
-<a href="http://www.python.org">Python</a>, however it can access <a href="http://www.openssl.org/">OpenSSL</a> or
-<a href="http://www.cs.auckland.ac.nz/~pgut001/cryptlib/">cryptlib</a> for faster crypto operations.
-
-<a name="tlssrp">
-<H2><a href="tls_srp/">TLS/SRP</a></H2>
-<b>Internet-Draft:</b> Using SRP for TLS Authentication (<a href="tls_srp/draft-ietf-tls-srp-06.txt">.txt</a>, <a href="tls_srp/draft-ietf-tls-srp-06.html">.html</a>)
-<p><a href="http://srp.stanford.edu">SRP</a> is the best way to do password authentication
-across a network. <a href="http://www.ietf.org/html.charters/tls-charter.html">TLS</a> (aka SSL v3.1)
-is the best way to do channel security. What could go better together?
-<p>This draft modifies the TLS handshake to use SRP. This combination of
-password-based mutual authentication and the TLS record layer is
-ideal for protecting protocols like POP3 and HTTP.
-
-<a name="dss">
-<H2>DSS</H2>
-<b>Requirements:</b> DSS Use Case Requirements Analysis (<a href="dss/oasis-dss-1.0-requirements-wd-12.pdf">.pdf</a>, <a href="dss/oasis-dss-1.0-requirements-wd-12.doc">.doc</a>)<br>
-<b>Specification Working Draft:</b> Digital Signature Service Core Protocol and Elements (<a href="dss/oasis-dss-1.0-core-spec-wd-10.pdf">.pdf</a>, <a href="dss/oasis-dss-1.0-core-spec-wd-10.doc">.doc</a>)<br>
-<b>Schema Working Draft:</b> oasis-dss-1.0-core-schema-wd-10 (<a href="dss/oasis-dss-1.0-core-schema-wd-10.xsd">.xsd</a>)<br>
-<b>Somewhat Related Paper:</b> Delegated Cryptography, Online Trusted Third Parties, and PKI
-(<a href="delegatedCrypto/delegatedCrypto.pdf">.pdf</a>, <a href="delegatedCrypto/delegatedCrypto.html">.html</a>)<br>
-<i>(presented at the <a href="http://www.cs.dartmouth.edu/~pki02/">1st Annual PKI Research Workshop</a>)</i>
-<p>The <a href="http://www.oasis-open.org/">OASIS</a> <a href="http://www.oasis-open.org/committees/dss/">Digital Signature Service Technical Committee</a>
-is designing protocols for signing, verifying, and
-time-stamping of XML documents and other data. The idea is to perform these
-operations on servers, thus freeing clients from having to manage private
-keys, calculate certificate paths, and so on.
-<p>Also listed is a paper arguing for the server-based approach vs. client-side PKI.
-
-<a name="cryptoURL">
-<H2>CryptoURLs</H2>
-<b>Draft of potential Internet-Draft:</b> The "crypto" URL scheme (<a href="cryptoURL/draft-ietf-cryptoURL-01.txt">.txt</a>, <a href="cryptoURL/draft-ietf-cryptoURL-01.html">.html</a>)<br>
-<p>
-CryptoURLs add "crypto metadata" like content hashes and key fingerprints to normal URLs.
-The resulting URLs are <a href="http://zooko.com/distnames.html">self-authenticating</a>,
-like <a href="http://citeseer.nj.nec.com/mazieres99separating.html">SFS file names</a> or
-<a href="http://research.microsoft.com/users/tuomaura/CGA/">Cryptographically Generated Addresses</a>.
-These could be useful in:
-<dir>
-<LI>web pages:
- <dir>
- <LI>a page could link to software binaries and include their hash
- <LI>a portal could provide secure introductions to a community of sites
- </dir>
-<LI>XML documents (e.g. extending an <a href="http://www.w3.org/TR/xmldsig-core/">XML-DSIG</a> over external references)
-<LI>protocols (e.g. HTTP Redirects or LDAP Referrals)
-<LI>software configuration (you could configure a client with the address and fingerprint of a server in one step)
-</dir>
-<a href="http://www.waterken.com/dev/YURL/">YURLs</a> are another approach to self-authenticating URLs.
-
-<a name="cryptlibConverter">
-<H2><a href="cryptlibConverter/">CryptlibConverter</a></H2>
-<b>Code:</b> Version 5 for cryptlib 3.1 (<a href="cryptlibConverter/cryptlibConverter5_cl31.zip">.zip</a>, <a href="cryptlibConverter/readme.txt">readme.txt</a>)
-<p>This is a python script that generates java, python, and C# wrappers for
-<a href="http://www.cs.auckland.ac.nz/~pgut001/cryptlib/">cryptlib</a>. A set of wrappers for
-cryptlib 3.1 is included in the .zip file. The python and C# wrappers are also included in the latest cryptlib distribution.
-<br>
-<a name="cryptoID">
-<H2><a href="cryptoID/">CryptoIDs</a></H2>
-<b>Paper 1:</b> Public Key Distribution through "cryptoIDs" (<a href="cryptoID/cryptoID.pdf">.pdf</a>, <a href="cryptoID/cryptoID.html">.html</a>) <i>(presented at <a href="http://www.nspw.org/2003/">NSPW 2003</a>)</i><br>
-<b>Paper 2:</b> The CryptoID Key Management Protocols (<a href="cryptoID/cryptoID2.pdf">.pdf</a>) <i>(the best introduction)</i><br>
-<b>Schema:</b> XML Schema for &lt;certChain&gt; (<a href="cryptoID/cryptoID.xsd">.xsd</a>)<br>
-<b>Code:</b> CryptoIDlib Python and Java library and command-line tool v0.1.8 (<a href="cryptoID/cryptoIDlib-0.1.8.zip">.zip</a>, <a href="cryptoID/readme.txt">readme.txt</a>)
-<p>PKI isn't working for person-to-person communications. Few people use
-secure email, voice, instant-messaging, or anything else.
-<p>CryptoIDs are an alternative. The idea is for people to exchange small,
-user-friendly fingerprints (aka "cryptoIDs") like 'cyhf4.9ajd8.kbdx4.rk98c'.
-These could be passed around and stored in address books as if they were phone
-numbers or postal addresses.
-<p>The cryptoID for each user would correspond to that user's <i>root key</i>.
-The user would keep his root key in a safe place - his employer or
-some commercial service might hold it for him. The rootholder would operate
-an online service which would issue short-lived <i>subkey certificates</i> or <i>validation signatures</i> to the user.
-<p>CryptoIDs, then, are about combining <i>fingerprint-based public-key distribution</i> with
-<i>certificate-based private-key management</i>. The first paper above presents the
-cryptoID fingerprint and certificate formats, which are designed specifically for
-this. CryptoIDlib lets you test-drive these formats.
-<p>The second paper presents private-key management protocols for use with online servers.
-Support for these is being added to cryptoIDlib.
-
-<a name="tls_lite">
-<H2><a href="tls_lite/">TLS Lite</a></H2>
-<b>Code:</b> tls_lite python library v0.1.8 (<a href="tls_lite/tls_lite-0.1.8.zip">.zip</a>, <a href="tls_lite/readme.txt">readme.txt</a>)<br>
-<p>
-TLS Lite is a free python library that implements SSL 3.0 and <a href="http://www.ietf.org/rfc/rfc2246.txt">TLS 1.0</a>.
-TLS Lite supports non-traditional authentication methods such as <a href="http://trevp.net/tls_srp/index.html">SRP</a>,
-<a href="http://www.ietf.org/internet-drafts/draft-ietf-tls-sharedkeys-02.txt">shared keys</a>,
-and <a href="http://trevp.net/cryptoID/index.html">cryptoIDs</a>, in addition to X.509 certificates. TLS Lite is pure
-<a href="http://www.python.org">Python</a>, however it can access <a href="http://www.openssl.org/">OpenSSL</a> or
-<a href="http://www.cs.auckland.ac.nz/~pgut001/cryptlib/">cryptlib</a> for faster crypto operations.
-
-<a name="tlssrp">
-<H2><a href="tls_srp/">TLS/SRP</a></H2>
-<b>Internet-Draft:</b> Using SRP for TLS Authentication (<a href="tls_srp/draft-ietf-tls-srp-06.txt">.txt</a>, <a href="tls_srp/draft-ietf-tls-srp-06.html">.html</a>)
-<p><a href="http://srp.stanford.edu">SRP</a> is the best way to do password authentication
-across a network. <a href="http://www.ietf.org/html.charters/tls-charter.html">TLS</a> (aka SSL v3.1)
-is the best way to do channel security. What could go better together?
-<p>This draft modifies the TLS handshake to use SRP. This combination of
-password-based mutual authentication and the TLS record layer is
-ideal for protecting protocols like POP3 and HTTP.
-
-<a name="dss">
-<H2>DSS</H2>
-<b>Requirements:</b> DSS Use Case Requirements Analysis (<a href="dss/oasis-dss-1.0-requirements-wd-12.pdf">.pdf</a>, <a href="dss/oasis-dss-1.0-requirements-wd-12.doc">.doc</a>)<br>
-<b>Specification Working Draft:</b> Digital Signature Service Core Protocol and Elements (<a href="dss/oasis-dss-1.0-core-spec-wd-10.pdf">.pdf</a>, <a href="dss/oasis-dss-1.0-core-spec-wd-10.doc">.doc</a>)<br>
-<b>Schema Working Draft:</b> oasis-dss-1.0-core-schema-wd-10 (<a href="dss/oasis-dss-1.0-core-schema-wd-10.xsd">.xsd</a>)<br>
-<b>Somewhat Related Paper:</b> Delegated Cryptography, Online Trusted Third Parties, and PKI
-(<a href="delegatedCrypto/delegatedCrypto.pdf">.pdf</a>, <a href="delegatedCrypto/delegatedCrypto.html">.html</a>)<br>
-<i>(presented at the <a href="http://www.cs.dartmouth.edu/~pki02/">1st Annual PKI Research Workshop</a>)</i>
-<p>The <a href="http://www.oasis-open.org/">OASIS</a> <a href="http://www.oasis-open.org/committees/dss/">Digital Signature Service Technical Committee</a>
-is designing protocols for signing, verifying, and
-time-stamping of XML documents and other data. The idea is to perform these
-operations on servers, thus freeing clients from having to manage private
-keys, calculate certificate paths, and so on.
-<p>Also listed is a paper arguing for the server-based approach vs. client-side PKI.
-
-<a name="cryptoURL">
-<H2>CryptoURLs</H2>
-<b>Draft of potential Internet-Draft:</b> The "crypto" URL scheme (<a href="cryptoURL/draft-ietf-cryptoURL-01.txt">.txt</a>, <a href="cryptoURL/draft-ietf-cryptoURL-01.html">.html</a>)<br>
-<p>
-CryptoURLs add "crypto metadata" like content hashes and key fingerprints to normal URLs.
-The resulting URLs are <a href="http://zooko.com/distnames.html">self-authenticating</a>,
-like <a href="http://citeseer.nj.nec.com/mazieres99separating.html">SFS file names</a> or
-<a href="http://research.microsoft.com/users/tuomaura/CGA/">Cryptographically Generated Addresses</a>.
-These could be useful in:
-<dir>
-<LI>web pages:
- <dir>
- <LI>a page could link to software binaries and include their hash
- <LI>a portal could provide secure introductions to a community of sites
- </dir>
-<LI>XML documents (e.g. extending an <a href="http://www.w3.org/TR/xmldsig-core/">XML-DSIG</a> over external references)
-<LI>protocols (e.g. HTTP Redirects or LDAP Referrals)
-<LI>software configuration (you could configure a client with the address and fingerprint of a server in one step)
-</dir>
-<a href="http://www.waterken.com/dev/YURL/">YURLs</a> are another approach to self-authenticating URLs.
-
-<a name="cryptlibConverter">
-<H2><a href="cryptlibConverter/">CryptlibConverter</a></H2>
-<b>Code:</b> Version 5 for cryptlib 3.1 (<a href="cryptlibConverter/cryptlibConverter5_cl31.zip">.zip</a>, <a href="cryptlibConverter/readme.txt">readme.txt</a>)
-<p>This is a python script that generates java, python, and C# wrappers for
-<a href="http://www.cs.auckland.ac.nz/~pgut001/cryptlib/">cryptlib</a>. A set of wrappers for
-cryptlib 3.1 is included in the .zip file. The python and C# wrappers are also included in the latest cryptlib distribution.
-<br>
-<a name="cryptoID">
-<H2><a href="cryptoID/">CryptoIDs</a></H2>
-<b>Paper 1:</b> Public Key Distribution through "cryptoIDs" (<a href="cryptoID/cryptoID.pdf">.pdf</a>, <a href="cryptoID/cryptoID.html">.html</a>) <i>(presented at <a href="http://www.nspw.org/2003/">NSPW 2003</a>)</i><br>
-<b>Paper 2:</b> The CryptoID Key Management Protocols (<a href="cryptoID/cryptoID2.pdf">.pdf</a>) <i>(the best introduction)</i><br>
-<b>Schema:</b> XML Schema for &lt;certChain&gt; (<a href="cryptoID/cryptoID.xsd">.xsd</a>)<br>
-<b>Code:</b> CryptoIDlib Python and Java library and command-line tool v0.1.8 (<a href="cryptoID/cryptoIDlib-0.1.8.zip">.zip</a>, <a href="cryptoID/readme.txt">readme.txt</a>)
-<p>PKI isn't working for person-to-person communications. Few people use
-secure email, voice, instant-messaging, or anything else.
-<p>CryptoIDs are an alternative. The idea is for people to exchange small,
-user-friendly fingerprints (aka "cryptoIDs") like 'cyhf4.9ajd8.kbdx4.rk98c'.
-These could be passed around and stored in address books as if they were phone
-numbers or postal addresses.
-<p>The cryptoID for each user would correspond to that user's <i>root key</i>.
-The user would keep his root key in a safe place - his employer or
-some commercial service might hold it for him. The rootholder would operate
-an online service which would issue short-lived <i>subkey certificates</i> or <i>validation signatures</i> to the user.
-<p>CryptoIDs, then, are about combining <i>fingerprint-based public-key distribution</i> with
-<i>certificate-based private-key management</i>. The first paper above presents the
-cryptoID fingerprint and certificate formats, which are designed specifically for
-this. CryptoIDlib lets you test-drive these formats.
-<p>The second paper presents private-key management protocols for use with online servers.
-Support for these is being added to cryptoIDlib.
-
-<a name="tls_lite">
-<H2><a href="tls_lite/">TLS Lite</a></H2>
-<b>Code:</b> tls_lite python library v0.1.8 (<a href="tls_lite/tls_lite-0.1.8.zip">.zip</a>, <a href="tls_lite/readme.txt">readme.txt</a>)<br>
-<p>
-TLS Lite is a free python library that implements SSL 3.0 and <a href="http://www.ietf.org/rfc/rfc2246.txt">TLS 1.0</a>.
-TLS Lite supports non-traditional authentication methods such as <a href="http://trevp.net/tls_srp/index.html">SRP</a>,
-<a href="http://www.ietf.org/internet-drafts/draft-ietf-tls-sharedkeys-02.txt">shared keys</a>,
-and <a href="http://trevp.net/cryptoID/index.html">cryptoIDs</a>, in addition to X.509 certificates. TLS Lite is pure
-<a href="http://www.python.org">Python</a>, however it can access <a href="http://www.openssl.org/">OpenSSL</a> or
-<a href="http://www.cs.auckland.ac.nz/~pgut001/cryptlib/">cryptlib</a> for faster crypto operations.
-
-<a name="tlssrp">
-<H2><a href="tls_srp/">TLS/SRP</a></H2>
-<b>Internet-Draft:</b> Using SRP for TLS Authentication (<a href="tls_srp/draft-ietf-tls-srp-06.txt">.txt</a>, <a href="tls_srp/draft-ietf-tls-srp-06.html">.html</a>)
-<p><a href="http://srp.stanford.edu">SRP</a> is the best way to do password authentication
-across a network. <a href="http://www.ietf.org/html.charters/tls-charter.html">TLS</a> (aka SSL v3.1)
-is the best way to do channel security. What could go better together?
-<p>This draft modifies the TLS handshake to use SRP. This combination of
-password-based mutual authentication and the TLS record layer is
-ideal for protecting protocols like POP3 and HTTP.
-
-<a name="dss">
-<H2>DSS</H2>
-<b>Requirements:</b> DSS Use Case Requirements Analysis (<a href="dss/oasis-dss-1.0-requirements-wd-12.pdf">.pdf</a>, <a href="dss/oasis-dss-1.0-requirements-wd-12.doc">.doc</a>)<br>
-<b>Specification Working Draft:</b> Digital Signature Service Core Protocol and Elements (<a href="dss/oasis-dss-1.0-core-spec-wd-10.pdf">.pdf</a>, <a href="dss/oasis-dss-1.0-core-spec-wd-10.doc">.doc</a>)<br>
-<b>Schema Working Draft:</b> oasis-dss-1.0-core-schema-wd-10 (<a href="dss/oasis-dss-1.0-core-schema-wd-10.xsd">.xsd</a>)<br>
-<b>Somewhat Related Paper:</b> Delegated Cryptography, Online Trusted Third Parties, and PKI
-(<a href="delegatedCrypto/delegatedCrypto.pdf">.pdf</a>, <a href="delegatedCrypto/delegatedCrypto.html">.html</a>)<br>
-<i>(presented at the <a href="http://www.cs.dartmouth.edu/~pki02/">1st Annual PKI Research Workshop</a>)</i>
-<p>The <a href="http://www.oasis-open.org/">OASIS</a> <a href="http://www.oasis-open.org/committees/dss/">Digital Signature Service Technical Committee</a>
-is designing protocols for signing, verifying, and
-time-stamping of XML documents and other data. The idea is to perform these
-operations on servers, thus freeing clients from having to manage private
-keys, calculate certificate paths, and so on.
-<p>Also listed is a paper arguing for the server-based approach vs. client-side PKI.
-
-<a name="cryptoURL">
-<H2>CryptoURLs</H2>
-<b>Draft of potential Internet-Draft:</b> The "crypto" URL scheme (<a href="cryptoURL/draft-ietf-cryptoURL-01.txt">.txt</a>, <a href="cryptoURL/draft-ietf-cryptoURL-01.html">.html</a>)<br>
-<p>
-CryptoURLs add "crypto metadata" like content hashes and key fingerprints to normal URLs.
-The resulting URLs are <a href="http://zooko.com/distnames.html">self-authenticating</a>,
-like <a href="http://citeseer.nj.nec.com/mazieres99separating.html">SFS file names</a> or
-<a href="http://research.microsoft.com/users/tuomaura/CGA/">Cryptographically Generated Addresses</a>.
-These could be useful in:
-<dir>
-<LI>web pages:
- <dir>
- <LI>a page could link to software binaries and include their hash
- <LI>a portal could provide secure introductions to a community of sites
- </dir>
-<LI>XML documents (e.g. extending an <a href="http://www.w3.org/TR/xmldsig-core/">XML-DSIG</a> over external references)
-<LI>protocols (e.g. HTTP Redirects or LDAP Referrals)
-<LI>software configuration (you could configure a client with the address and fingerprint of a server in one step)
-</dir>
-<a href="http://www.waterken.com/dev/YURL/">YURLs</a> are another approach to self-authenticating URLs.
-
-<a name="cryptlibConverter">
-<H2><a href="cryptlibConverter/">CryptlibConverter</a></H2>
-<b>Code:</b> Version 5 for cryptlib 3.1 (<a href="cryptlibConverter/cryptlibConverter5_cl31.zip">.zip</a>, <a href="cryptlibConverter/readme.txt">readme.txt</a>)
-<p>This is a python script that generates java, python, and C# wrappers for
-<a href="http://www.cs.auckland.ac.nz/~pgut001/cryptlib/">cryptlib</a>. A set of wrappers for
-cryptlib 3.1 is included in the .zip file. The python and C# wrappers are also included in the latest cryptlib distribution.
-<br>
-<a name="cryptoID">
-<H2><a href="cryptoID/">CryptoIDs</a></H2>
-<b>Paper 1:</b> Public Key Distribution through "cryptoIDs" (<a href="cryptoID/cryptoID.pdf">.pdf</a>, <a href="cryptoID/cryptoID.html">.html</a>) <i>(presented at <a href="http://www.nspw.org/2003/">NSPW 2003</a>)</i><br>
-<b>Paper 2:</b> The CryptoID Key Management Protocols (<a href="cryptoID/cryptoID2.pdf">.pdf</a>) <i>(the best introduction)</i><br>
-<b>Schema:</b> XML Schema for &lt;certChain&gt; (<a href="cryptoID/cryptoID.xsd">.xsd</a>)<br>
-<b>Code:</b> CryptoIDlib Python and Java library and command-line tool v0.1.8 (<a href="cryptoID/cryptoIDlib-0.1.8.zip">.zip</a>, <a href="cryptoID/readme.txt">readme.txt</a>)
-<p>PKI isn't working for person-to-person communications. Few people use
-secure email, voice, instant-messaging, or anything else.
-<p>CryptoIDs are an alternative. The idea is for people to exchange small,
-user-friendly fingerprints (aka "cryptoIDs") like 'cyhf4.9ajd8.kbdx4.rk98c'.
-These could be passed around and stored in address books as if they were phone
-numbers or postal addresses.
-<p>The cryptoID for each user would correspond to that user's <i>root key</i>.
-The user would keep his root key in a safe place - his employer or
-some commercial service might hold it for him. The rootholder would operate
-an online service which would issue short-lived <i>subkey certificates</i> or <i>validation signatures</i> to the user.
-<p>CryptoIDs, then, are about combining <i>fingerprint-based public-key distribution</i> with
-<i>certificate-based private-key management</i>. The first paper above presents the
-cryptoID fingerprint and certificate formats, which are designed specifically for
-this. CryptoIDlib lets you test-drive these formats.
-<p>The second paper presents private-key management protocols for use with online servers.
-Support for these is being added to cryptoIDlib.
-
-<br>
-<br>
-</body>
-</html>
« no previous file with comments | « third_party/tlslite/test/httpsserver.py ('k') | third_party/tlslite/test/serverCryptoIDChain.xml » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698