IETF Logo Mail Archive

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

"Panos Kampanakis (pkampana)" <pkampana@cisco.com> Thu, 04 October 2018 16:36 UTC

Return-Path: <pkampana@cisco.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF65D130E83 for <pkix@ietfa.amsl.com>; Thu, 4 Oct 2018 09:36:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.946
X-Spam-Level:
X-Spam-Status: No, score=-14.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WX_wyS-790gZ for <pkix@ietfa.amsl.com>; Thu, 4 Oct 2018 09:36:06 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1E6130E82 for <pkix@ietf.org>; Thu, 4 Oct 2018 09:36:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18539; q=dns/txt; s=iport; t=1538670966; x=1539880566; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7pexG3KOee3r1PpRjwOxGhLuSURjuT3dlgzTPBjtX7U=; b=bd5LlGIBzZWj64O/2j8BZlX7h+1IXeKMui26++pN0RDCIk4RItqZELPz yLjRYlEhaEfwb1oSRaxE96d+gRLQgG1mmpxJvgZ8/iDRvBljslnArUdLu 18ZPcbAIx1ro8SyzvY4IolJoS9GzkcH5kcaceG62Q8lmCwrN1NjCUhHTY o=;
X-Files: image001.png : 3146
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AGAADoQLZb/4gNJK1bGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ5IL2Z/KAqDaogVjCCCDZEdhUCBeggBAgEBJYRHAheEDiE0DQ0BAwEBAgEBAm0cDIU5AQEBAQMFHgIIAVsCAQgRBAEBBgEBASICAgIFEAEODB0IAgQBEQEGAgaDFIIBD6QwgS4fiWYKBYssF4FBP4ESgxKDGwEBAgEXgTEEKYJqglcCiEmFPoFOiAiBUoQoCQKFaQFeiW4fj2uHKoRyiRwCERSBJR04gVVwFTuCbIsWhT5vAYp9K4EBgR8BAQ
X-IronPort-AV: E=Sophos;i="5.54,340,1534809600"; d="png'150?scan'150,208,217,150";a="451153474"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Oct 2018 16:36:05 +0000
Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id w94Ga5Dr020291 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Oct 2018 16:36:05 GMT
Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 4 Oct 2018 11:36:04 -0500
Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1395.000; Thu, 4 Oct 2018 11:36:04 -0500
From: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>
To: "Dr. Pala" <director@openca.org>, PKIX <pkix@ietf.org>
Thread-Topic: [pkix] Validating Certs w/out reliable source of Time
Thread-Index: AQHUW+2xQc/Um//hGUK5w+9LCMFbQqUPOOxw
Date: Thu, 04 Oct 2018 16:36:04 +0000
Message-ID: <47b70e1c4d214e9297e29b9ee1450c59@XCH-ALN-010.cisco.com>
References: <f1d0a721-96e4-5d1b-4dd3-7b041e3c4379@openca.org>
In-Reply-To: <f1d0a721-96e4-5d1b-4dd3-7b041e3c4379@openca.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.227.127]
Content-Type: multipart/related; boundary="_004_47b70e1c4d214e9297e29b9ee1450c59XCHALN010ciscocom_"; type="multipart/alternative"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/4Xw2QxcR5-LzQt7VzZfbnujPmBE>
Subject: Re: [pkix] Validating Certs w/out reliable source of Time
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Oct 2018 16:36:09 -0000

Hi Max,


This is an issue that is dealt with in onboarding too. https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-16#section-2.6 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 https://mailarchive.ietf.org/arch/browse/spasm/?q=%22Permissibility+of+expired+cert+renewal%22 . Caching revocation info for the chain is important in these cases.

Rgs,
Panos

From: pkix <pkix-bounces@ietf.org> On Behalf Of Dr. Pala
Sent: Thursday, October 04, 2018 10:22 AM
To: PKIX <pkix@ietf.org>
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]

v2.23.0 | Report a Bug | By Email