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::).

