Certificate authentication
==========================

The most known authentication method of TLS are certificates. The PKIX PKIX public key infrastructure is daily used by anyone using a browser today. GnuTLS supports both X.509 certificates PKIX and OpenPGP certificates using a common API.

The key exchange algorithms supported by certificate authentication are shown in tab:key-exchange.

Key exchange   Description

RSA
The RSA algorithm is used to encrypt a key and send it to the peer.
The certificate must allow the key to be used for encryption.

DHE_RSA
The RSA algorithm is used to sign ephemeral Diffie-Hellman parameters
which are sent to the peer. The key in the certificate must allow the
key to be used for signing. Note that key exchange algorithms which
use ephemeral Diffie-Hellman parameters, offer perfect forward
secrecy. That means that even if the private key used for signing is
compromised, it cannot be used to reveal past session data.

ECDHE_RSA
The RSA algorithm is used to sign ephemeral elliptic curve Diffie-Hellman
parameters which are sent to the peer. The key in the certificate must allow
the key to be used for signing. It also offers perfect forward
secrecy. That means that even if the private key used for signing is
compromised, it cannot be used to reveal past session data.

DHE_DSS
The DSA algorithm is used to sign ephemeral Diffie-Hellman parameters
which are sent to the peer. The certificate must contain DSA
parameters to use this key exchange algorithm. DSA is the algorithm
of the Digital Signature Standard (DSS).

ECDHE_ECDSA
The Elliptic curve DSA algorithm is used to sign ephemeral elliptic
curve Diffie-Hellman parameters which are sent to the peer. The
certificate must contain ECDSA parameters (i.e., EC and marked for signing)
to use this key exchange algorithm.

Table: Supported key exchange algorithms.

X.509 certificates
------------------

The X.509 protocols rely on a hierarchical trust model. In this trust model Certification Authorities (CAs) are used to certify entities.  Usually more than one certification authorities exist, and certification authorities may certify other authorities to issue certificates as well, following a hierarchical model.

Figure: An example of the X.509 hierarchical trust model.

One needs to trust one or more CAs for his secure communications. In that case only the certificates issued by the trusted authorities are acceptable.  The framework is illustrated on fig:x509.

X.509 certificate structure
...........................

An X.509 certificate usually contains information about the certificate holder, the signer, a unique serial number, expiration dates and some other fields PKIX as shown in tab:x509.

Field   Description

version
The field that indicates the version of the certificate.

serialNumber
This field holds a unique serial number per certificate.

signature
The issuing authority's signature.

issuer
Holds the issuer's distinguished name.

validity
The activation and expiration dates.

subject
The subject's distinguished name of the certificate.

extensions
The extensions are fields only present in version 3 certificates.

Table: X.509 certificate fields.

The certificate's subject or issuer name is not just a single string.  It is a Distinguished name and in the ASN.1 notation is a sequence of several object identifiers with their corresponding values. Some of available OIDs to be used in an X.509 distinguished name are defined in gnutls/x509.h.

The Version field in a certificate has values either 1 or 3 for version 3 certificates.  Version 1 certificates do not support the extensions field so it is not possible to distinguish a CA from a person, thus their usage should be avoided.

The validity dates are there to indicate the date that the specific certificate was activated and the date the certificate's key would be considered invalid.

Certificate extensions are there to include information about the certificate's subject that did not fit in the typical certificate fields. Those may be e-mail addresses, flags that indicate whether the belongs to a CA etc.  All the supported X.509 version 3 extensions are shown in tab:x509-ext.

Extension   OID   Description

Subject key id   2.5.29.14
An identifier of the key of the subject.

Authority key id   2.5.29.35
An identifier of the authority's key used to sign the certificate.

Subject alternative name   2.5.29.17
Alternative names to subject's distinguished name.

Key usage   2.5.29.15
Constraints the key's usage of the certificate.

Extended key usage   2.5.29.37
Constraints the purpose of the certificate.

