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

Jim Schaad <> Sat, 06 January 2018 02:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2049C120713 for <>; Fri, 5 Jan 2018 18:22:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C1ekHcyuJ-JC for <>; Fri, 5 Jan 2018 18:22:14 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 59C93126C22 for <>; Fri, 5 Jan 2018 18:22:14 -0800 (PST)
Received: from Jude ( by ( with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 5 Jan 2018 18:20:34 -0800
From: Jim Schaad <>
To: 'Anoop Gulati' <>, <>
References: <>
In-Reply-To: <>
Date: Fri, 5 Jan 2018 18:21:54 -0800
Message-ID: <001901d38695$2277c500$67674f00$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01D38652.1456F600"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQH3iw0DpJOO6sVZAPQvik52kS6026MeAyLQ
Content-Language: en-us
X-Originating-IP: []
Archived-At: <>
Subject: Re: [pkix] Requesting information on Time stamp authority certificate expiry.
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 06 Jan 2018 02:22:17 -0000

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 [] On Behalf Of Anoop Gulati
Sent: Thursday, January 4, 2018 10:22 AM
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.