+ <varlistentry><term>Check-Valid-Until</term>
+ <listitem><para>Security related option defaulting to true as an
+ expiring validation for a Release file prevents longtime replay attacks
+ and can e.g. also help users to identify no longer updated mirrors -
+ but the feature depends on the correctness of the time on the user system.
+ Archive maintainers are encouraged to create Release files with the
+ <literal>Valid-Until</literal> header, but if they don't or a stricter value
+ is volitional the following <literal>Max-ValidTime</literal> option can be used.
+ </para></listitem>
+ </varlistentry>
+
+ <varlistentry><term>Max-ValidTime</term>
+ <listitem><para>Seconds the Release file should be considered valid after
+ it was created (indicated by the <literal>Date</literal> header).
+ If the Release file itself includes a <literal>Valid-Until</literal> header
+ the earlier date of the two is used as the expiration date.
+ The default value is <literal>0</literal> which stands for "for ever".
+ Archive specific settings can be made by appending the label of the archive
+ to the option name.
+ </para></listitem>
+ </varlistentry>
+
+ <varlistentry><term>Min-ValidTime</term>
+ <listitem><para>Minimum of seconds the Release file should be considered
+ valid after it was created (indicated by the <literal>Date</literal> header).
+ Use this if you need to use a seldomly updated (local) mirror of a more
+ regular updated archive with a <literal>Valid-Until</literal> header
+ instead of competely disabling the expiration date checking.
+ Archive specific settings can and should be used by appending the label of
+ the archive to the option name.
+ </para></listitem>
+ </varlistentry>
+