Basic constraints   2.5.29.19
Indicates whether this is a CA certificate or not, and specify the
maximum path lengths of certificate chains.

CRL distribution points   2.5.29.31
This extension is set by the CA, in order to inform about the issued
CRLs.

Certificate policy   2.5.29.32
This extension is set to indicate the certificate policy as object
identifier and may contain a descriptive string or URL.

Proxy Certification Information   1.3.6.1.5.5.7.1.14
Proxy Certificates includes this extension that contains the OID of
the proxy policy language used, and can specify limits on the maximum
lengths of proxy chains.  Proxy Certificates are specified in
RFC3820.

Table: X.509 certificate extensions.

In GnuTLS the X.509 certificate structures are handled using the gnutls_x509_crt_t type and the corresponding private keys with the gnutls_x509_privkey_t type.  All the available functions for X.509 certificate handling have their prototypes in gnutls/x509.h. An example program to demonstrate the X.509 parsing capabilities can be found in ex:x509-info.

Importing an X.509 certificate
..............................

The certificate structure should be initialized using gnutls_x509_crt_init, and a certificate structure can be imported using gnutls_x509_crt_import.

gnutls_x509_crt_init,gnutls_x509_crt_import,gnutls_x509_crt_deinit

In several functions an array of certificates is required. To assist in initialization and import the following two functions are provided.

gnutls_x509_crt_list_import,gnutls_x509_crt_list_import2

In all cases after use a certificate must be deinitialized using gnutls_x509_crt_deinit. Note that although the functions above apply to gnutls_x509_crt_t structure, similar functions exist for the CRL structure gnutls_x509_crl_t.

X.509 distinguished names
.........................

The ``subject'' of an X.509 certificate is not described by a single name, but rather with a distinguished name. This in X.509 terminology is a list of strings each associated an object identifier. To make things simple GnuTLS provides gnutls_x509_crt_get_dn2 which follows the rules in RFC4514 and returns a single string. Access to each string by individual object identifiers can be accessed using gnutls_x509_crt_get_dn_by_oid.

gnutls_x509_crt_get_dn2 gnutls_x509_crt_get_dn,gnutls_x509_crt_get_dn_by_oid,gnutls_x509_crt_get_dn_oid

Similar functions exist to access the distinguished name of the issuer of the certificate.

gnutls_x509_crt_get_issuer_dn,gnutls_x509_crt_get_issuer_dn2,gnutls_x509_crt_get_issuer_dn_by_oid,gnutls_x509_crt_get_issuer_dn_oid,gnutls_x509_crt_get_issuer

The more powerful gnutls_x509_crt_get_subject and gnutls_x509_dn_get_rdn_ava provide efficient but low-level access to the contents of the distinguished name structure.

gnutls_x509_crt_get_subject,gnutls_x509_crt_get_issuer gnutls_x509_dn_get_rdn_ava

Accessing public and private keys
.................................

Each X.509 certificate contains a public key that corresponds to a private key. To get a unique identifier of the public key the gnutls_x509_crt_get_key_id function is provided. To export the public key or its parameters you may need to convert the X.509 structure to a gnutls_pubkey_t. See Abstract public keys for more information.

gnutls_x509_crt_get_key_id

The private key parameters may be directly accessed by using one of the following functions.

gnutls_x509_privkey_get_pk_algorithm2,gnutls_x509_privkey_export_rsa_raw2,gnutls_x509_privkey_export_ecc_raw,gnutls_x509_privkey_export_dsa_raw,gnutls_x509_privkey_get_key_id

Verifying X.509 certificate paths
.................................

Verifying certificate paths is important in X.509 authentication. For this purpose the following functions are provided.

gnutls_x509_trust_list_add_cas gnutls_x509_trust_list_add_named_crt gnutls_x509_trust_list_add_crls gnutls_x509_trust_list_verify_crt gnutls_x509_trust_list_verify_named_crt

gnutls_x509_trust_list_add_trust_file gnutls_x509_trust_list_add_trust_mem gnutls_x509_trust_list_add_system_trust

