Document XAdES certificate trust and timestamp validation procedures

[kislyuk]

For timestamps, see: https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/doc/dss-documentation.html#Timestamps

For signer, support and document support for any RFC 3161 compatible timestamp authority server, with the default set to one of the entries in https://gist.github.com/Manouchehri/fd754e402d98430243455713efada710.

• A RFC 3161 client implementation that can be used for reference, but we won't be adding as a dependency: https://github.com/trbs/rfc3161ng
• https://github.com/wbond/asn1crypto supports ASN.1 primitives like GeneralizedTime for use with the RFC 3161 API (https://github.com/wbond/asn1crypto/blob/master/asn1crypto/tsp.py)
• https://pypi.org/project/pyasice/

[kislyuk]

For EU eSignature applications, the EU publishes what looks like the complete list of trusted X509 certificates in the EU LOTL: https://ec.europa.eu/tools/lotl/eu-lotl.xml - unclear if we should support this directly or instruct users to configure their system trust store. If we support this directly, we should support loading any DSS trusted list from an XML URL in the "TLSource" format described in https://ec.europa.eu/digital-building-blocks/DSS/webapp-demo/doc/dss-documentation.html#TrustedLists

[kislyuk]

For timestamp verification requirements, see RFC 3161 Appendix B:

APPENDIX B - Placing a Signature At a Particular Point in Time

   We present an example of a possible use of this general time-stamping
   service.  It places a signature at a particular point in time, from
   which the appropriate certificate status information (e.g., CRLs)
   MUST be checked.  This application is intended to be used in
   conjunction with evidence generated using a digital signature
   mechanism.

   Signatures can only be verified according to a non-repudiation
   policy. This policy MAY be implicit or explicit (i.e., indicated in
   the evidence provided by the signer).  The non-repudiation policy can
   specify, among other things, the time period allowed by a signer to
   declare the compromise of a signature key used for the generation of
   digital signatures.  Thus a signature may not be guaranteed to be
   valid until the termination of this time period.

   To verify a digital signature, the following basic technique may be
   used:

   A) Time-stamping information needs to be obtained soon after the
      signature has been produced (e.g., within a few minutes or hours).

      1)    The signature is presented to the Time Stamping Authority
            (TSA).  The TSA then returns a TimeStampToken (TST) upon
            that signature.

      2)    The invoker of the service MUST then verify that the
            TimeStampToken is correct.

   B) The validity of the digital signature may then be verified in the
      following way:

      1)    The time-stamp token itself MUST be verified and it MUST be
            verified that it applies to the signature of the signer.

      2)    The date/time indicated by the TSA in the TimeStampToken
            MUST be retrieved.

      3)    The certificate used by the signer MUST be identified and
            retrieved.

      4)    The date/time indicated by the TSA MUST be within the
            validity period of the signer's certificate.

      5)    The revocation information about that certificate, at the
            date/time of the Time-Stamping operation, MUST be retrieved.

      6)    Should the certificate be revoked, then the date/time of
            revocation shall be later than the date/time indicated by
            the TSA.

   If all these conditions are successful, then the digital signature
   shall be declared as valid.

[kislyuk]

RFC 5816:
2. Updates to RFC 3161

2.1. Changes to Section 2.4.1, Request Format

Last paragraph on Page 5.

Old:

  If the certReq field is present and set to true, the TSA's public
  key certificate that is referenced by the [ESS](https://datatracker.ietf.org/doc/html/rfc5816#ref-ESS)CertID identifier
  inside a SigningCertificate attribute in the response MUST be
  provided by the TSA in the certificates field from the SignedData
  structure in that response.  That field may also contain other
  certificates.

New:

  If the certReq field is present and set to true, the TSA's public
  key certificate that is referenced by the ESSCertID [ESS] field
  inside a SigningCertificate attribute or by the ESSCertIDv2
  [[ESSV2](https://datatracker.ietf.org/doc/html/rfc5816#ref-ESSV2)] field inside a SigningCertificateV2 attribute in the
  response MUST be provided by the TSA in the certificates field
  from the SignedData structure in that response.  That field may
  also contain other certificates.

2.2. Changes to Section 2.4.2, Response Format

2.2.1. Signature of Time-Stamp Token

Fifth paragraph on Page 8, just before the definition of TSTInfo.

Old:

  The time-stamp token MUST NOT contain any signatures other than
  the signature of the TSA.  The certificate identifier ([ESS](https://datatracker.ietf.org/doc/html/rfc5816#ref-ESS)CertID)
  of the TSA certificate MUST be included as a signerInfo attribute
  inside a SigningCertificate attribute.

New:

  The time-stamp token MUST NOT contain any signatures other than
  the signature of the TSA.  The certificate identifier (either
  ESSCertID [ESS] or ESSCertIDv2 [[ESSV2](https://datatracker.ietf.org/doc/html/rfc5816#ref-ESSV2)]) of the TSA certificate
  MUST be included as a signerInfo attribute inside a
  SigningCertificate attribute.

  Note: As mentioned in [RFC 5035](https://datatracker.ietf.org/doc/html/rfc5035) [[ESSV2](https://datatracker.ietf.org/doc/html/rfc5816#ref-ESSV2)], the SigningCertificateV2
        attribute MUST be used if any algorithm other than SHA-1 is
        used and SHOULD NOT be used for SHA-1.

  Note: For backwards compatibility, in line with [RFC 5035](https://datatracker.ietf.org/doc/html/rfc5035), both
        ESSCertID and ESSCertIDv2 MAY be present.  Systems MAY
        ignore ESSCertIDv2 if [RFC 5035](https://datatracker.ietf.org/doc/html/rfc5035) has not been implemented.

2.2.2. Verifying the Time-Stamp Token

Third paragraph on Page 11.

Old:

  The purpose of the tsa field is to give a hint in identifying the
  name of the TSA.  If present, it MUST correspond to one of the
  subject names included in the certificate that is to be used to
  verify the token.  However, the actual identification of the
  entity that signed the response will always occur through the use
  of the certificate identifier ([ESS](https://datatracker.ietf.org/doc/html/rfc5816#ref-ESS)CertID Attribute) inside a
  SigningCertificate attribute which is part of the signerInfo (See
  Section 5 of [[ESS](https://datatracker.ietf.org/doc/html/rfc5816#ref-ESS)]).

New:

  The purpose of the tsa field is to give a hint in identifying the
  name of the TSA.  If present, it MUST correspond to one of the
  subject names included in the certificate that is to be used to
  verify the token.  However, the actual identification of the
  entity that signed the response will always occur through the use
  of the certificate identifier (ESSCertID inside a
  SigningCertificate attribute or ESSCertIDv2 inside a
  SigningCertificateV2 attribute) that is part of the signerInfo
  (see Section 5 of [ESS] and [Section 3](https://datatracker.ietf.org/doc/html/rfc5816#section-3) of [[ESSV2](https://datatracker.ietf.org/doc/html/rfc5816#ref-ESSV2)]).

3. Security Considerations

This document incorporates the security considerations of RFC 5035
[ESSV2] with further explanations in this section.

ESSCertID provides a means based on the SHA-1 hash algorithm for
identifying the certificate used to verify the signature on a time
stamp. The use of ESSCertIDv2 aims to enable implementers to comply
with policies that require phasing out all uses of the SHA-1
algorithm.

The update provided by this document is motivated by reasons of
interoperability and migration to other hash algorithms rather than
mitigating new security issues.