Problem
ParseResponse currently validates the TimeStampResp status, parses the TimeStampToken, and verifies its CMS signature when the TSA certificate is embedded. It then exposes HashAlgorithm, HashedMessage, Nonce, Policy, and Certificates.
It cannot establish that the response belongs to a particular request because the API receives only response bytes. RFC 3161 section 2.2 requires the requester to verify the returned algorithm, message imprint, nonce/freshness, TSA certificate identifier, token signature, and requested policy before accepting the token.
Consumers therefore need to reimplement this security-critical binding. digitorus/pdfsign PR #153 now performs those checks locally at its HTTP boundary.
This is related to #10, but focuses specifically on validating a response against its originating request.
Proposed API
Add a request-aware API while preserving ParseResponse for compatibility, for example:
func ParseResponseForRequest(
response []byte,
request []byte,
options *VerificationOptions,
) (*Timestamp, error)
Alternatively, accept a parsed Request.
The validation should cover:
- recognized successful PKIStatus values;
- response hash algorithm and message imprint matching the request;
- nonce equality when requested;
- requested policy equality;
- presence of the requested TSA certificate when certReq is true;
- cryptographic token signature validation;
- ESS certificate identifier binding;
- optional caller-provided TSA certificates, roots, or verification callback when the token omits its certificate or trust validation is required.
Trust-chain and revocation policy should remain caller-configurable rather than being conflated with syntactic request binding.
Tests
Include valid controls plus wrong algorithm, wrong imprint, missing/wrong nonce, wrong policy, missing requested certificate, invalid token signature, and externally supplied TSA certificate cases.
RFC 3161: https://www.rfc-editor.org/rfc/rfc3161.html#section-2.2
pdfsign PR: digitorus/pdfsign#153
Problem
ParseResponse currently validates the TimeStampResp status, parses the TimeStampToken, and verifies its CMS signature when the TSA certificate is embedded. It then exposes HashAlgorithm, HashedMessage, Nonce, Policy, and Certificates.
It cannot establish that the response belongs to a particular request because the API receives only response bytes. RFC 3161 section 2.2 requires the requester to verify the returned algorithm, message imprint, nonce/freshness, TSA certificate identifier, token signature, and requested policy before accepting the token.
Consumers therefore need to reimplement this security-critical binding. digitorus/pdfsign PR #153 now performs those checks locally at its HTTP boundary.
This is related to #10, but focuses specifically on validating a response against its originating request.
Proposed API
Add a request-aware API while preserving ParseResponse for compatibility, for example:
Alternatively, accept a parsed Request.
The validation should cover:
Trust-chain and revocation policy should remain caller-configurable rather than being conflated with syntactic request binding.
Tests
Include valid controls plus wrong algorithm, wrong imprint, missing/wrong nonce, wrong policy, missing requested certificate, invalid token signature, and externally supplied TSA certificate cases.
RFC 3161: https://www.rfc-editor.org/rfc/rfc3161.html#section-2.2
pdfsign PR: digitorus/pdfsign#153