The verification function will verify a given certificate chain against a list of certificate authorities and certificate revocation lists, and output a bit-wise OR of elements of the gnutls_certificate_status_t enumeration shown in gnutls_certificate_status_t. The GNUTLS_CERT_INVALID flag is always set on a verification error and more detailed flags will also be set when appropriate.

gnutls_certificate_status_t,The gnutls_certificate_status_t enumeration.

An example of certificate verification is shown in ex:verify2. It is also possible to have a set of certificates that are trusted for a particular server but not to authorize other certificates. This purpose is served by the functions gnutls_x509_trust_list_add_named_crt and gnutls_x509_trust_list_verify_named_crt.

Verifying a certificate in the context of TLS session
.....................................................

When operating in the context of a TLS session, the trusted certificate authority list may also be set using: gnutls_certificate_set_x509_trust_file,gnutls_certificate_set_x509_crl_file,gnutls_certificate_set_x509_system_trust

Then it is not required to setup a trusted list as above. The function gnutls_certificate_verify_peers3 may then be used to verify the peer's certificate chain and identity. The flags are set similarly to the verification functions in the previous section.

There is also the possibility to pass some input to the verification functions in the form of flags. For gnutls_x509_trust_list_verify_crt the flags are passed straightforward, but gnutls_certificate_verify_peers3 depends on the flags set by calling gnutls_certificate_set_verify_flags.  All the available flags are part of the enumeration gnutls_certificate_verify_flags shown in gnutls_certificate_verify_flags.

gnutls_certificate_verify_flags,The gnutls_certificate_verify_flags enumeration.

OpenPGP certificates
--------------------

The OpenPGP key authentication relies on a distributed trust model, called the ``web of trust''. The ``web of trust'' uses a decentralized system of trusted introducers, which are the same as a CA. OpenPGP allows anyone to sign anyone else's public key. When Alice signs Bob's key, she is introducing Bob's key to anyone who trusts Alice. If someone trusts Alice to introduce keys, then Alice is a trusted introducer in the mind of that observer. For example in fig:openpgp, David trusts Alice to be an introducer and Alice signed Bob's key thus Dave trusts Bob's key to be the real one.

Figure: An example of the OpenPGP trust model.

There are some key points that are important in that model. In the example Alice has to sign Bob's key, only if she is sure that the key belongs to Bob. Otherwise she may also make Dave falsely believe that this is Bob's key. Dave has also the responsibility to know who to trust.  This model is similar to real life relations.

Just see how Charlie behaves in the previous example. Although he has signed Bob's key - because he knows, somehow, that it belongs to Bob - he does not trust Bob to be an introducer. Charlie decided to trust only Kevin, for some reason. A reason could be that Bob is lazy enough, and signs other people's keys without being sure that they belong to the actual owner.

Field   Description

version
The field that indicates the version of the OpenPGP structure.

user ID
An RFC 2822 string that identifies the owner of the key. There may be
multiple user identifiers in a key.

public key
The main public key of the certificate.

expiration
The expiration time of the main public key.

public subkey
An additional public key of the certificate. There may be multiple subkeys
in a certificate.

public subkey expiration
The expiration time of the subkey.

Table: OpenPGP certificate fields.

OpenPGP certificate structure
.............................

In GnuTLS the OpenPGP certificate structures RFC2440 are handled using the gnutls_openpgp_crt_t type. A typical certificate contains the user ID, which is an RFC 2822 mail and name address, a public key, possibly a number of additional public keys (called subkeys), and a number of signatures. The various fields are shown in tab:openpgp-certificate.

The additional subkeys may provide key for various different purposes, e.g. one key to encrypt mail, and another to sign a TLS key exchange. Each subkey is identified by a unique key ID. The keys that are to be used in a TLS key exchange that requires signatures are called authentication keys in the OpenPGP jargon. The mapping of TLS key exchange methods to public keys is shown in tab:openpgp-key-exchange.

