Open kislyuk opened 1 year ago
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
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.
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.
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.