1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
|
If you want to contribute (implement something from the current list, or
anything), contact the developer's mailing list (gnutls-dev@lists.gnupg.org),
in order to avoid having people working on the same thing.
Current list:
+ Support PKCS#8 AES and DES-MD5 (tests/enc3pkcs8.pem) encrypted keys.
* Implement Datagram-TLS (DTLS).
* Correct TLS 1.2 support.
* Cleanup pkix.asn and remove unused (by the certificate api) structures.
That way memory used will be reduced.
* Improve or rewrite libtasn1 to make it easier to maintain.
* Verify added CRLs (is it really needed?)
* Add support for generating empty CRLs
* Document the format for the supported DN attributes.
* Audit the code
- Support OpenSSL encrypted PKCS#1 RSA keys, for compatibility (new
applications should use PKCS#8 instead).
- Allow verifying of certificates on their reception.
- Add gnutls_certificate_set_openpgp_keyring()
function, similar to gnutls_certificate_set_openpgp_key().
- Add function to extract the signers of an openpgp key. Should
be similar to gnutls_x509_crt_get_dn_oid().
- Add function to verify an openpgp key against a plain key.
- Clean up name space of helper functions in library (memmem,
firstElement, bit_mask, ...) for platforms that libtool's
-export-symbols-regex doesn't work.
- Allow sending V2 Hello messages. It seems that some (old) broken
implementations require that.
- Add Kerberos ciphersuites
- Certificate chain validation improvements:
- Implement "correct" DN comparison (instead of memcmp).
- Support critical key usage KeyCertSign and cRLSign.
- Support path length constraints.
- RFC 3280 compliant certificate path validation.
- Add progress handler gnutls_{dh,rsa}_params_generate2, to allow
application to give progress feedback to user.
- Support non-blocking gnutls_{dh,rsa}_params_generate2 for when there
is not enough entropy available.
- Chain verifications.
- Check path length constraints.
- Check keyCertSign key usages.
- Reject extensions in v1 certificates.
- Support for cryptodev (and thus hardware accelerators)
- Exhaustive test suite, using NIST's PKI Test vectors,
see http://csrc.nist.gov/pki/testing/x509paths_old.html
and http://csrc.nist.gov/pki/testing/x509paths.html
- Clean up certtool. Perhaps separate the different functions into
separate tools. Probably a rewrite is necessary.
- Make it possible to extract the internal state of a session, to
be able to execve a new process that take over the current
living socket (using the fcntl close-on-exec flag) and
continue the TLS session as well.
- Implement draft-salowey-tls-ticket-05, useful for (e.g.) EAP-FAST.
- Reduce memory footprint
- Inside gnutls_global_init, the library allocates about 64 kb of
memory in almost 4000 calls to malloc. On my desktop, there are 22
processes using gnutls, meaning about 1.2 MB of memory usage from
this alone.
- Furthermore, gnutls has 24 kb of relocations in the shared
library. You can see this on a 2.6.16 kernel by reading
/proc/PID/smaps and looking for:
b71a5000-b71ab000 rw-p 00062000 03:01 3131118
/usr/lib/libgnutls.so.12.3.6
Size: 24 kB
Rss: 24 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 24 kB
This means another 24 kb used by each process that makes use of
libgnutls.
- Make gnutls-cli-debug exit with better error messages if the
handshake fails, rather than saying that the server doesn't support
TLS.
- Make gnutls_certificate_get_ours return a zero-terminated array (or
add a new API that return the size of the array).
- Debug why www-s.uiuc.edu:443 refuse to negotiate sslv3 when we propose
sslv3+tls1.
- Investigate why failed client authentication results in weird error
messages. See http://permalink.gmane.org/gmane.network.gnutls.general/875
- Print X.509 DN in the proper order.
- Debug why connections to smtp.hispeed.ch fails (Debian #429183).
Most likely the server is buggy, but it would be useful to document
the problem better.
(+) Means high priority
(*) Means medium priority
(-) Means low priority (ie. nobody is interested to develop that)
|