Key exchange   Public key requirements

RSA
An RSA public key that allows encryption.

DHE_RSA
An RSA public key that is marked for authentication.

ECDHE_RSA
An RSA public key that is marked for authentication.

DHE_DSS
A DSA public key that is marked for authentication.

Table: The types of (sub)keys required for the various TLS key exchange methods.

The corresponding private keys are stored in the gnutls_openpgp_privkey_t type. All the prototypes for the key handling functions can be found in gnutls/openpgp.h.

Verifying an OpenPGP certificate
................................

The verification functions of OpenPGP keys, included in GnuTLS, are simple ones, and do not use the features of the ``web of trust''.  For that reason, if the verification needs are complex, the assistance of external tools like GnuPG and GPGME (http://www.gnupg.org/related_software/gpgme/) is recommended.

In GnuTLS there is a verification function for OpenPGP certificates, the gnutls_openpgp_crt_verify_ring.  This checks an OpenPGP key against a given set of public keys (keyring) and returns the key status. The key verification status is the same as in X.509 certificates, although the meaning and interpretation are different. For example an OpenPGP key may be valid, if the self signature is ok, even if no signers were found.  The meaning of verification status flags is the same as in the X.509 certificates (see gnutls_certificate_verify_flags).

gnutls_openpgp_crt_verify_ring

gnutls_openpgp_crt_verify_self

Verifying a certificate in the context of a TLS session
.......................................................

Similarly with X.509 certificates, one needs to specify the OpenPGP keyring file in the credentials structure. The certificates in this file will be  used by gnutls_certificate_verify_peers3 to verify the signatures in the certificate sent by the peer.

gnutls_certificate_set_openpgp_keyring_file

Advanced certificate verification
---------------------------------

The verification of X.509 certificates in the HTTPS and other Internet protocols is typically done by loading a trusted list of commercial Certificate Authorities (see gnutls_certificate_set_x509_system_trust), and using them as trusted anchors. However, there are several examples (eg. the Diginotar incident) where one of these authorities was compromised. This risk can be mitigated by using in addition to CA certificate verification, other verification methods. In this section we list the available in GnuTLS methods.

Verifying a certificate using trust on first use authentication
...............................................................

It is possible to use a trust on first use (TOFU) authentication method in GnuTLS. That is the concept used by the SSH programs, where the public key of the peer is not verified, or verified in an out-of-bound way, but subsequent connections to the same peer require the public key to remain the same.  Such a system in combination with the typical CA verification of a certificate, and OCSP revocation checks, can help to provide multiple factor verification, where a single point of failure is not enough to compromise the system. For example a server compromise may be detected using OCSP, and a CA compromise can be detected using the trust on first use method. Such a hybrid system with X.509 and trust on first use authentication is shown in Simple client example with SSH-style certificate verification.

See Certificate verification on how to use the available functionality.

Verifying a certificate using DANE (DNSSEC)
...........................................

The DANE protocol is a protocol that can be used to verify TLS certificates using the DNS (or better DNSSEC) protocols. The DNS security extensions (DNSSEC) provide an alternative public key infrastructure to the commercial CAs that are typically used to sign TLS certificates. The DANE protocol takes advantage of the DNSSEC infrastructure to verify TLS certificates. This can be in addition to the verification by CA infrastructure or may even replace it where DNSSEC is fully deployed. Note however, that DNSSEC deployment is fairly new and it would be better to use it as an additional verification method rather than the only one.

The DANE functionality is provided by the libgnutls-dane library that is shipped with GnuTLS and the function prototypes are in gnutls/dane.h. See Certificate verification for information on how to use the library.

Note however, that the DANE RFC mandates the verification methods one should use in addition to the validation via DNSSEC TLSA entries. GnuTLS doesn't follow that RFC requirement, and the term DANE verification in this manual refers to the TLSA entry verification. In GnuTLS any other verification methods can be used (e.g., PKIX or TOFU) on top of DANE.

Digital signatures
------------------

In this section we will provide some information about digital signatures, how they work, and give the rationale for disabling some of the algorithms used.

Digital signatures work by using somebody's secret key to sign some arbitrary data.  Then anybody else could use the public key of that person to verify the signature.  Since the data may be arbitrary it is not suitable input to a cryptographic digital signature algorithm. For this reason and also for performance cryptographic hash algorithms are used to preprocess the input to the signature algorithm. This works as long as it is difficult enough to generate two different messages with the same hash algorithm output. In that case the same signature could be used as a proof for both messages. Nobody wants to sign an innocent message of donating 1 euro to Greenpeace and find out that he donated 1.000.000 euros to Bad Inc.

For a hash algorithm to be called cryptographic the following three requirements must hold:

 1. Preimage resistance. That means the algorithm must be one way and given the output of the hash function H(x), it is impossible to calculate x.

 2. 2nd preimage resistance. That means that given a pair x,y with y=H(x) it is impossible to calculate an x' such that y=H(x').

 3. Collision resistance. That means that it is impossible to calculate random x and x' such H(x')=H(x).

