kend for the storage of entries. If it is NULL then the default file backend will be used. Unless an alternative ‘tdb’ is provided, the storage format is a textual format consisting of a line for each host with fields separated by '|'. The contents of the fields are a format-identifier which is set to 'g0', the hostname that the rest of the data applies to, the numeric port or host name, the expiration time in seconds since the epoch (0 for no expiration), and a base64 encoding of the raw (DER) public key information (SPKI) of the peer. As of GnuTLS 3.6.6 this function also accepts raw public keys. *Returns:* On success, ‘GNUTLS_E_SUCCESS’ (0) is returned, otherwise a negative error value. *Since:* 3.0.13 In addition to the above the *note gnutls_store_commitment:: can be used to implement a key-pinning architecture as in [*note KEYPIN::]. This provides a way for web server to commit on a public key that is not yet active. -- Function: int gnutls_store_commitment (const char * DB_NAME, gnutls_tdb_t TDB, const char * HOST, const char * SERVICE, gnutls_digest_algorithm_t HASH_ALGO, const gnutls_datum_t * HASH, time_t EXPIRATION, unsigned int FLAGS) DB_NAME: A file specifying the stored keys (use NULL for the default) TDB: A storage structure or NULL to use the default HOST: The peer's name SERVICE: non-NULL if this key is specific to a service (e.g. http) HASH_ALGO: The hash algorithm type HASH: The raw hash EXPIRATION: The expiration time (use 0 to disable expiration) FLAGS: should be 0 or ‘GNUTLS_SCOMMIT_FLAG_ALLOW_BROKEN’ . This function will store the provided hash commitment to the list of stored public keys. The key with the given hash will be considered valid until the provided expiration time. The ‘tdb’ variable if non-null specifies a custom backend for the storage of entries. If it is NULL then the default file backend will be used. Note that this function is not thread safe with the default backend. *Returns:* On success, ‘GNUTLS_E_SUCCESS’ (0) is returned, otherwise a negative error value. *Since:* 3.0 The storage and verification functions may be used with the default text file based back-end, or another back-end may be specified. That should contain storage and retrieval functions and specified as below. ‘INT *note gnutls_tdb_init:: (gnutls_tdb_t * TDB)’ ‘VOID *note gnutls_tdb_deinit:: (gnutls_tdb_t TDB)’ ‘VOID *note gnutls_tdb_set_verify_func:: (gnutls_tdb_t TDB, gnutls_tdb_verify_func VERIFY)’ ‘VOID *note gnutls_tdb_set_store_func:: (gnutls_tdb_t TDB, gnutls_tdb_store_func STORE)’ ‘VOID *note gnutls_tdb_set_store_commitment_func:: (gnutls_tdb_t TDB, gnutls_tdb_store_commitment_func CSTORE)’ 6.12.3.2 DANE verification .......................... Since the DANE library is not included in GnuTLS it requires programs to be linked against it. This can be achieved with the following commands. gcc -o foo foo.c `pkg-config gnutls-dane --cflags --libs` When a program uses the GNU autoconf system, then the following line or similar can be used to detect the presence of the library. PKG_CHECK_MODULES([LIBDANE], [gnutls-dane >= 3.0.0]) AC_SUBST([LIBDANE_CFLAGS]) AC_SUBST([LIBDANE_LIBS]) The high level functionality provided by the DANE library is shown below. -- Function: int dane_verify_crt (dane_state_t S, const gnutls_datum_t * CHAIN, unsigned CHAIN_SIZE, gnutls_certificate_type_t CHAIN_TYPE, const char * HOSTNAME, const char * PROTO, unsigned int PORT, unsigned int SFLAGS, unsigned int VFLAGS, unsigned int * VERIFY) S: A DANE state structure (may be NULL) CHAIN: A certificate chain CHAIN_SIZE: The size of the chain CHAIN_TYPE: The type of the certificate chain HOSTNAME: The hostname associated with the chain PROTO: The protocol of the service connecting (e.g. tcp) PORT: The port of the service connecting (e.g. 443) SFLAGS: Flags for the initialization of ‘s’ (if NULL) VFLAGS: Verification flags; an OR'ed list of ‘dane_verify_flags_t’ . VERIFY: An OR'ed list of ‘dane_verify_status_t’ . This function will verify the given certificate chain against the CA constrains and/or the certificate available via DANE. If no information via DANE can be obtained the flag ‘DANE_VERIFY_NO_DANE_INFO’ is set. If a DNSSEC signature is not available for the DANE record then the verify flag ‘DANE_VERIFY_NO_DNSSEC_DATA’ is set. Due to the many possible options of DANE, there is no single threat model countered. When notifying the user about DANE verification results it may be better to mention: DANE verification did not reject the certificate, rather than mentioning a successful DANE verification. Note that this function is designed to be run in addition to PKIX - certificate chain - verification. To be run independently the ‘DANE_VFLAG_ONLY_CHECK_EE_USAGE’ flag should be specified; then the function will check whether the key of the peer matches the key advertised in the DANE entry. *Returns:* a negative error code on error and ‘DANE_E_SUCCESS’ (0) when the DANE entries were successfully parsed, irrespective of whether they were verified (see ‘verify’ for that information). If no usable entries were encountered ‘DANE_E_REQUESTED_DATA_NOT_AVAILABLE’ will be returned. ‘INT *note dane_verify_session_crt:: (dane_state_t S, gnutls_session_t SESSION, const char * HOSTNAME, const char * PROTO, unsigned int PORT, unsigned int SFLAGS, unsigned int VFLAGS, unsigned int * VERIFY)’ ‘CONST CHAR * *note dane_strerror:: (int ERROR)’ Note that the ‘dane_state_t’ structure that is accepted by both verification functions is optional. It is required when many queries are performed to optimize against multiple re-initializations of the resolving back-end and loading of DNSSEC keys. The following flags are returned by the verify functions to indicate the status of the verification. ‘DANE_VERIFY_CA_CONSTRAINTS_VIOLATED’ The CA constraints were violated. ‘DANE_VERIFY_CERT_DIFFERS’ The certificate obtained via DNS differs. ‘DANE_VERIFY_UNKNOWN_DANE_INFO’ No known DANE data was found in the DNS record. Figure 6.3: The DANE verification status flags. In order to generate a DANE TLSA entry to use in a DNS server you may use danetool (see *note danetool Invocation::).