Re: [pkix] Validating Certs w/out reliable source of Time

"Dr. Pala" <> Mon, 08 October 2018 14:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 40B24130DE0 for <>; Mon, 8 Oct 2018 07:12:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1mKctRDTnnvi for <>; Mon, 8 Oct 2018 07:12:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1AB23130DCB for <>; Mon, 8 Oct 2018 07:12:47 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTP id EA5613740FE1; Mon, 8 Oct 2018 14:12:46 +0000 (UTC)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id LJWnIX9uViWh; Mon, 8 Oct 2018 10:12:40 -0400 (EDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id E278A3740FC1; Mon, 8 Oct 2018 10:12:39 -0400 (EDT)
To: "Panos Kampanakis (pkampana)" <>, PKIX <>
References: <> <>
From: "Dr. Pala" <>
Organization: OpenCA Labs
Message-ID: <>
Date: Mon, 8 Oct 2018 08:12:39 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050008060601050104060108"
Archived-At: <>
Subject: Re: [pkix] Validating Certs w/out reliable source of Time
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Oct 2018 14:12:50 -0000

Hi Panos, all,

thanks for the info. It seems nobody has a good story around it - the 
onboarding provides some obvious paths, but it does not provide really a 
good story around it and it is very prone to implementation errors (it 
seems more like giving up in having a good answer / system when you do 
not trust the network itself - which is the case I am trying to cover).

Although I totally agree with the difficulty around providing a 
solution, I am a bit worried about devices keeping logs/audit traces and 
then follow up on them at a later time - especially without providing 
guidance about what is a trusted source of time... :D I would expect 
many devices not to really check the validity of certificates after they 
have been "used" already.

In my specific use-case (which is not a generic case), I am leaning 
toward building a signed time service w/ a simple challenge-response 
mechanism that can be proxy and verified by the device... since we 
already have domain-specific trust anchors deployed, we might leverage 
those also for this use-case.

Last but not least, it might be useful to define a TLS extension that 
would carry such a record so that time-synchronization becomes less of 
an issue... does such an extension already exists?

Thanks again,


On 10/4/18 10:36 AM, Panos Kampanakis (pkampana) wrote:
> Hi Max,
> This is an issue that is dealt with in onboarding too. 
> has some text around it. It states “It is reasonable that the
> notBefore date be after the pledge's current working reasonable
> date.  It is however, suspicious for the notAfter date to be
> before the pledge's current reasonable date.  No action is
> recommended, other than an internal audit entry for this.”
> IMO, if someone trusted a server cert chain because he didn’t have 
> proper time at the time, he should generate an audit log that can be 
> used to go back to validate when more accurate time available.
> There was also a discussion in LAMPS about trusting expired certs in 
> the initial enrollment 
> . Caching revocation info for the chain is important in these cases.
> Rgs,
> Panos
> *From:*pkix <> *On Behalf Of *Dr. Pala
> *Sent:* Thursday, October 04, 2018 10:22 AM
> *To:* PKIX <>
> *Subject:* [pkix] Validating Certs w/out reliable source of Time
> Hi all,
> I am struggling with one issue that we have been seeing more and more 
> often with the introduction of small IoT devices that connect to 
> clouds and need to validate the other party's certificate chain.
> In particular, the problem is that without a reliable (or trusted) 
> source of Time information, devices can not really validate 
> certificates (i.e., is the certificate even valid... ? is it expired ? 
> is the revocation info fresh enough ?) and my question for the list is 
> about best practices in the space.
> Do you know if there are indications / best practices from ITU or from 
> IETF (or other organizations) on how to deal with this issue ?
> Cheers,
> Max
> -- 
> Best Regards,
> Massimiliano Pala, Ph.D.
> OpenCA Labs Director
> OpenCA Logo

Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo