| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This reverts commit a6b2f5ce7316b4774649ee9b421da2ee7fef461f.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Removed the clone() capability from HMAC. It was never used and having
it prevents using it with hardware accelerators that might not have this
capability.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Reported by m.drochner@fz-juelich.de in
<http://savannah.gnu.org/support/?107449>.
|
|
|
|
|
| |
Reported by Dagobert Michelsen <dam@opencsw.org>
in <http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/4566>.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to RFC 4945 § 5.1.3.12 section title "ExtendedKeyUsage"[0] the
following extended key usage has been added:
... this document defines an ExtendedKeyUsage keyPurposeID that MAY be
used to limit a certificate's use:
id-kp-ipsecIKE OBJECT IDENTIFIER ::= { id-kp 17 }
where id-kp is defined in RFC 3280 [5]. If a certificate is intended
to be used with both IKE and other applications, and one of the other
applications requires use of an EKU value, then such certificates
MUST contain either the keyPurposeID id-kp-ipsecIKE or
anyExtendedKeyUsage [5], as well as the keyPurposeID values
associated with the other applications. Similarly, if a CA issues
multiple otherwise-similar certificates for multiple applications
including IKE, and it is intended that the IKE certificate NOT be
used with another application, the IKE certificate MAY contain an EKU
extension listing a keyPurposeID of id-kp-ipsecIKE to discourage its
use with the other application. Recall, however, that EKU extensions
in certificates meant for use in IKE are NOT RECOMMENDED.
Conforming IKE implementations are not required to support EKU. If a
critical EKU extension appears in a certificate and EKU is not
supported by the implementation, then RFC 3280 requires that the
certificate be rejected. Implementations that do support EKU MUST
support the following logic for certificate validation:
o If no EKU extension, continue.
o If EKU present AND contains either id-kp-ipsecIKE or
anyExtendedKeyUsage, continue.
o Otherwise, reject cert.
Signed-off-by: Nikos Mavrogiannopoulos <nmav@gnutls.org>
|
| |
|
| |
|
| |
|
|
|
|
| |
added new ones.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
EAGAIN and INTERRUPTED as non-fatal during handshake. If the check_fatal
flag is set then GNUTLS_E_WARNING_ALERT_RECEIVED could interrupt
a handshake as well.
|
|
|
|
| |
solaris where lines dissappeared from output. Reported and suggested fix by Knut Anders Hatlen.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
* tests/Makefile.am (ctests)[ENABLE_OPENPGP]: Add `openpgp-auth'.
(TESTS_ENVIRONMENT): Add `srcdir'.
* tests/openpgp-auth.c: New file.
Signed-off-by: Nikos Mavrogiannopoulos <nmav@gnutls.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This introduces the concept of a "cipher epoch". The epoch number is
the number of successful handshakes and is incremented by one each
time. This concept is native to DTLS and this patch makes the
symmetric cipher state explicit for TLS in preparation for DTLS. This
concept was implicit in plain TLS and ChangeCipherSpec messages
triggered a "pending state copy". Now, we the current epoch number is
simply incremented to the parameters negotiated by the handshake.
The main side effects of this patch is a slightly more abstract
internal API and, in some cases, simpler code. The session blob format
is also changed a bit since this patch avoids storing information that
is now redundant. If this breaks library users' expectations, this
side effect can be negated.
The cipher_specs structure has been removed. The conn_state has become
record_state_st. Only symmetric cipher information is
versioned. Things such as key exchange algorithm and the master secret
are not versioned and their handling is unchanged.
I have tested this patch as much as I could. It introduces no test
suite regressions on my x64 Debian GNU/Linux system.
Do not hesitate to point out shortcomings or suggest changes. Since
this is a big diff, I am expecting this to be an iterative process.
Signed-off-by: Jonathan Bastien-Filiatrault <joe@x2a.org>
Signed-off-by: Nikos Mavrogiannopoulos <nmav@gnutls.org>
|
|
|
|
|
|
|
|
|
| |
This warrants being made in an inline function or macro since it is
used throughout the code. This converts 4 line repetitive blocks into
1 line.
Signed-off-by: Jonathan Bastien-Filiatrault <joe@x2a.org>
Signed-off-by: Nikos Mavrogiannopoulos <nmav@gnutls.org>
|
| |
|
|
|
|
|
|
| |
1st level: Token level. Object is unique up to token.
2nd level: Object is unique up to token and module used to access it.
3rd level: Object is unique up to token and module and version of module used to access it.
|
| |
|
| |
|
|
|
|
|
| |
Signed-off-by: Jonathan Bastien-Filiatrault <joe@x2a.org>
Signed-off-by: Nikos Mavrogiannopoulos <nmav@gnutls.org>
|
|
|
|
|
| |
Signed-off-by: Jonathan Bastien-Filiatrault <joe@x2a.org>
Signed-off-by: Nikos Mavrogiannopoulos <nmav@gnutls.org>
|
|
|
|
|
|
|
|
| |
This will be needed by the DTLS code to make sure reads are stored in
segments that correspond to datagram boundaries.
Signed-off-by: Jonathan Bastien-Filiatrault <joe@x2a.org>
Signed-off-by: Nikos Mavrogiannopoulos <nmav@gnutls.org>
|
|
|
|
|
|
|
| |
This is standard practice and the DTLS code got bit by this.
Signed-off-by: Jonathan Bastien-Filiatrault <joe@x2a.org>
Signed-off-by: Nikos Mavrogiannopoulos <nmav@gnutls.org>
|
|
|
|
|
| |
Signed-off-by: Jonathan Bastien-Filiatrault <joe@x2a.org>
Signed-off-by: Nikos Mavrogiannopoulos <nmav@gnutls.org>
|