The last two requirements in the list are the most important in digital signatures. These protect against somebody who would like to generate two messages with the same hash output. When an algorithm is considered broken usually it means that the Collision resistance of the algorithm is less than brute force. Using the birthday paradox the brute force attack takes 2^((hash size) / 2) operations. Today colliding certificates using the MD5 hash algorithm have been generated as shown in WEGER.

There has been cryptographic results for the SHA-1 hash algorithms as well, although they are not yet critical.  Before 2004, MD5 had a presumed collision strength of 2^64, but it has been showed to have a collision strength well under 2^50.  As of November 2005, it is believed that SHA-1's collision strength is around 2^63.  We consider this sufficiently hard so that we still support SHA-1.  We anticipate that SHA-256/386/512 will be used in publicly-distributed certificates in the future.  When 2^63 can be considered too weak compared to the computer power available sometime in the future, SHA-1 will be disabled as well.  The collision attacks on SHA-1 may also get better, given the new interest in tools for creating them.

Trading security for interoperability
.....................................

If you connect to a server and use GnuTLS' functions to verify the certificate chain, and get a GNUTLS_CERT_INSECURE_ALGORITHM validation error (see Verifying X.509 certificate paths), it means that somewhere in the certificate chain there is a certificate signed using RSA-MD2 or RSA-MD5.  These two digital signature algorithms are considered broken, so GnuTLS fails verifying the certificate.  In some situations, it may be useful to be able to verify the certificate chain anyway, assuming an attacker did not utilize the fact that these signatures algorithms are broken. This section will give help on how to achieve that.

It is important to know that you do not have to enable any of the flags discussed here to be able to use trusted root CA certificates self-signed using RSA-MD2 or RSA-MD5. The certificates in the trusted list are considered trusted irrespective of the signature.

If you are using gnutls_certificate_verify_peers3 to verify the certificate chain, you can call gnutls_certificate_set_verify_flags with the flags:

  * GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2

  * GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5

as in the following example:

       gnutls_certificate_set_verify_flags (x509cred,
                                            GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5);

This will signal the verifier algorithm to enable RSA-MD5 when verifying the certificates.

If you are using gnutls_x509_crt_verify or gnutls_x509_crt_list_verify, you can pass the GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5 parameter directly in the flags parameter.

If you are using these flags, it may also be a good idea to warn the user when verification failure occur for this reason.  The simplest is to not use the flags by default, and only fall back to using them after warning the user.  If you wish to inspect the certificate chain yourself, you can use gnutls_certificate_get_peers to extract the raw server's certificate chain, gnutls_x509_crt_list_import to parse each of the certificates, and then gnutls_x509_crt_get_signature_algorithm to find out the signing algorithm used for each certificate.  If any of the intermediary certificates are using GNUTLS_SIGN_RSA_MD2 or GNUTLS_SIGN_RSA_MD5, you could present a warning.