Subject: [pkix] Requesting information on Time stamp authority certificate expiry.

From: Anoop Gulati <[email-masked]>
Date: Thu, 4 Jan 2018 12:22:15 -0600

Hi Team,
Happy 2018!

I'm requesting some clarification on the status of a timestamped signature
when the timestamp authority (TSA) certificate expires.

My understanding is timestamp is applied to a digital signature to ensure
the digital signature continues to stay valid past the lifetime of the
signing certificate.
RFC 3161, in section 4.3 briefly talks about TSA certificate lifetimes but
it does not clarify the situation of a natural TSA certificate expiry.

We recently experienced an enterprise-wide outage when java started to
error out on a signed & timestamped jar file when the TSA certificate
expired.
Windows, on the other hand does not error out on signed & timestamped files
on TSA certificate expiry.

So, it seems like, even implementation between platforms is not consistent.
Hence I'm writing to understand how expiry of a TSA certificate impacts
existing signed and timestamped files.
Sincere apologies in advance if this is not the right platform to discuss
this, I was not able to find a working group specifically for digital
timestamp & TSAs.

Thanks,

Anoop

---

From: Koichi Sugimoto <[email-masked]>
Date: Fri, 5 Jan 2018 03:01:11 +0000

Hello & Happy New Year,

This problem also relates to code signing.
As specified in “Minimum Requirements for Code Signing Certificates” managed by CSCA, revocation of code signing certificates also affects to the signed objects.
SEE: https://casecurity.org/2016/07/20/minimum-requirements-for-code-signing-certificates/
But AFAIK, such behavior has not explained in this working group as well.

Regards,
Koichi Sugimoto.

From: pkix [mailto:[email-masked]] On Behalf Of Anoop Gulati
Sent: Friday, January 5, 2018 3:22 AM
To: [email-masked]
Subject: [pkix] Requesting information on Time stamp authority certificate expiry.

Hi Team,
Happy 2018!

I'm requesting some clarification on the status of a timestamped signature when the timestamp authority (TSA) certificate expires.
My understanding is timestamp is applied to a digital signature to ensure the digital signature continues to stay valid past the lifetime of the signing certificate.
RFC 3161, in section 4.3 briefly talks about TSA certificate lifetimes but it does not clarify the situation of a natural TSA certificate expiry.

We recently experienced an enterprise-wide outage when java started to error out on a signed & timestamped jar file when the TSA certificate expired.
Windows, on the other hand does not error out on signed & timestamped files on TSA certificate expiry.

So, it seems like, even implementation between platforms is not consistent.
Hence I'm writing to understand how expiry of a TSA certificate impacts existing signed and timestamped files.
Sincere apologies in advance if this is not the right platform to discuss this, I was not able to find a working group specifically for digital timestamp & TSAs.

Thanks,

Anoop

---

From: Jim Schaad <[email-masked]>
Date: Fri, 5 Jan 2018 18:21:54 -0800

While one can interpret a timestamp as extending the life of a signed object, that is not the technical definition of a timestamp.

A timestamp says “I successfully validated the signature on this object at time X”.  One can chain timestamps together so that a second timestamp could be made on the first one which allows one to do a chain of inference.  

Code signing generates a problem because there is no opportunity to apply a new timestamp and re-distribute the result which is what should happen.  Therefore, a hard coded public key is used which is “known” to be good past the certificate expiration date.  God help us if the key is ever compromised.  Additionally, problems are going to occur over time with the hash algorithm being declared as not longer usable for the counter signature.

The correct rule ought to be, when the TSA certificate expires the signature expires and it no longer tells you anything more.  If there is a chain one may be able to infer things, but changes in algorithms can kill you.   You can look at the work of the LTANS WG for some back ground (RFC 4998 and RFC 5698 are good starters).

From: pkix [mailto:[email-masked]] On Behalf Of Anoop Gulati
Sent: Thursday, January 4, 2018 10:22 AM
To: [email-masked]
Subject: [pkix] Requesting information on Time stamp authority certificate expiry.

Hi Team,

Happy 2018!

Thanks,

Anoop

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 6 Jan 2018 02:27:21 +0000

Jim Schaad <[email-masked]> writes:

>The correct rule ought to be, when the TSA certificate expires the signature
>expires and it no longer tells you anything more.

Just because the cert has expired doesn't mean the signature automatically
invalidates itself.  The TSA countersig still tells you that the signed item
was OK at time X, if you securely store a copy of it after the expiry time (or
countersign it yourself, or whatever) you can refer back to your known-good
copy to check that it's still OK.

It's really an ecumenical matt^H^H^Hpolicy issue as to how you manage this.

Peter.

---

From: Jim Schaad <[email-masked]>
Date: Fri, 5 Jan 2018 20:00:43 -0800

> -----Original Message-----
> From: Peter Gutmann [mailto:[email-masked]]
> Sent: Friday, January 5, 2018 6:27 PM
> To: Jim Schaad <[email-masked]>; 'Anoop Gulati'
> <[email-masked]>; [email-masked]
> Subject: Re: [pkix] Requesting information on Time stamp authority
> certificate expiry.
> 
> >The correct rule ought to be, when the TSA certificate expires the
> >signature expires and it no longer tells you anything more.
> 
> invalidates itself.  The TSA countersig still tells you that the signed
item was
> OK at time X, if you securely store a copy of it after the expiry time (or

I was referring to the TSA signature not the original signature.  On a new
copy you cannot assume anything.  I agree that if you securely store the
item while it was originally good then you can still make some assumptions
about it still being the same as it originally was.

---

From: Anoop Gulati <[email-masked]>
Date: Wed, 17 Jan 2018 16:18:03 -0600

Many thanks for the responses and further explanation on the workings of
the TSA.

This poses a logistical challenge of redistributing a new signed copy of
code.
Also, apart from monitoring signing key expiration, we now also got to
monitor TSA key expiration.

I agree with your description of the TSA service, “I successfully validated
the signature on this object at time X", but apps & platforms not
acknowledging this fact post TSA key expiry is whats causing the impact.
I also agree with your point: "If there is a chain one may be able to infer
things, but changes in algorithms can kill you.", but this can be managed
as all previous alg. changes have been dealt with on an OS level.
e.g.:
https://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-sha1-certificates.aspx
.