From nobody Tue Apr 13 11:44:20 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58A73A22D9 for ; Tue, 13 Apr 2021 11:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.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 Zgu_4-uCJKDf for ; Tue, 13 Apr 2021 11:44:14 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AC303A12C5 for ; Tue, 13 Apr 2021 11:44:14 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id w186so4783036wmg.3 for ; Tue, 13 Apr 2021 11:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=VAYxMcrcZz68tHU/U/kXbt60hIoPE2hkXIA92BtmE3w=; b=uhbK3add8usUa48XjTbtTGzBvPKIu76MWK7tJ8klqiBKafnA8U6MaKL+0TlkzL6EhN tBlGpbP5Pq2itiWQEKgfvajzAtWf3Qn0ButVZaN3Z9Le1MmlnGZgiIu1q5yIzzhi62U5 2I6FYMHy8VHMj8WHgsq6645LiMTy6sFBTvnLCTuoLpaEmQ3fDtIvEbp7sYDY9/QrySRQ +fiL/mZv3EGy99zDP1N86fGDt+gh9Wa3telahVKRzRi/L73zPhn9tCXKBAGJ9rak/yPF FGzzk7yNpdEcfMu7H3r0PfhgbTWGQgD73ZtCYMA4JbzDcFRO4+Rsg6pDIt1jvVcn+BiM NjeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VAYxMcrcZz68tHU/U/kXbt60hIoPE2hkXIA92BtmE3w=; b=HQii1KSsBk7AzoDk2RRrUP5FCUwKoN3OSDteFgGbu2KbECshbHFVZV1o8fsJyGP0PN ZJIymw9BRPaon5WMpdF0yA8hHN1V8Y4hneXMGI3NMJDXek/vkjKdhW4V235hWjLg/0Lf GhnoWgAOToeCiswJlcNuyiMu9ffcIU+rLFfadRS7ySuMU7rdvVwoArMzxUF9htKGsCYV v0TrLx0yW68EOgaMdJ4XaaIBWxHL8WPNyC/OtmoZdfD5Q7TAOt7A+jsYeznGyeSbFKO6 4tkMI+pzW29J7p47LuJTrSXAiCeb7+F8rD4NsKGnA8E8XvsLVIwFGkiAV/E36lB7jmd3 d8ug== X-Gm-Message-State: AOAM531AGD+ub3LqTCfgMBaNYkS4Ea7CWSbFrBVdg0BaCIE7e60qB6Cm zVtLvTkV5gq3ScjEH7STcNVMMgKM+P/aVYwo4++j3mOlsJWg1A== X-Google-Smtp-Source: ABdhPJy/CKb+H6MfXu6lu2NVUY0EN0S1yxXSqxfeMU0X0hLawq8dTrfha4xo7zqFj+EXCRi+cbtQYwzKLffWiBK8kgM= X-Received: by 2002:a1c:6a01:: with SMTP id f1mr1368649wmc.144.1618339451272; Tue, 13 Apr 2021 11:44:11 -0700 (PDT) MIME-Version: 1.0 From: Yakov Shafranovich Date: Tue, 13 Apr 2021 14:43:36 -0400 Message-ID: To: saag@ietf.org, art@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 18:44:19 -0000 Is there a preference for Internet drafts/RFCs regarding the specific data/time format to be used? Right now we are referencing RFC 5322, but there has been feedback from multiple people that the ISO 8601 format is easier to parse. This is in regards to the section 3.5.5 of "draft-foudil-securitytxt-11" that I am working on: https://tools.ietf.org/html/draft-foudil-securitytxt-11#section-3.5.4 The options I am asking about are the following: - RFC 3339 (a profile of ISO 8601) Example: 2021-04-13T06:50:53-07:00 - RFC 5322, section 3.3 Example: Tue, 13 Apr 2021 06:50:53 -0700 Thanks From nobody Tue Apr 13 12:00:35 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40233A2378; Tue, 13 Apr 2021 12:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.618 X-Spam-Level: X-Spam-Status: No, score=-9.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001, 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 header.b=fym6Wxd4; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=afXqa6pD 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 lgt0YSEEYsKP; Tue, 13 Apr 2021 12:00:24 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF34A3A238E; Tue, 13 Apr 2021 12:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2095; q=dns/txt; s=iport; t=1618340420; x=1619550020; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oTvnQtiIFHc3HdRfLVvV/1kGxT58VLv3kUxU975cVEI=; b=fym6Wxd4no6U16Um4T0YRc9kbwiTHUAYQFB81Czqto5eZN0K40Oqas+h ZS7zeZEwZM7ejfFXvD2SEL8oYpQRXNaHKWbVPTWxTL3JjjFtdwOc8UCAA H4ORNrBoISS0nFJFToQLhpiMRsWm+Cycz6HU8QStzSvNQF4Guj0/fKkZP k=; X-Files: signature.asc : 488 IronPort-PHdr: =?us-ascii?q?A9a23=3AKzv4dRQ6OL1m3FcqSQ8YtcJAi9pso2XLVj590?= =?us-ascii?q?bIulq5Of6K//p/rIE3Y47B3gUTUWZnAg9pCiuXWr7/pRWcA6oeLvWoZfZdRT?= =?us-ascii?q?R4ZmIMdmAlzSMKGCEiuKvnsYmR6GclZT1Zq8jm9NlQweo7lZlLUr3HzpT4fE?= =?us-ascii?q?xnyL0x5c+LyHIOBicW41/yt8oHYYw5Zjjener55MQ+3sRSXvc4T0sNuL68rw?= =?us-ascii?q?U7PpX1FM+1d2WJvIweVmBDxg6X4/JNq/ylK/fw78MsVWqThdKN+RrtdX1wb?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AdWxYf6stfevZAhNOptkt2ZbP7skCNocji2?= =?us-ascii?q?hD6mlwRA09T+WxrOrrtOgH1BPylTYaUGwhn9fFA6WbXXbA7/dOgLU5FYyJGC?= =?us-ascii?q?3ronGhIo0n14vtxDX8Bzbzn9Qy6Y5JSII7MtH5CDFB4vrSyAOzH888hPyO96?= =?us-ascii?q?61jenTpk0dMj1CQYsI1XYfNi+wFEpqSA5aQb8wE5SB7sRKzgDQB0g/RMK9G3?= =?us-ascii?q?UDQqz/t8TG/aiWICIuKjwGzE21jT2u4KPnCBTw5Hcjeh5G3LtKyxm/ryXX/a?= =?us-ascii?q?Om2svLryP092iW1JhOncuk990rPr3xtuEwChHBzjmlf55gXbrqhkF0nMiK5E?= =?us-ascii?q?wxmNfB5zcMVv4DkU/5RW2+rRvz1wSI6l9HgBWOpS768BneiPf0Sz4gB81KiZ?= =?us-ascii?q?gxSGql12MboNp+3KhXtljp0aZ/MBLakCzxo/jOWh16/3DE2UYKrO8Jg3RTFb?= =?us-ascii?q?YZcb9axLZvhX99LZFoJlOf1KkXVM1VSO3M7vdfdl2XK1rDuHN0/dCqVnMvWj?= =?us-ascii?q?+bX0kroKWuontrtUE863Fd6N0Un38G+p54YYJD/f74PqNhk6wLZtMKbJh6GP?= =?us-ascii?q?wKTaKMey7waCOJFFjXDUXsFakBNX6IgYXw+q8J6Oajf4FN65cuhpLbUhd9uX?= =?us-ascii?q?Qpc0zjTe2Ctac7tyzlcSGYZ3DA28te7592tvnXX7zwKxCOT1gojo+uuPMaDs?= =?us-ascii?q?rHW+uiOZ5fDvP5RFGeXrph7knbYd1/OHMeWMoatpIQQFSVuP/GLYXsq6jafZ?= =?us-ascii?q?/oVfzQOAdhflm6LmoIXTD1KskFxFusQGXEjB/YXG6ofkT++Jl3AbXL5uR78v?= =?us-ascii?q?lVCqR89iwuzXip7MCCLjNP9oYselFlHb/hmqSn4W+s/WjJ6G1tMgFHDllc5a?= =?us-ascii?q?jhV38in35PD2rENZI4//mPc2Fb23WKYjVlSdnNLQJZr1Nrvb6sI4eI3iAkAd?= =?us-ascii?q?K/Omech38ezUj6F6s0q+mm34PIa5k4BpEpVOhNDg3NDQVyghsvgnxEchU4Sk?= =?us-ascii?q?jWES7Oha2pgIcPPvzWc8BxjW6QUJVpgEOakX/ZhMk0AlMHQjalUKes8HcTbg?= =?us-ascii?q?sRomc0zogyr/6rny21JW42neIiWWc8GFi/MfZhFwSKZIJdh7bxXhp/JF363w?= =?us-ascii?q?CyulUUZnfg8VkUiyjHKyCZEMu7XmZ1izR/zrvg9k9yeyGmW39ILlp+sYF7CA?= =?us-ascii?q?39yytO+OeWe6u+1HaQYFMewucbdCrIeycWPxkG/aHE6DeF3DmFDnko3ZMoI6?= =?us-ascii?q?jUC6kiaaja3je3JJSPjrxuJY4ZwL91cNTnsuoGSoukCnyoBSK9D+MiwAqOoH?= =?us-ascii?q?k5fCFytXk/iPvtsSeVplSQzTo6AfDIJk5hSKxeK9aA73L8T/LN1Jlil9o6sa?= =?us-ascii?q?+xNWr2A+T2hJ3/fnpGKhnJp3SxQPxtoZdIvbgqvL82BoLFS1LzpTh69QR7KN?= =?us-ascii?q?2xmFIVQax97ryEMohzf9YKcyYc+lYyjtyAIEYirwSeOJ5wQXg9y3vAe9+Z6b?= =?us-ascii?q?vBrrQiRleMowb9IlGT+SxQ9fWtZVrJ6ZcKT6YrZWhGYkk173pvuP6Yf4rLEQ?= =?us-ascii?q?OwaqVN+kG5PnLVSs4SdIGVXbEL6hB07NGDk7XJK2722AXMsSB6JawL+WC9Ws?= =?us-ascii?q?+2CB+NH+kN89HSAyX6voK6pMqoyDHwQn+nbk5dg4tPf0kZdN5ChTkvl5df6F?= =?us-ascii?q?n7doXn5kY+10JD6jRmnEP30oeo4G3HDVhLWDep9ql+TH1WKDyUlszL/uiTyW?= =?us-ascii?q?Tl7DVE0ZfFEl1MftsmIalncqHnayF0KcYRu7a0/60gxiRbCS1eelIBtA=3D?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AABc6XVg/49dJa1aGwEBAQEBAQE?= =?us-ascii?q?BBQEBARIBAQEDAwEBAYIABAEBAQsBgVJRB3daNjEChEGDSAOFOYhmA5k8gS6?= =?us-ascii?q?BJQNUBAcBAQEKAwEBHQsKAgQBAYRQAoFyAiU2Bw4CAwEBDAEBBQEBAQIBBgR?= =?us-ascii?q?xE4VQDYZEAQEBAwEBASEdAQEsCwEECwIBCBgqAgInCyUCBA4FDoJjAYJVAw4?= =?us-ascii?q?hAQ6hXwKKH3mBMoEBggQBAQaCTIJKGIIMBwMGgTkBgVKBJIpbJxyBSUKBOhy?= =?us-ascii?q?CXz6BBIFcAQECAYR0NYIrgzJRAhRHIFQOnmadBgqDC4Ehg2SCcYFxkxwEH6R?= =?us-ascii?q?4j3uRCJNAAYQBAgICAgQFAg4BAQaBWwopgVlwFTsqAYI+PhIXAg6OHxeDWYU?= =?us-ascii?q?UhUVzAgEKKwIGAQkBAQMJfIwSAQE?= X-IronPort-AV: E=Sophos;i="5.82,220,1613433600"; d="asc'?scan'208";a="874744859" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Apr 2021 19:00:19 +0000 Received: from mail.cisco.com (xbe-rcd-003.cisco.com [173.37.102.18]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 13DJ0J2R016833 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 13 Apr 2021 19:00:19 GMT Received: from xfe-aln-001.cisco.com (173.37.135.121) by xbe-rcd-003.cisco.com (173.37.102.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Tue, 13 Apr 2021 14:00:19 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xfe-aln-001.cisco.com (173.37.135.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Tue, 13 Apr 2021 14:00:19 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 13 Apr 2021 15:00:19 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PtL7kGZZ9BGlRWi7/5z/1v46IN6AVn8V7K1ta/0WC3x/B69zNTzSjgufuuJGTF2q2tM5aIV5srzmts62dUYUM7/SFZJ0vnPMIDpz9Wl40t1sXGSDDJmLuaIFx7cd19lLhThxltfArn13eOgMovGgQLQwa/e4LhoemBaK8iJx/mmD0a8fBglozEuTSbV+lRVNi9qfVrzSWS4UYkLtVoHizFcqoIR57ocpo0wMobwP+b9RLOyghXLK+1U1i2o+4GsK2RAB5y55iYv7nTPu9PffCdHlrvNrSovOWlWI1kJGtARcDeTUaQG//aXqhOd53bakLpG9NDLqh3IKepZ85FmhcQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Dnilp0Oks+56CySm63qR42B+1vbuW5RCdaAFbBWoyGw=; b=AsSqzzJvu7Tc0fwjzljkgx6DJuz22HOXws7ZsAXOAIZpYQxErjLe/kYtZFuWcjs9R9hZTs6zrhPARiZsR6+XED/Nxd5oBE1XT4GJQtDhq1nNEVoTHGPkHhjAs9Qo13jVJozaeL0IX7jca54nF4M0s1FqUL3DeKeRIewFJzBp/fPXlvibFKsJZAzAPSlEM8waNfI2tKQ46ezfjrOTI3OzXoSZ9k8YFqZ4J2J85gTnNlaj8lURbwYwwc2TwWQ+ib2U2vGSc2ek2b+PKhhs9YpMKcST4f4ZpKzpzqCQy+tB9u3aZoUbvfL6HpRxCDDc6uLjFvWlQugDQkN6tot32xZJ7Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Dnilp0Oks+56CySm63qR42B+1vbuW5RCdaAFbBWoyGw=; b=afXqa6pDqmHuZ2JNP9kV5ZenKoDuYMirXZU+0Qg29hueOvLfW/bYsrPR/Je1LiLOaa7Ueqg9WJPlzxjNmmBlzFp2yl3994nfI5mhU73XE2sP5E9rye56VzNdddLcecyH48T+Zez7HNKPpLfeKTXJ1CIwtUZN3Cv2409i9nqypt4= Received: from DM4PR11MB5247.namprd11.prod.outlook.com (2603:10b6:5:38a::20) by DM6PR11MB2795.namprd11.prod.outlook.com (2603:10b6:5:bf::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.22; Tue, 13 Apr 2021 19:00:17 +0000 Received: from DM4PR11MB5247.namprd11.prod.outlook.com ([fe80::21c6:ed7f:6f71:7467]) by DM4PR11MB5247.namprd11.prod.outlook.com ([fe80::21c6:ed7f:6f71:7467%5]) with mapi id 15.20.4020.022; Tue, 13 Apr 2021 19:00:17 +0000 From: "Eliot Lear (elear)" To: Yakov Shafranovich CC: "saag@ietf.org" , "art@ietf.org" Thread-Topic: [saag] Date formats: RFC3339 vs. RFC 5322 Thread-Index: AQHXMJUZ2VQz3qEwN06K4IQYXw3trqqyzU+A Date: Tue, 13 Apr 2021 19:00:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.60.0.2.21) authentication-results: nightwatchcybersecurity.com; dkim=none (message not signed) header.d=none;nightwatchcybersecurity.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a02:aa15:4101:2a80:702d:65b9:d143:ee8c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7fda59f4-ac9c-4b03-43ef-08d8feae60f4 x-ms-traffictypediagnostic: DM6PR11MB2795: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wc1K3kFGT4B/2vw02a3+OyXLxKC/HsHSpSGa4gu3d3k1RrdQheICtOQNtm3masU8aBmrcv75ateOFm/2Gwg5c4AQTI8YrvoElRO8f2NjBzcnGA98hPFb2iX3IJJpkPbp3dYbXoC9huul4JCWhCCZwNsW0H33BtU20LNb5l/tNsSdXbRNdI5TVRfLd2LEqxCBUCjQaPbPWqndYdZwv0mxeEuqjRO4FOXAAXQlVZ2PzBR5kDI+n02SLqrhe9tf2pI6aBo6ioTke06nQHpIzPNW33r1a/uZW6exY1ZeYVx95Hl/kSVK/mkRquRRi1d5dNdTH3nRB+ZJy3dRgWUtdmCrYawxi2pFU9FnycO9TMY1BCR4R86pMydDYIcEERFID4jNrWa4i4Bb8Rs3DOtZdn9P24tp8RgB38uDZ/d9CVfbDOP488w+a0fK7fBL1yURBaO21zNY9AAQfA1hZyc5jHFyz5/IJg9YgDqv2A+TNmVXvocvWdyH7X1busRIumh6rczp7Irzsblpofeff5vLwRMSk5NZTQRvoI1S9KsVbEzIgzO6M1UY3BnSXhEYs4BQJ2oZyTwnYEUan0KqgLA2Zy0Ne1UsbL1laj+jZu0YSPXsDPaDoSGELHWBQXT0fGt7Z5BUFciE+tjX+1b1rJxGDEM8XHK0fiOkUVQVr6BaPDHkPH6JJGvfAoFIYqo/fTE2sO+y7Ck/O3afxrBVrj5nHYHtH4LMdXWBBwZtbPCHkABdNhQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM4PR11MB5247.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(39860400002)(346002)(366004)(396003)(136003)(99936003)(33656002)(66556008)(8936002)(53546011)(91956017)(6512007)(64756008)(66616009)(316002)(54906003)(122000001)(8676002)(6486002)(36756003)(66476007)(66446008)(478600001)(38100700002)(2906002)(83380400001)(186003)(6916009)(66574015)(5660300002)(71200400001)(966005)(66946007)(6506007)(76116006)(86362001)(4326008)(2616005)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?VklLMDNtaEsxOG1teis3OVdvc3k4Z3ZxcjJLVHZXMk9QOFZZb3dYd3Mydmtw?= =?utf-8?B?T1U0Lzd3ZUwxWDY5Wk9WVVJnTDlEbkxBRGtwS2lITUNHSUJLS0xtb2FUcVJx?= =?utf-8?B?bHJsQkZTeXBLUVZzUk9sS2gra3c1d0pPOUZCY09JQjkyTS9yczRWUFNpM1dy?= =?utf-8?B?eXZ2ZS9wK2hCY2M3QlpaUzYwSHBMU2xHeEZndmlqbUFoNTdoTHZvRUJ6UWZx?= =?utf-8?B?SnN4MEluNXNxdWh2NUIweUkrVVJhOEl6ZDBOMUp1WjVMM01Ranc4UGhzVGxW?= =?utf-8?B?QTdjcXRYcVBQS2Zla3p3enRqNVRNOG45ZVVsTEI0NW1iaWwzSDIwU0xueDl5?= =?utf-8?B?d3F5b011cXUvQWYrb3gzQ21YZU00aVpOUkh2MTAvUHZqbmFqVGhsMUQ3UFl1?= =?utf-8?B?TmliNXk5Mk9QZ0JPRWFsTEowbm03WTdTQktJR2JmRjVCbTN2S0M1cnh2VlNP?= =?utf-8?B?SllCSEFXclN5NHNoYzhKY1VYUnBuNFBVbjNTV21vR0ZUVlNlYVdyUEhXcTcr?= =?utf-8?B?S1djK3dzZXlrNWNiTmhGTERyWU9zdHpNVzFYUkdYZ1NtNExiT2g3bGVnRnMr?= =?utf-8?B?MjJZQ1lPUlNwMWFBc2RzUFlEL0JGcUVISHl3bWN0UHcrS2xYWG5ueWN5bS91?= =?utf-8?B?WHRGcndqd0IybDdJVFJYRks0dmt3UWFUWEltbUUzNTJGV1VoSHA2c2RnNlFS?= =?utf-8?B?d1ZwQWZ5b1FhR2hMMVViRi9paEZ2ZEVYVUQ1MXRCRUhEZG8zcWJUZGJNOUhV?= =?utf-8?B?VCszTGRSaFNWaFpCcWNKdjFxaG9MNzV4QnVlRGNTMnFudDNqK3FORiszS0Fm?= =?utf-8?B?QU0rTnZmZXJEWDFsUk9oeGpmMGVZOEdSVit1RzM5emJUMlVxTS9DMDd3ZWN2?= =?utf-8?B?Zi9wc29lMitVS2E3UGZOUkNtMExzWmE1Wkt3RDQzNEttbGVIUllSekNtMnlv?= =?utf-8?B?K3IweUp0S0hUS0xqbGNxYVhDNDE5OHE3Mmd1VUUrWW9YUTI0Z1puNjMwbUkr?= =?utf-8?B?RWtZTStVM21OQWJVUnR4ZEpvUEFNcTR3ZEh3eExWL0tMQUEzdHpxeHJUM3A0?= =?utf-8?B?dVNhT3E5QkhBemF1VXJlWllJZHRhSDFpTmhKRTJiMHk3MlRUV3dkd3FSU0Vm?= =?utf-8?B?NGFYN0hsMWV3SHhNbndkN09PU3F0R2dSbEhFeWRybkpFNjRTSWdpNGZpQW9B?= =?utf-8?B?enZKTHZSM1JUTDQ5UmVXYzRFbDNGZWhHYlBDOEx0TEMzQW0rZFVudXhQZ3dP?= =?utf-8?B?eHVyWHM3dFpjL05QVDlhUXl5RXh3VHlqTmZlUVIwNVhMWkthUFN3ajQ0NnlM?= =?utf-8?B?Sk91emVwbGRYc2dZV3l2ME5tSlRId3EvTllHYkJ5TWp5L1NYUEpRNTJqZUJ4?= =?utf-8?B?TW1UaFJubzRBUmRlV1kwT3lSOHVmclFkVGsxOG1pRWdPaHZUYVh4L01yNExP?= =?utf-8?B?UElnZWNPci9EWit1eWlhZzJnQXlvd050azk2ZS9MQm4reFBmQ2J1dnFaanNp?= =?utf-8?B?SkVmV1BuUHV3MUtaTDhrUFNISXRZQmY1VEc1UmpQMGxNYU1mdWpobWZoNHQz?= =?utf-8?B?WHMvSHU2Z3BOK3lnT1NqZmhiNUFwVlowYzZSc2ltSU02eVk5V0dwMWtwTUtD?= =?utf-8?B?RHhiZzVhT0RXMHNjWnBWMHJTNDJ6UkYrdEUxc2JIUTFvdWpoYVh4T2NDNTVa?= =?utf-8?B?ZHVJdXNwTkJwUThtTlFHSEk0SUlqQmEvZWFyNGZXamx1akdtaTRsSktDWlFt?= =?utf-8?B?NUl3dDIyd0Z2alR3MXgyUW9XWGt4Y1NqWTZ5ZkcybzdnaE1wOUtmRUcrSklD?= =?utf-8?B?SmtoUTdyUk94LzRvNTZHemYwZzRvb21jZnRVSHFlekpiMDNSdkJ6enhJMlZM?= =?utf-8?B?b2hKcVRyenBxSmlpSGxBYkY1cC9ZQVZwVXRoOFFERUlZSEE9PQ==?= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; boundary="Apple-Mail=_C995284B-D681-44E5-89C6-CC0E32BFEFCF"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB5247.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7fda59f4-ac9c-4b03-43ef-08d8feae60f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2021 19:00:17.6807 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: UCHWbQpyJQMGNW8Uzz1DV+OL1JrOWMj4LJRDgiAVe88S7zB931m/3UqthZtjDuCE X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2795 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.18, xbe-rcd-003.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [saag] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 19:00:33 -0000 --Apple-Mail=_C995284B-D681-44E5-89C6-CC0E32BFEFCF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The question is whether you need something that is easy to parse or = something that is human readable and can be localized. It SEEMs that = this draft is intended to be human readable, and so 5322 doesn=E2=80=99t = seem out of bounds. > On 13 Apr 2021, at 20:43, Yakov Shafranovich = wrote: >=20 > Is there a preference for Internet drafts/RFCs regarding the specific > data/time format to be used? >=20 > Right now we are referencing RFC 5322, but there has been feedback > from multiple people that the ISO 8601 format is easier to parse. This > is in regards to the section 3.5.5 of "draft-foudil-securitytxt-11" > that I am working on: > https://tools.ietf.org/html/draft-foudil-securitytxt-11#section-3.5.4 >=20 > The options I am asking about are the following: > - RFC 3339 (a profile of ISO 8601) > Example: 2021-04-13T06:50:53-07:00 >=20 > - RFC 5322, section 3.3 > Example: Tue, 13 Apr 2021 06:50:53 -0700 >=20 > Thanks >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail=_C995284B-D681-44E5-89C6-CC0E32BFEFCF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmB16kAACgkQh7ZrRtnS ejNQiggAqErSSlhVxwUecvAaFDJpJHfK4josP4bPMtW2saWkM109EARIydO4wAaJ /UQJ/aJuw6DQJohuCwNOdsyXpwoc2Ku0f59IuLHom+X2SVyrMg2CWZASJfNvkeNb KinhGkI70+EGTlgDsMrGAjAxvgu/sk9mNfMgAuRd8Z79Yyos0ikrilFcs3XS2BKu U9JrPhfJJukJHDjYPam4mApiw2Jbeyt5GIWDm4u1GWZAgxIkG4pYVnfkkoXMAxY8 fj6EMkQ65ms0SVCNc1oO72OpUj21NWySoCKtaC/8Ktd5Aw2Sp81YHzbTi0SSZu5i /Kj+rQ5k+GNKyfUrjQ65/D0V92QuGg== =wuvO -----END PGP SIGNATURE----- --Apple-Mail=_C995284B-D681-44E5-89C6-CC0E32BFEFCF-- From nobody Tue Apr 13 12:04:39 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3CA3A236B for ; Tue, 13 Apr 2021 12:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=textuality-com.20150623.gappssmtp.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 gOpV7ZnA6Kfe for ; Tue, 13 Apr 2021 12:04:34 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421E73A2366 for ; Tue, 13 Apr 2021 12:04:34 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id j18so29090328lfg.5 for ; Tue, 13 Apr 2021 12:04:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=textuality-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=llkTOMkdXz36HXBpet4gaxk6T1b6TY3OX3vaM/8HD9s=; b=VNAh9LiLmS3jeAMQTzrSmopsx2T92+GnII6MNUwfTkKJj7+C9R6CL8KhNuonlYTP6T 3esGCKYYpdMCt3N5eluVMR9Q3trGNkTW+Tr0PEhavAbcvSdEZfiTWztc6e0jY/HseAlm mHkkbSoDHxJLOIaVbuob2KyfdDR916IR4zaRpnrSyYaQqANX/0ZecaPXg7mapbLazQip bjeU6SraCbx13/1pmxHPFRaMx4OP3TRYeETyA+5LYl7EnQl7yxbqwar7tX4flumngTv5 CM1SxVEgjwWpHjX06MdEA2n/arnJcokDCJ3GEofqSN9dN+QoCuof6IUvL5f7igysqZpI p66g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=llkTOMkdXz36HXBpet4gaxk6T1b6TY3OX3vaM/8HD9s=; b=GRglJ24U66DFw6e2jZR9lkk/KGGnVHh2TObRNjbgu5oPzzTCMdAqP1YC92OVrKH67+ vJ8Xq3xydt9naVXnNcYX/xA3IP9YLur8u3ahfsu3MNe3l1yBQSzt65mBI7JiIN4GrKYw QRo0i0zZrPUDiBiXsoXxAlrp/5oPKwRMSO/+MdHx61UGUn27rw6p/lrUUAHImiKXusyf EkxMbTp7AG1ika9NPfVblSUOTGayNdcYWtWa1AdaTKC0bC0RNx+8VfxPRONLgE5VLmRq a/3OXjHZfpDMjC5GeBf5+xEm3OMyB/JD5r1DOEapoNN2p6VDUrR29YjUX2epK6DcEaq+ CNKA== X-Gm-Message-State: AOAM533za6APi9Cf9A92HwkgUaNTthrOPIkBWFG3cf2JmdO0OmaVIDgN NVNfCj64Ms+OGJUPs4ltN66LLKPhCBoxKP/Ktx6cMQ== X-Google-Smtp-Source: ABdhPJwclmPLqPM2Li/sDUcN9UxdFNEeIhkdIzeywG5PrUzufcuvwQtJ0QHdhDArPAuZ+QwyETG4si8u3ny9xlCG1uQ= X-Received: by 2002:a05:6512:3087:: with SMTP id z7mr23370532lfd.224.1618340671620; Tue, 13 Apr 2021 12:04:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tim Bray Date: Tue, 13 Apr 2021 12:04:19 -0700 Message-ID: To: Yakov Shafranovich Cc: IETF Security Area Advisory Group , art@ietf.org Content-Type: multipart/alternative; boundary="000000000000dbaa9205bfdf4cd1" Archived-At: Subject: Re: [saag] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 19:04:39 -0000 --000000000000dbaa9205bfdf4cd1 Content-Type: text/plain; charset="UTF-8" For use in protocols, I think you'd probably find that most people would strongly favor the use of 3339 if at all possible. On Tue, Apr 13, 2021 at 11:44 AM Yakov Shafranovich < yakov@nightwatchcybersecurity.com> wrote: > Is there a preference for Internet drafts/RFCs regarding the specific > data/time format to be used? > > Right now we are referencing RFC 5322, but there has been feedback > from multiple people that the ISO 8601 format is easier to parse. This > is in regards to the section 3.5.5 of "draft-foudil-securitytxt-11" > that I am working on: > https://tools.ietf.org/html/draft-foudil-securitytxt-11#section-3.5.4 > > The options I am asking about are the following: > - RFC 3339 (a profile of ISO 8601) > Example: 2021-04-13T06:50:53-07:00 > > - RFC 5322, section 3.3 > Example: Tue, 13 Apr 2021 06:50:53 -0700 > > Thanks > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --000000000000dbaa9205bfdf4cd1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
For= use in protocols, I think you'd probably find that most people would s= trongly favor the use of 3339 if at all possible.=C2=A0

On Tue, Apr 13= , 2021 at 11:44 AM Yakov Shafranovich <yakov@nightwatchcybersecurity.com> wrote:
Is there a preference for Internet drafts/RFCs regardin= g the specific
data/time format to be used?

Right now we are referencing RFC 5322, but there has been feedback
from multiple people that the ISO 8601 format is easier to parse. This
is in regards to the section 3.5.5 of "draft-foudil-securitytxt-11&quo= t;
that I am working on:
https://tools.ietf.org/html/dra= ft-foudil-securitytxt-11#section-3.5.4

The options I am asking about are the following:
- RFC 3339 (a profile of ISO 8601)
Example: 2021-04-13T06:50:53-07:00

- RFC 5322, section 3.3
Example: Tue, 13 Apr 2021 06:50:53 -0700

Thanks

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--000000000000dbaa9205bfdf4cd1-- From nobody Tue Apr 13 12:05:32 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5E73A2369; Tue, 13 Apr 2021 12:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 0xzrtxg6UyQd; Tue, 13 Apr 2021 12:05:22 -0700 (PDT) Received: from flamingo.apple.relay.mailchannels.net (flamingo.apple.relay.mailchannels.net [23.83.208.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B0A23A2422; Tue, 13 Apr 2021 12:05:11 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 8DD26781F3F; Tue, 13 Apr 2021 19:05:09 +0000 (UTC) Received: from pdx1-sub0-mail-a57.g.dreamhost.com (100-96-16-43.trex.outbound.svc.cluster.local [100.96.16.43]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 08016781D38; Tue, 13 Apr 2021 19:05:09 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a57.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.16.43 (trex/6.1.1); Tue, 13 Apr 2021 19:05:09 +0000 X-MC-Relay: Good X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Decisive-Lonely: 339d62ba5c2fdf5e_1618340709335_1749551692 X-MC-Loop-Signature: 1618340709335:650591063 X-MC-Ingress-Time: 1618340709334 Received: from pdx1-sub0-mail-a57.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a57.g.dreamhost.com (Postfix) with ESMTP id AC3E388834; Tue, 13 Apr 2021 12:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=ZKSojTMm/PHOi9 /kqdwWk+GTITQ=; b=WY9XpCOcDbmwVJVUo/hRIpGGQl0ZgqZAyON6LgghVkteCM 6lmGQI2+ELxpTE5YWfPtYvcZtpYrqWDFF/rKi7E2I0383UHprs3HZO9qshZrSGGr PYI+8trsH0gTCp3SrKReY9IjRZgqY/MaG3VpgFK2HgKudzkTdzwe326dvCuIE= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a57.g.dreamhost.com (Postfix) with ESMTPSA id 1075B88849; Tue, 13 Apr 2021 12:05:06 -0700 (PDT) Date: Tue, 13 Apr 2021 14:05:04 -0500 X-DH-BACKEND: pdx1-sub0-mail-a57 From: Nico Williams To: Yakov Shafranovich Cc: saag@ietf.org, art@ietf.org Message-ID: <20210413190503.GJ9612@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [saag] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 19:05:27 -0000 On Tue, Apr 13, 2021 at 02:43:36PM -0400, Yakov Shafranovich wrote: > Is there a preference for Internet drafts/RFCs regarding the specific > data/time format to be used? > > Right now we are referencing RFC 5322, but there has been feedback > from multiple people that the ISO 8601 format is easier to parse. This > is in regards to the section 3.5.5 of "draft-foudil-securitytxt-11" > that I am working on: > https://tools.ietf.org/html/draft-foudil-securitytxt-11#section-3.5.4 > > The options I am asking about are the following: > - RFC 3339 (a profile of ISO 8601) > Example: 2021-04-13T06:50:53-07:00 > > - RFC 5322, section 3.3 > Example: Tue, 13 Apr 2021 06:50:53 -0700 My very strong preference is for ISO 8601 format dates on account of: - it sorts semantically correctly when sorting alphabetically (when using Zulu time) - anyone can read and write ISO 8601 format dates, and it's easy to memorize -- this is not true of any other format I would further suggest that timezone information for this purpose is not very useful in this context, and that always using Zulu time would be best. Nico -- From nobody Tue Apr 13 12:19:52 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B681E3A240D; Tue, 13 Apr 2021 12:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 2hYeHgZJJv7g; Tue, 13 Apr 2021 12:19:46 -0700 (PDT) Received: from fly.apple.relay.mailchannels.net (fly.apple.relay.mailchannels.net [23.83.208.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC063A2407; Tue, 13 Apr 2021 12:19:45 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C1830102649; Tue, 13 Apr 2021 19:19:43 +0000 (UTC) Received: from pdx1-sub0-mail-a57.g.dreamhost.com (100-101-162-39.trex.outbound.svc.cluster.local [100.101.162.39]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 28D771016AC; Tue, 13 Apr 2021 19:19:43 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a57.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.101.162.39 (trex/6.1.1); Tue, 13 Apr 2021 19:19:43 +0000 X-MC-Relay: Good X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Company-Company: 5bf43abc66538abe_1618341583629_2833403677 X-MC-Loop-Signature: 1618341583629:3743367100 X-MC-Ingress-Time: 1618341583629 Received: from pdx1-sub0-mail-a57.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a57.g.dreamhost.com (Postfix) with ESMTP id CF99488842; Tue, 13 Apr 2021 12:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=zhUSrwg43mhfpCd0WlMFt9GTcEM=; b=LydVgtsfLvg /j8aMT/6xMW0RZl1UCn0/4NkF3a09BAxZeaLiKI/iOTprzpbfLkm+fTDu7ehByEM bPEZZqG0NW5ZCfWyrClftEakNR0FTEa2zsmfJxsLC/lZzmOUeb6X2CZmD705Hrd/ aagyNUDaK7AH2MK9PacG41W9CQGmIGRM= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a57.g.dreamhost.com (Postfix) with ESMTPSA id 06B3E88846; Tue, 13 Apr 2021 12:19:40 -0700 (PDT) Date: Tue, 13 Apr 2021 14:19:38 -0500 X-DH-BACKEND: pdx1-sub0-mail-a57 From: Nico Williams To: "Eliot Lear (elear)" Cc: Yakov Shafranovich , "art@ietf.org" , "saag@ietf.org" Message-ID: <20210413191937.GK9612@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 19:19:51 -0000 On Tue, Apr 13, 2021 at 07:00:17PM +0000, Eliot Lear (elear) wrote: > The question is whether you need something that is easy to parse or > something that is human readable and can be localized. It SEEMs that > this draft is intended to be human readable, and so 5322 doesn=E2=80=99= t seem > out of bounds. English-centric much? :) Seriously, RFC 5322 is unnecessarily English centric, and ISO 8601 is universally understandable. Nico --=20 From nobody Tue Apr 13 12:30:32 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC89E3A246B; Tue, 13 Apr 2021 12:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.188 X-Spam-Level: X-Spam-Status: No, score=-0.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, RCVD_IN_VALIDITY_RPBL=1.31, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 eZG5V0TbQ_8o; Tue, 13 Apr 2021 12:30:23 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34483A2469; Tue, 13 Apr 2021 12:30:23 -0700 (PDT) Received: from [10.32.60.51] (76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id 13DJUo0I026029 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Apr 2021 12:30:50 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 76-209-242-70.lightspeed.mtryca.sbcglobal.net [76.209.242.70] claimed to be [10.32.60.51] From: "Paul Hoffman" To: "Yakov Shafranovich" Cc: saag@ietf.org, art@ietf.org Date: Tue, 13 Apr 2021 12:30:21 -0700 X-Mailer: MailMate (1.13.2r5673) Message-ID: <901F4345-91B6-42CA-9F68-27DB4C539F3D@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [saag] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 19:30:28 -0000 On 13 Apr 2021, at 11:43, Yakov Shafranovich wrote: > Is there a preference for Internet drafts/RFCs regarding the specific > data/time format to be used? > > Right now we are referencing RFC 5322, but there has been feedback > from multiple people that the ISO 8601 format is easier to parse. This > is in regards to the section 3.5.5 of "draft-foudil-securitytxt-11" > that I am working on: > https://tools.ietf.org/html/draft-foudil-securitytxt-11#section-3.5.4 > > The options I am asking about are the following: > - RFC 3339 (a profile of ISO 8601) > Example: 2021-04-13T06:50:53-07:00 > > - RFC 5322, section 3.3 > Example: Tue, 13 Apr 2021 06:50:53 -0700 Given that the date in that section of that draft is meant to be machine parsed, choosing RFC 5322 (neé 822) date formats is a particularly bad idea, given the existence of RFC 3339. --Paul Hoffman From nobody Tue Apr 13 13:01:22 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290A93A2585; Tue, 13 Apr 2021 13:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 zGLI5rvZ9Ktq; Tue, 13 Apr 2021 13:01:11 -0700 (PDT) Received: from giraffe.apple.relay.mailchannels.net (giraffe.apple.relay.mailchannels.net [23.83.208.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1D43A2583; Tue, 13 Apr 2021 13:01:11 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 280B24822E3; Tue, 13 Apr 2021 20:01:10 +0000 (UTC) Received: from pdx1-sub0-mail-a57.g.dreamhost.com (100-96-27-180.trex.outbound.svc.cluster.local [100.96.27.180]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id CCD104822FA; Tue, 13 Apr 2021 20:01:08 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a57.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.27.180 (trex/6.1.1); Tue, 13 Apr 2021 20:01:10 +0000 X-MC-Relay: Good X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Imminent-Cooperative: 67b84cf25cf8e252_1618344069180_4176549922 X-MC-Loop-Signature: 1618344069180:1491392068 X-MC-Ingress-Time: 1618344069179 Received: from pdx1-sub0-mail-a57.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a57.g.dreamhost.com (Postfix) with ESMTP id 769F988834; Tue, 13 Apr 2021 13:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=/qmQKtGqSfBbRp8GEcfWbADhKN8=; b=HF73J7GgwGf 15/gGiCjV2zSbJJ8svidhY5KHY1SrP/Sk568/7w478tfu9RfLNMLFKc89NtOEtPP t342IzpZSzdaf+3E46Uy2a95TmpOnsx0jUZpW9XjeqtHiIHRBz+w1ePKvVScbOrc e8BWrC9a1YuVqf4549pwEM/N7zwNjvTc= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a57.g.dreamhost.com (Postfix) with ESMTPSA id 4E7358883B; Tue, 13 Apr 2021 13:01:04 -0700 (PDT) Date: Tue, 13 Apr 2021 15:01:02 -0500 X-DH-BACKEND: pdx1-sub0-mail-a57 From: Nico Williams To: Paul Hoffman Cc: Yakov Shafranovich , art@ietf.org, saag@ietf.org Message-ID: <20210413200101.GL9612@localhost> References: <901F4345-91B6-42CA-9F68-27DB4C539F3D@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <901F4345-91B6-42CA-9F68-27DB4C539F3D@vpnc.org> User-Agent: Mutt/1.9.4 (2018-02-28) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 20:01:16 -0000 On Tue, Apr 13, 2021 at 12:30:21PM -0700, Paul Hoffman wrote: > Given that the date in that section of that draft is meant to be machin= e > parsed, choosing RFC 5322 (ne=E9 822) date formats is a particularly ba= d idea, > given the existence of RFC 3339. I mean, strptime() can handle both, and since everything is written in C (which is why we so badly need security.txt!), that's enough. But yes, ISO 8601 is much easier to parse. And it will be even easier to compare dates if security.txt ends up using Zulu time, since then plain string comparison (even memcmp()!) is enough. Thinking about implementation... I suddenly wonder why security.txt should have expiration instead of a TTL. I'm pretty sure what's really intended is that I not cache security.txt files too long so that they can be updated. Indeed, sections 3.5.5 and 6.3 make it clear that this is about caching. An optional publication time (ISO 8601), and a required TTL measured in hours or days would be more than sufficient, and maybe superior to a notAfter. Unless the point of `Expires` is also to force the publisher to keep security.txt up to date. Implementation-wise, I see a few ways in which I would handle `Expires` information: 1) Comparison. E.g., to determine if a security.txt is stale, or to sort/index/search archived security.txt files, in which case I'd have two choices: 1a) if the format is ISO 8601 zulu, then format current time then string compare, 1b) parse the `Expires` into local time of day form and compare to current time. (1a) is simpler, but only works for ISO 8601 Zulu times. 3) Authoring/production of security.txt files, where I only need to format time, not parse it. Clearly it's easier to only have to format time and never have to parse it. That said, strptime() and similar are widely available and easy enough to use, so I do think there's an readability argument to make. But ISO 8601 is still easier to read than RFC 5322 time, especially for non-English speakers. Nico --=20 From nobody Tue Apr 13 13:06:41 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D293A259D; Tue, 13 Apr 2021 13:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 fAzuQlm8rY1A; Tue, 13 Apr 2021 13:06:31 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CD53A2635; Tue, 13 Apr 2021 13:06:17 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lWPId-0009xi-PO; Tue, 13 Apr 2021 16:06:15 -0400 Date: Tue, 13 Apr 2021 16:06:10 -0400 From: John C Klensin To: "Eliot Lear (elear)" , Yakov Shafranovich cc: art@ietf.org, saag@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 20:06:36 -0000 --On Tuesday, April 13, 2021 19:00 +0000 "Eliot Lear (elear)" wrote: > The question is whether you need something that is easy to > parse or something that is human readable and can be > localized. It SEEMs that this draft is intended to be human > readable, and so 5322 doesn't seem out of bounds. I suggest that even for reading by humans in 2021 --as distinct from 1982 (RFC 822) or 1977 (RFC 733, which used day-month-year ordering)-- the 5322 dates are not easy to understand and use... at least unless one is an English speaker on this side of the pond. It was quite wise at the time to spell out the month name, thereby eliminating the ambiguity associated with, e.g., 5/10/1977, but still bad news for someone who might think the fourth month in the Gregorian calendar is, e.g., = =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F, =D8=A3=D8=A8=D8=B1=D9=8A=D9=84 , or =E5=9B=9B=E6=9C=88. So I would argue that, for new protocols or data structures in this increasingly global/ international Internet, and even for elements visible to humans, sticking as close to ISO 8601 as possible (with minimal profiling) is the Right Thing to Do. Much too late now to change the 822/5322 format, turning supplemental protocols for email into a gray area, but, for new work, ISO 8601 formats are not just easier to parse but easier to understand globally and in an unambiguous way. Just my opinion, of course. john From nobody Tue Apr 13 13:59:00 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2C53A0CF8; Tue, 13 Apr 2021 13:58:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=garr.it 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 0byQHOtXRfk9; Tue, 13 Apr 2021 13:58:50 -0700 (PDT) Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [193.206.158.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93E93A0CF6; Tue, 13 Apr 2021 13:58:49 -0700 (PDT) Received: from mac-allocchio3.garrtest.units.it (unknown [10.2.2.13]) by smtp-1.dir.garr.it (Postfix) with ESMTPSA id EA6E09FB6A; Tue, 13 Apr 2021 22:58:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=garr.it; s=202004; t=1618347525; bh=SM0rYB/O19MjT9r6urAjn+xHK7y7cXNgfgO3Z5jLrhc=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=HNzdLy5PS3sROGXnhUvtT1nIngohYgb/rlmXHz6lKG1h0SGBxg1rR08BlUqCUCR6w FaKjVfVnuzCAxHqMm/2j/lDQCMDRu9zaz6mpTdohrnfMXGqEoUrB8V+PDl04t7i/CV n2AKPhjo3kSUn7K780oB3fgXgmCHb/oSpzdwijlCKAm9PAUXwGC6rCj04n2Es7ZZFL vqUSHwGTp4r7Tl1GB+ZHOLpoTmnnNEpPne+4xZUivnAvr83YybGBudvwS7u9aLSmK9 vYSHgeP6C6AYdOqWjxSmCYm1Z3Y1mnjHazBeU7hchTjGBFBmywXBbhrD8YmGnfBU11 4n/m8ZBvJFGWA== Date: Tue, 13 Apr 2021 22:58:44 +0200 (CEST) From: Claudio Allocchio X-X-Sender: claudio@mac-allocchio3.local To: John C Klensin cc: "Eliot Lear (elear)" , Yakov Shafranovich , art@ietf.org, saag@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (OSX 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="0-890075638-1618347432=:1318" Content-ID: Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 20:58:56 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-890075638-1618347432=:1318 Content-Type: text/plain; CHARSET=UTF-8; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: let me do a wider diversion: human reading of time and date, was and still is a cause of problems: the human readable version, with all its flavours, variants, causes headaches... every time we schedule a meeting we need to ensure all do understand when it is... 04/07/2021 at 2.30PM is it the 4th day of July 2021, or th e 7th date of April? 2.30PM which time zone? DST or not? So to go back to the point, +1 to John: ISO 8601 is better, also for humans! (the date/time paring code for email gateways I wrote 30+ years ago was a set of nested "if" "then" "else" "and" "or" and tables... no thank you.) On Tue, 13 Apr 2021, John C Klensin wrote: > > > --On Tuesday, April 13, 2021 19:00 +0000 "Eliot Lear (elear)" > wrote: > >> The question is whether you need something that is easy to >> parse or something that is human readable and can be >> localized. It SEEMs that this draft is intended to be human >> readable, and so 5322 doesn't seem out of bounds. > > I suggest that even for reading by humans in 2021 --as distinct > from 1982 (RFC 822) or 1977 (RFC 733, which used day-month-year > ordering)-- the 5322 dates are not easy to understand and use... > at least unless one is an English speaker on this side of the > pond. It was quite wise at the time to spell out the month > name, thereby eliminating the ambiguity associated with, e.g., > 5/10/1977, but still bad news for someone who might think the > fourth month in the Gregorian calendar is, e.g., апреля, > أبريل , or 四月. > > So I would argue that, for new protocols or data structures in > this increasingly global/ international Internet, and even for > elements visible to humans, sticking as close to ISO 8601 as > possible (with minimal profiling) is the Right Thing to Do. > Much too late now to change the 822/5322 format, turning > supplemental protocols for email into a gray area, but, for new > work, ISO 8601 formats are not just easier to parse but easier > to understand globally and in an unambiguous way. > > Just my opinion, of course. > > > john > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > ------------------------------------------------------------------------------ Claudio Allocchio G A R R Claudio.Allocchio@garr.it Senior Technical Officer tel: +39 040 3758523 Italian Academic and G=Claudio; S=Allocchio; fax: +39 040 3758565 Research Network P=garr; A=garr; C=it; PGP Key: https://www.cert.garr.it/servizi/informazioni-su-pgp-keys --0-890075638-1618347432=:1318-- From nobody Tue Apr 13 14:01:57 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11373A0D24; Tue, 13 Apr 2021 14:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 hXREt3pAxC5y; Tue, 13 Apr 2021 14:01:51 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408B33A0D27; Tue, 13 Apr 2021 14:01:47 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1lWQA6-0005GW-Sq; Tue, 13 Apr 2021 21:01:31 +0000 Date: Tue, 13 Apr 2021 14:01:30 -0700 Message-ID: From: Randy Bush To: Nico Williams Cc: Yakov Shafranovich , art@ietf.org, saag@ietf.org In-Reply-To: <20210413190503.GJ9612@localhost> References: <20210413190503.GJ9612@localhost> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [saag] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 21:01:53 -0000 > My very strong preference is for ISO 8601 format dates on account of: > > - it sorts semantically correctly when sorting alphabetically (when > using Zulu time) > > - anyone can read and write ISO 8601 format dates, and it's easy to > memorize -- this is not true of any other format > > I would further suggest that timezone information for this purpose is > not very useful in this context, and that always using Zulu time would > be best. thank you randy From nobody Tue Apr 13 15:26:07 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95273A12EF; Tue, 13 Apr 2021 15:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 OShrCEmTseUf; Tue, 13 Apr 2021 15:25:57 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D77A3A12E4; Tue, 13 Apr 2021 15:25:56 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RXTS9CKTSW00HE4N@mauve.mrochek.com>; Tue, 13 Apr 2021 15:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1618352452; bh=VyPYKdRldGKqG/AjXCbPNj06MVVXTcRLbfTXjBuCOyo=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=EwlvaTO55Z4sus+8wU/r81nZsgu6zoTfrDFYioKmkPugHrkOXSfNBU2kl0SEJf2Vj BeL4T0tlKfrSg+HtzU/mpR2jUiQkBfZsxA4YOx0DfpM5tiCCp/pYGEa3k2UMUbuCKe jX5679aPOIb4cUwtVKVmZPxv7zQ1RxE6dGMMZWjM= MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: TEXT/PLAIN; charset=utf-8; Format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RXTM8LE0RK0085YQ@mauve.mrochek.com>; Tue, 13 Apr 2021 15:20:49 -0700 (PDT) Cc: Yakov Shafranovich , art@ietf.org, saag@ietf.org Message-id: <01RXTS9APXIU0085YQ@mauve.mrochek.com> Date: Tue, 13 Apr 2021 15:17:45 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Tue, 13 Apr 2021 12:30:21 -0700" <901F4345-91B6-42CA-9F68-27DB4C539F3D@vpnc.org> References: <901F4345-91B6-42CA-9F68-27DB4C539F3D@vpnc.org> To: Paul Hoffman Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 22:26:02 -0000 > On 13 Apr 2021, at 11:43, Yakov Shafranovich wrote: > > Is there a preference for Internet drafts/RFCs regarding the specific > > data/time format to be used? > > > > Right now we are referencing RFC 5322, but there has been feedback > > from multiple people that the ISO 8601 format is easier to parse. This > > is in regards to the section 3.5.5 of "draft-foudil-securitytxt-11" > > that I am working on: > > https://tools.ietf.org/html/draft-foudil-securitytxt-11#section-3.5.4 > > > > The options I am asking about are the following: > > - RFC 3339 (a profile of ISO 8601) > > Example: 2021-04-13T06:50:53-07:00 > > > > - RFC 5322, section 3.3 > > Example: Tue, 13 Apr 2021 06:50:53 -0700 > Given that the date in that section of that draft is meant to be machine > parsed, choosing RFC 5322 (neé 822) date formats is a particularly bad > idea, given the existence of RFC 3339. Whenever machine parsing enters the picture the other syntax that should be considered is integer milliseconds since epoch. (This syntax is increasingly popular in the schemata I encounter.) However, I think there's also a need for this to be readable. RFC 3339 seems like the right balance to me. Ned From nobody Tue Apr 13 16:09:04 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE883A1503; Tue, 13 Apr 2021 16:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zP7dNc_1bgiX; Tue, 13 Apr 2021 16:08:58 -0700 (PDT) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62EA63A1504; Tue, 13 Apr 2021 16:08:58 -0700 (PDT) Received: by mail-qk1-x730.google.com with SMTP id o17so11207698qkl.13; Tue, 13 Apr 2021 16:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=v8dbp2CVAiGMM/ZFlxMjv09t8VV5cEVyub4JAjtjE7I=; b=KNM0K+tXUadcz+8GKsa45YXDs45KovhNQG5o2N0lePlApaeIBoiKYPWtzxcGPnWp2w BSJJDF5nn2kHGObZ8xEJcEKkBAjWktacUmJSVuxOdVPG3HkL2iNhy0GBfEZfzt2rFLyK 2HAllKqwPJg20jOuQk6zP6pSekj5SjgOIsibUrWgIghbpf+Wnwv4U8fzhmtusNgdevLA HzOWjns/yJijrojJi8pxhXbio5x/UszPh9taVyqolGVsniONRdE+7zXJT8KW5c9mtkJU iUCr8NykdINSvpQJM7LC+uye7cvWy8bkOWpkLmt605bfysQKZ6/MNZwMMMi9PWda9tEg yLTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=v8dbp2CVAiGMM/ZFlxMjv09t8VV5cEVyub4JAjtjE7I=; b=tJ1B9DTwuJOq8jPJ23jAxG6qCtED4s/sQ+b+z9xeXFsUU2f17Rypgy0Pgo9F2gw13b kmGE1z0+hPkp0P8YHIkyFCIHJ1o77wSkamG0lkphA9rdJCrt5ZIERlSEMfEEcAhUWYP7 9OtpFqCBpVy9jR8g/SEJ6+Uk7Aj7+y+7Pw0EhgXwZq/PQFRFw6Hn2Mhlm06yWqIMB9Ol 7gfkepJVZMcnEzaACjLqMSl9lxBtpmTI8bp7FygEAQon/SuLkw9jMtHMINChFZx1bx6t 03Z1LoMMxaSmt4gWOMxZNgWlLJ0XI97uBagxqKsqyPe1VdgV1+rnUewkB1SMdtSX/5a+ 6uAw== X-Gm-Message-State: AOAM5318Xjlq1Ei7F7x1leMiThKjCnqrFbERz4jCZEOJNRt+DrfY3vfy 3TiQfFKQE0/M/y6htOV1xJ4= X-Google-Smtp-Source: ABdhPJwNCE3pljxiohI8tMMNrguWwap3M0a/M/8Y4nwcB2Vi7Gr1ZVl6dWE/p0VCke+yAme1P3bZcg== X-Received: by 2002:a37:9087:: with SMTP id s129mr35552514qkd.297.1618355336141; Tue, 13 Apr 2021 16:08:56 -0700 (PDT) Received: from [192.168.1.149] (cpe-74-70-70-237.nycap.res.rr.com. [74.70.70.237]) by smtp.googlemail.com with ESMTPSA id 81sm10271830qkl.121.2021.04.13.16.08.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 13 Apr 2021 16:08:55 -0700 (PDT) To: Nico Williams , "Eliot Lear (elear)" Cc: "art@ietf.org" , "saag@ietf.org" , Yakov Shafranovich References: <20210413191937.GK9612@localhost> From: Michael Douglass Message-ID: <3ac37291-a75d-53b0-27e4-94875b143c63@gmail.com> Date: Tue, 13 Apr 2021 19:08:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <20210413191937.GK9612@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2021 23:09:02 -0000 Even as a UK person I prefer the ISO8601 format On 4/13/21 15:19, Nico Williams wrote: > On Tue, Apr 13, 2021 at 07:00:17PM +0000, Eliot Lear (elear) wrote: >> The question is whether you need something that is easy to parse or >> something that is human readable and can be localized. It SEEMs that >> this draft is intended to be human readable, and so 5322 doesn’t seem >> out of bounds. > English-centric much? :) > > Seriously, RFC 5322 is unnecessarily English centric, and ISO 8601 is > universally understandable. > > Nico From nobody Tue Apr 13 21:22:59 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3A43A1ACC; Tue, 13 Apr 2021 21:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dcrocker.net 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 KdfE--24I7WO; Tue, 13 Apr 2021 21:22:47 -0700 (PDT) Received: from dog.birch.relay.mailchannels.net (dog.birch.relay.mailchannels.net [23.83.209.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 472943A1ACB; Tue, 13 Apr 2021 21:22:46 -0700 (PDT) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id BDFDC921CD8; Wed, 14 Apr 2021 04:22:45 +0000 (UTC) Received: from nl-srv-smtpout1.hostinger.io (100-96-16-47.trex.outbound.svc.cluster.local [100.96.16.47]) (Authenticated sender: hostingeremail) by relay.mailchannels.net (Postfix) with ESMTPA id 564859222F4; Wed, 14 Apr 2021 04:22:43 +0000 (UTC) X-Sender-Id: hostingeremail|x-authsender|dhc@dcrocker.net Received: from nl-srv-smtpout1.hostinger.io ([UNAVAILABLE]. [185.224.136.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256) by 100.96.16.47 (trex/6.1.1); Wed, 14 Apr 2021 04:22:45 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: hostingeremail|x-authsender|dhc@dcrocker.net X-MailChannels-Auth-Id: hostingeremail X-Plucky-Average: 237387723a185e38_1618374165474_2050355545 X-MC-Loop-Signature: 1618374165473:1132739903 X-MC-Ingress-Time: 1618374165473 Received: from [192.168.0.111] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (Authenticated sender: dhc@dcrocker.net) by nl-srv-smtpout1.hostinger.io (smtp.hostinger.com) with ESMTPSA id 65A7F22693AE; Wed, 14 Apr 2021 04:22:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=hostingermail-a; t=1618374161; bh=Q0HIaW/U/xkIVw6QqZqwbXkA6Cf/0B0ZaC8bghcTst0=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=GHjW/4xxePk3wETVI2nAByr1/FRBN8xNyTDluocVVZYkah4/na4K5T1eVZ0lsBbYb Qyml1Mif8HuFFgRovyPAEWJD9fbFpeglwUaDrswB8xLUAe7HGjHqYDPw44QZNkuObd W9PVKeSn5X0G5kS4u3L/mOC9ZVZ/07gmZQ+E36AvuqMwYGCL5Pg7w7xXWc7MX1th78 5t5EFew20ru4fzQQ5eHPu+TnSQY2rfKd7Dmb1FZkoXTNhBPaMd9Jgb/p9yPDeFIoh6 TjuVoaHC48/NsW62gDyy7mhAqNbr6GsSaAAb/2gVYh5IWLazD6060cEB7VAwnCExTh B4J2iIYsdC+rQ== Reply-To: dcrocker@bbiw.net To: Nico Williams , "Eliot Lear (elear)" Cc: "art@ietf.org" , "saag@ietf.org" , Yakov Shafranovich References: <20210413191937.GK9612@localhost> From: Dave Crocker Organization: Brandenburg InternetWorking Message-ID: Date: Tue, 13 Apr 2021 21:22:33 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: <20210413191937.GK9612@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 04:22:53 -0000 On 4/13/2021 12:19 PM, Nico Williams wrote: > English-centric much?:) The RFC5322 date format was not designed for use as extensive as venues speaking English. It's original target for use was restricted only to North America (cf, RFC733). I thought it quite exciting to even include Atlantic Standard Time, as well as the zones for Hawaii and Alaska, although getting the latter turned into a bit of an exercise. I was working at The Rand Corporation at the time and had been told that the Librarian there had magical research skills. The timezone topic finally prompted my contacting her and asking for help. She said she'd see what she could find. I don't think it was as much as a half-hour before she called back with the answer. I was duly impressed. (Astonished would be the more apt word.) So I asked her how she found the answer that quickly. She told me she call the phone company's information operator for Juneau and asked her what they called their timezone. She then repeated the exercise for Oahu... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From nobody Wed Apr 14 02:01:11 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9123A1690; Wed, 14 Apr 2021 02:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 nEQWNgJtrmhf; Wed, 14 Apr 2021 02:00:59 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100074.outbound.protection.outlook.com [40.107.10.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40283A1693; Wed, 14 Apr 2021 02:00:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jSug1EE4lIwLp7oB0m9O69DFN3azjrzhIiXOuxEA1amzNSHAEte4wirWFs+PtWkpo3RULaj1tM2yx5pCweZ7IVW9ppcXMdHXPdnfOuZl23NkfRMrJfwg7++wnkXCKpB5fEOYwDCAK8/u2qCwJRiBiscCdPfVbKr/Rn0onCzWCsojk3JVegqp+Fm4nLfD9t314HQUHVgQZpUE42LbX7SO0lxPZfsYkbfHiR2Wb4T4QrtymPX5kaQzLIx0ldsUEyzBsm7Xynjm6H4sr1CHG+sEUt61eeT/QXOtBdFlxd53OtKQ95frpqRfF7BHRC3zYd18j1hAgSU6mK8uRX2T5Ql7HA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wOxhUJfiHILFD+LwRGiWsiYoKkl7o5+frWh5vQZ5CYY=; b=OHgIMP2kK3KjPkTWGfWI+BFQSWXbcS97KszG4OT6F4w1Pkct2p9A7lnx7I7235jrJ4hPEhGdnVI0Oj1Q+jzYh2sv8DiExl504PyRGLnRyHV84IqcWNeoj42ncbghMaj0epXhzQ7M+mb8IEW8lHLRJLAX7KRptG494f9Kdbb6mM5EUjTLS/bz9kWstbUmX9PTwrVUAqIiXQj3hV9BZ98V4UDc/V7CFOyO/rSsu7xpjRPuDemtD/MGsgQKLQpGX9NTLXd1HFCUPuim8fgDGaWjyKXvUmh1nF1KjAw02fXPxLAzhg+xIvzqtNC4W8Ca37vI71RbsGMiBXM3O8b8SZH2Cw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=manchester.ac.uk; dmarc=pass action=none header.from=manchester.ac.uk; dkim=pass header.d=manchester.ac.uk; arc=none Received: from LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:184::9) by LOYP265MB2173.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:110::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.22; Wed, 14 Apr 2021 09:00:55 +0000 Received: from LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM ([fe80::8088:4602:d179:2e9e]) by LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM ([fe80::8088:4602:d179:2e9e%7]) with mapi id 15.20.4020.023; Wed, 14 Apr 2021 09:00:55 +0000 From: Stian Soiland-Reyes To: "dcrocker@bbiw.net" , Nico Williams , "Eliot Lear (elear)" CC: "art@ietf.org" , "saag@ietf.org" , Yakov Shafranovich Thread-Topic: [art] [saag] Date formats: RFC3339 vs. RFC 5322 Thread-Index: AQHXMJe3QFo8O+lXyEKs6qsGiriCoaqy0rQAgACXsYCAAF6JgA== Date: Wed, 14 Apr 2021 09:00:55 +0000 Message-ID: <5F841FEF-7985-424B-A925-336AC3265D8F@manchester.ac.uk> References: <20210413191937.GK9612@localhost> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: bbiw.net; dkim=none (message not signed) header.d=none;bbiw.net; dmarc=none action=none header.from=manchester.ac.uk; x-originating-ip: [2001:8b0:a657:68e3:d08c:7f95:a3d:f697] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 63adc707-0728-4c11-7867-08d8ff23d032 x-ms-traffictypediagnostic: LOYP265MB2173: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: u4cMzfoXDhz/LLfStr0bVEwSmGHopNPu7DNgTO64pVzh7PhdPQ4kKohuALXjpTJIkTbN5Eg1i3Q7WvVTmpOhMl2AlgfL/eafGcvka3iOVY0JoSP9LBxoimg6TP4OL1ckkQx36XrhqiX/2k0XsO1V6G+EmENkJvVQi/Le4rZGG3fgtWA/psQF7sl20eElQ6u7a/+Ni9fArTvF3Ld6ST3vP7gyXOPVl6Vu6BQohV30FiNJXKpn1ho/uBUV8tXfe6l/yLj7y+RG6eFcRJA/d59wwbIRhTBVRf/TKZ7nKTP4CWjtErRH1D1AKv+4apWrsS79+qUvf/dj/awwbNBNiwQr2RiCV+PLU2YqFRiFH7ktEK3XVPCbVvB0YVDqBFJ006oFnX2lzE2NyVjnz4ABOQ4eG5uD5JWu9SpRv+mYpry//8kNpI3uVunVDZUyqj4aECEQoB5OciuvqPzwGo2WXkt+cASRGJDKoCWzmLsxQdtME+LeCBWXvpWD36DiH3q6q29HVQMN/vqHcaVwqIO+jXHEDpsrwu71+pSOb1j4HRUfSz/NHKaA0IzZ1QzbWlmkyFp+KBRVOmXgujn3BtaezyG2SFYlaZaFD5XocHVYeEg9rDRgx4rYteU9+BH8a+MEbNe7EUs1VW/ieslmMu+dpo6tD9b8+BjFqCvoUqhFZUCSBJvFUIULAo3sI4ys9Zn28X9OwmRWSaTuwq8ux1wvG72USpn+y0Ctzc3zqohCIs6kfwo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(39860400002)(346002)(376002)(366004)(136003)(33656002)(38100700002)(36756003)(2616005)(53546011)(316002)(122000001)(76116006)(4326008)(6506007)(54906003)(6512007)(86362001)(786003)(966005)(71200400001)(478600001)(186003)(66446008)(8676002)(6486002)(66556008)(66476007)(83380400001)(64756008)(66946007)(2906002)(110136005)(5660300002)(8936002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?NWJZc2t3dmFpVXFvK1hZYTc3YnY2R2wxcXpod0k1SVFtdW5YdnU4L1J2QmVB?= =?utf-8?B?QlJGVko3dVNWK2g4VERZL25lS2M4amh2cjY2SXZsSi9FZEJXS0pvc25OSXZv?= =?utf-8?B?Q2lrYXltR2lCc0YxUXRkRmo2Mk9XaDhNNDNTMWFKM2VBTUtEU1RxUXdRUHMx?= =?utf-8?B?VTZEUjU2Vm5QQlJNcjkrTGhVWTNqUTgwdStSRkMzeVk0YXRMLzRuVXl3SW03?= =?utf-8?B?NDcwV2FvSnVRTTZXVkNTUkk4cWd4eFdmYUJmZmVXbGxpd2hUU25UOGgxSE8w?= =?utf-8?B?UTR4TVd1WGJwRGxRaktkWkZZV09aQndFZ3hMU2x2ZU8wZVNVTjFQYUNrVGhv?= =?utf-8?B?VWRnczJxeklpcDZzM0VMaEcvUW5yR2NvMU84N3paMjBPZ2tPdWtyd1BxekZU?= =?utf-8?B?eWIyaEhLNGlTYUR0T3FuZjR2RXpJRnA4MEVtdWJLeFVVTjZmclZRQ3h2alR5?= =?utf-8?B?T0VPZ05nR2ZlQTJLMmQ1bWdlbjhia0F5TnBPMG1WU2FzT1lQTVBuKytzSXFw?= =?utf-8?B?U1kyMnJjSlJhVmR6RVdxaTcvT0hieENvMS9DYTl5Nk42Y2FHVlFpSG9OS1JQ?= =?utf-8?B?WHZMaFlyeDZhWUxNTUJxS0g2MUhCa0QrdE5DUEM1WDZwSWZ2Y2lrVHJzZC8z?= =?utf-8?B?eVQzdU4yZXNVY1JsK2tTY3hQTFM4RUlyYm5SNGpNT3BjSzFLaUNyR1pCWHZW?= =?utf-8?B?N2pXWWFlNTVZN2VGRVNNL2J5TnRmUC84UU9BOVljWWt0YkhCVUFEdXNzR1Vv?= =?utf-8?B?UVhJcmdMcWVYMXVlRzc5dE9UV1oxMXROSDl4NnFScUFTNGo2UjZyVkw0LzRH?= =?utf-8?B?b09mNE5WOHdYZk10TVBSeTNITi9MNEJqSUFmd1JLWFNDYW9BcjBPcjkwVnFi?= =?utf-8?B?Rk9ZQWtHaGtrck4yMWRib3IzTm03Smh3eXNwS20rVHhmYXZzekJBUm9UOGZv?= =?utf-8?B?dlJFOURtVTRxMkI4SnBtOEFuVXJiLyt4TkpsMjFhOUJySVd2OG9Ddi9GTWM2?= =?utf-8?B?anA3SytCdGZ1YXdReDExNndlU2V5aWxtVzN4Y1d3bUhvd05vSk9PaXByMzg5?= =?utf-8?B?c2dTbjB3ZlU5SVdSQkNSZlVtUVJTZ21yVGFUYm9wT2U0ZzBibml3Y3RIV1pY?= =?utf-8?B?Vm40dlAyc0lKdGhOQkVJZUJwTmFMRFBuOEp4UmpVRk1POG54TUtYZ1kwbXBh?= =?utf-8?B?TEJMbGRQVHI1VnRKYWJFd2tYNnhWUHFETWFDZmREamdpRkxxbFZPdmN0TGc5?= =?utf-8?B?MXRGVmVpdS9VOFNmSjFydy9QMjV3UTlDdVFjSHUxekFFY0dSVy8zY29pZG0x?= =?utf-8?B?enhMelBKa1ZTdlovaGptMFlkckYyUFljTGZZdldkV1BvQmpaQUdXSTMxWEhr?= =?utf-8?B?UmFlN1RQNW85YnMvYWJ4S29OYmVnaXJrZzZkWGFtSDdDV2tIYkNRSmlLaGdT?= =?utf-8?B?UDJFdnkrTE10UE9qLzB5aVdsUnFPbW93N2FuWG1XdXpoams3M3lQY2lIcUlN?= =?utf-8?B?c3RPSjk1OUE2anJrQ3ZCWkZiTlJwcGdQUHRGa05td0h0RXI2VU8yVEJGdVMx?= =?utf-8?B?dmdUVktKajgxNDlydEZuMVNpSm9qYjVaZmZxWTgzZTRnSW90Y1FjQm9RNytq?= =?utf-8?B?b0YzazI4ZzczVms4MXRRcUFtRFkzM0hOeVFadkVqVW8wUzAySFRHc3I4WmFH?= =?utf-8?B?UnhML201Z3dwR0w0dDBGTy9PbjdRUksvdzdZU2krMTZqZ3lJUHprUVR0K3hD?= =?utf-8?B?Sk5INzd0dTMzd0dFUVg3Z0dxZ1NVam1Sb1Y1MjBSZGp4QU56QVI1TTFyTW9T?= =?utf-8?B?cFZoSy85Z01pdU13UFVqREtDWUdjaHJiazJqVC9TakgzRnJtUTBZSUVLQ0ZW?= =?utf-8?Q?OQAHNGdlwmzoX?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <9A2AAE08ACCC4F4EA1A9DEF3F80AAD7A@GBRP265.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: manchester.ac.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 63adc707-0728-4c11-7867-08d8ff23d032 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2021 09:00:55.4194 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c152cb07-614e-4abb-818a-f035cfa91a77 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BqMMEBoGvZEOYYJ0s7W6dDW7Rlw6psTKqKLEu9pc/XXhxJrJCTCuJHNHFYVqtrqSlAF7T5vEci2AchxS2ENd21HFqasDCRn8JaRuXixLUWM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LOYP265MB2173 Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 09:01:05 -0000 SSB3b3VsZCBzYXkgZm9yIHRoaXMgcGFydGljdWxhciBleGFtcGxlIG9mIHNlY3VyaXR5IGxvZ3Mg eW91IHNob3VsZCB1c2UgSVNPODYwMSAoYWthIFJGQzMzMzkpLCBhcyBpdCBpcyBtb3JlIGltcG9y dGFudCB3aGVuIGl0IGhhcHBlbmVkL2V4cGlyZXMgaW50ZXJuYXRpb25hbGx5IHJhdGhlciB0aGFu IHdoYXQgdGltZXpvbmUgaXQgaGFwcGVuZWQgaW4uIA0KDQpJbiB0aGF0IGNhc2UgaXQgc2hvdWxk IGFsc28gYmUgVVRDLWJhc2VkIG9yIGhhdmUgYW4gZXhwbGljaXQgdGltZXpvbmUsIGUuZy4gY29u c2lkZXJpbmcgIlplcm8gZGF5IiAtIHdoaWNoIGRheT8NCg0KQXMgYSBzaWRlIGVmZmVjdCAgZGF0 ZXMgYXJlIGFsc28gbmljZWx5IHNvcnRhYmxlIQ0KDQotLSANClN0aWFuIFNvaWxhbmQtUmV5ZXMs IFRoZSBVbml2ZXJzaXR5IG9mIE1hbmNoZXN0ZXINCmh0dHBzOi8vd3d3LmVzY2llbmNlbGFiLm9y Zy51ay8NCmh0dHBzOi8vb3JjaWQub3JnLzAwMDAtMDAwMS05ODQyLTk3MTgNCiAgICBQbGVhc2Ug bm90ZSB0aGF0IEkgbWF5IHdvcmsgZmxleGlibHkg4oCTIHdoaWxzdCBpdCBzdWl0cyBtZSB0byBl bWFpbCBub3csIA0KICAgIEkgZG8gbm90IGV4cGVjdCBhIHJlc3BvbnNlIG9yIGFjdGlvbiBvdXRz aWRlIG9mIHlvdXIgb3duIHdvcmtpbmcgaG91cnMuDQogDQoNCu+7v09uIDIwMjEtMDQtMTQsIDA1 OjIzLCAiYXJ0IG9uIGJlaGFsZiBvZiBEYXZlIENyb2NrZXIiIDxhcnQtYm91bmNlc0BpZXRmLm9y ZyBvbiBiZWhhbGYgb2YgZGhjQGRjcm9ja2VyLm5ldD4gd3JvdGU6DQoNCiAgICBPbiA0LzEzLzIw MjEgMTI6MTkgUE0sIE5pY28gV2lsbGlhbXMgd3JvdGU6DQogICAgPiBFbmdsaXNoLWNlbnRyaWMg bXVjaD86KQ0KDQogICAgVGhlIFJGQzUzMjIgZGF0ZSBmb3JtYXQgd2FzIG5vdCBkZXNpZ25lZCBm b3IgdXNlIGFzIGV4dGVuc2l2ZSBhcyB2ZW51ZXMgDQogICAgc3BlYWtpbmcgRW5nbGlzaC4gIEl0 J3Mgb3JpZ2luYWwgdGFyZ2V0IGZvciB1c2Ugd2FzIHJlc3RyaWN0ZWQgb25seSB0byANCiAgICBO b3J0aCBBbWVyaWNhIChjZiwgUkZDNzMzKS4NCg0KICAgIEkgdGhvdWdodCBpdCBxdWl0ZSBleGNp dGluZyB0byBldmVuIGluY2x1ZGUgQXRsYW50aWMgU3RhbmRhcmQgVGltZSwgYXMgDQogICAgd2Vs bCBhcyB0aGUgem9uZXMgZm9yIEhhd2FpaSBhbmQgQWxhc2thLCBhbHRob3VnaCBnZXR0aW5nIHRo ZSBsYXR0ZXIgDQogICAgdHVybmVkIGludG8gYSBiaXQgb2YgYW4gZXhlcmNpc2UuDQoNCiAgICBJ IHdhcyB3b3JraW5nIGF0IFRoZSBSYW5kIENvcnBvcmF0aW9uIGF0IHRoZSB0aW1lIGFuZCBoYWQg YmVlbiB0b2xkIHRoYXQgDQogICAgdGhlIExpYnJhcmlhbiB0aGVyZSBoYWQgbWFnaWNhbCByZXNl YXJjaCBza2lsbHMuICBUaGUgdGltZXpvbmUgdG9waWMgDQogICAgZmluYWxseSBwcm9tcHRlZCBt eSBjb250YWN0aW5nIGhlciBhbmQgYXNraW5nIGZvciBoZWxwLiAgU2hlIHNhaWQgc2hlJ2QgDQog ICAgc2VlIHdoYXQgc2hlIGNvdWxkIGZpbmQuDQoNCiAgICBJIGRvbid0IHRoaW5rIGl0IHdhcyBh cyBtdWNoIGFzIGEgaGFsZi1ob3VyIGJlZm9yZSBzaGUgY2FsbGVkIGJhY2sgd2l0aCANCiAgICB0 aGUgYW5zd2VyLiAgSSB3YXMgZHVseSBpbXByZXNzZWQuICAoQXN0b25pc2hlZCB3b3VsZCBiZSB0 aGUgbW9yZSBhcHQgDQogICAgd29yZC4pICBTbyBJIGFza2VkIGhlciBob3cgc2hlIGZvdW5kIHRo ZSBhbnN3ZXIgdGhhdCBxdWlja2x5Lg0KDQogICAgU2hlIHRvbGQgbWUgc2hlIGNhbGwgdGhlIHBo b25lIGNvbXBhbnkncyBpbmZvcm1hdGlvbiBvcGVyYXRvciBmb3IgSnVuZWF1IA0KICAgIGFuZCBh c2tlZCBoZXIgd2hhdCB0aGV5IGNhbGxlZCB0aGVpciB0aW1lem9uZS4gU2hlIHRoZW4gcmVwZWF0 ZWQgdGhlIA0KICAgIGV4ZXJjaXNlIGZvciBPYWh1Li4uDQoNCiAgICBkLw0KDQogICAgLS0gDQog ICAgRGF2ZSBDcm9ja2VyDQogICAgQnJhbmRlbmJ1cmcgSW50ZXJuZXRXb3JraW5nDQogICAgYmJp dy5uZXQNCg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQogICAgYXJ0IG1haWxpbmcgbGlzdA0KICAgIGFydEBpZXRmLm9yZw0KICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXJ0DQoNCg== From nobody Wed Apr 14 03:21:42 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E048D3A199C for ; Wed, 14 Apr 2021 03:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9Dd4h0NOAvS4 for ; Wed, 14 Apr 2021 03:21:36 -0700 (PDT) Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [103.96.23.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48D423A199E for ; Wed, 14 Apr 2021 03:21:35 -0700 (PDT) Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01lp2173.outbound.protection.outlook.com [104.47.71.173]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-64-IXmcpotJN_ikuas1TOEVDA-1; Wed, 14 Apr 2021 20:21:32 +1000 X-MC-Unique: IXmcpotJN_ikuas1TOEVDA-1 Received: from SG2PR06CA0186.apcprd06.prod.outlook.com (2603:1096:4:1::18) by SY4PR01MB6505.ausprd01.prod.outlook.com (2603:10c6:10:122::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16; Wed, 14 Apr 2021 10:21:29 +0000 Received: from SG2APC01FT059.eop-APC01.prod.protection.outlook.com (2603:1096:4:1:cafe::c0) by SG2PR06CA0186.outlook.office365.com (2603:1096:4:1::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16 via Frontend Transport; Wed, 14 Apr 2021 10:21:29 +0000 X-MS-Exchange-Authentication-Results: spf=none (sender IP is 130.216.95.224) smtp.mailfrom=cs.auckland.ac.nz; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cs.auckland.ac.nz Received: from uxcn13-ogg-e.UoA.auckland.ac.nz (130.216.95.224) by SG2APC01FT059.mail.protection.outlook.com (10.152.251.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.4042.16 via Frontend Transport; Wed, 14 Apr 2021 10:21:27 +0000 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.8) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 14 Apr 2021 22:21:25 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1497.012; Wed, 14 Apr 2021 22:21:25 +1200 From: Peter Gutmann To: Nico Williams , "Eliot Lear (elear)" , "dcrocker@bbiw.net" CC: "art@ietf.org" , "saag@ietf.org" Thread-Topic: [saag] [art] Date formats: RFC3339 vs. RFC 5322 Thread-Index: AQHXMOYCPXqqZEOUwE+abNfa2hcOc6qzzXDZ Date: Wed, 14 Apr 2021 10:21:25 +0000 Message-ID: <1618395685340.24243@cs.auckland.ac.nz> References: <20210413191937.GK9612@localhost>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: c83def6d-a903-4be3-e52c-08d8ff2f1070 X-MS-TrafficTypeDiagnostic: SY4PR01MB6505: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7219 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: MZpTuXHZNtL5sMIBsB989u0uUURbPNCDZawcr+B2D8aywUA9sBwfN1vgkilNKrsi4hECVa0gDTn1k+kXPjV6jM3mDw1WZ4Nfyz8TF6LZ3IvbOj4YhI/o9vqdL9YNTo/NNHqfttIX+X2dqalWPAlW7s1NrONgVgW5X+N2+M6u9IKZNYetjZo0rPrc9Sbm+irVqPrgr803GbtbMHKz2zIaPhZix6u0TkOU3uYftI09dFruvFCa7uXnkCbSsj7LCEJUfMyMbBaAnlGRdZUso/d0apPVK5KesQb7+UMrPCKSKQjpvABgDgFEN+KgrIxdp1p+QH2WuPMc444RvVjku8kgjyLHhu0azhPZ5zK+RwFteedYfOCaNSCQyp9UpLNNshIqyK+fhfrDRY6xOwg25Yu2SXveq84GI+JiPuLW+G5OFDkkuZGbZiVq07Vjjveck6eMwYY6NhlzWhqJAn2ZlSOoy5t+oqeYwGaMP6PT5p1KVH24kpEt9CyggnbHVtrvUzIlVLZSI+KNGZp7Elnhv+P394/ivSa1FbfRXC7QVocbUzdICTyxSD2O8FWp3VlxQaAvYc4V0c9spPe0ZiDCR4394hlY/0M2JoXJfGZe/Qdo3AMJdcvKFcG9RdXzhUgp7b+FnjI1qRvoL6nR6BmUB3KVKQ== X-Forefront-Antispam-Report: CIP:130.216.95.224; CTRY:NZ; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:uxcn13-ogg-e.UoA.auckland.ac.nz; PTR:natgate2-1.auckland.ac.nz; CAT:NONE; SFS:(4636009)(396003)(39850400004)(136003)(346002)(376002)(46966006)(36840700001)(110136005)(4326008)(54906003)(82740400003)(36906005)(70206006)(786003)(47076005)(70586007)(558084003)(86362001)(356005)(336012)(26005)(316002)(5660300002)(2616005)(7636003)(2906002)(8676002)(8936002)(82310400003)(478600001)(186003)(36860700001); DIR:OUT; SFP:1101 X-OriginatorOrg: cs.auckland.ac.nz X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Apr 2021 10:21:27.4356 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c83def6d-a903-4be3-e52c-08d8ff2f1070 X-MS-Exchange-CrossTenant-Id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d1b36e95-0d50-42e9-958f-b63fa906beaa; Ip=[130.216.95.224]; Helo=[uxcn13-ogg-e.UoA.auckland.ac.nz] X-MS-Exchange-CrossTenant-AuthSource: SG2APC01FT059.eop-APC01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SY4PR01MB6505 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: cs.auckland.ac.nz Content-Language: en-NZ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 10:21:41 -0000 Dave Crocker writes:=0A=0A>I was working at The Rand Cor= poration at the time and had been told that the=0A>Librarian there had magi= cal research skills.=0A=0AOok!=0A=0APeter.=0A From nobody Wed Apr 14 04:17:04 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F403A1B6F; Wed, 14 Apr 2021 04:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 wrWzr_N2kPDy; Wed, 14 Apr 2021 04:16:53 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7A53A1B72; Wed, 14 Apr 2021 04:16:52 -0700 (PDT) Received: from [192.168.46.152] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id DCAAE262; Wed, 14 Apr 2021 11:16:49 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Alan DeKok In-Reply-To: <5F841FEF-7985-424B-A925-336AC3265D8F@manchester.ac.uk> Date: Wed, 14 Apr 2021 07:16:48 -0400 Cc: Nico Williams , "Eliot Lear (elear)" , "art@ietf.org" , "saag@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3E679B11-0D23-4746-9938-D6532276690F@deployingradius.com> References: <20210413191937.GK9612@localhost> <5F841FEF-7985-424B-A925-336AC3265D8F@manchester.ac.uk> To: Stian Soiland-Reyes X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 11:16:58 -0000 On Apr 14, 2021, at 5:00 AM, Stian Soiland-Reyes = wrote: >=20 > I would say for this particular example of security logs you should = use ISO8601 (aka RFC3339), as it is more important when it = happened/expires internationally rather than what timezone it happened = in.=20 >=20 > In that case it should also be UTC-based or have an explicit timezone, = e.g. considering "Zero day" - which day? Add to that the problem that time zones change over time. That = information can be lost, or unknown to later consumers of the data. What we've learned in the AAA environment (ISP / Telco) is that there = are two reasonable choices for dates: 1) whatever you use locally, because it will never go off-system, and no = one else will ever see it 2) RFC 3339 Alan DeKok. From nobody Wed Apr 14 07:29:28 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95C53A0DEE; Wed, 14 Apr 2021 07:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.971 X-Spam-Level: X-Spam-Status: No, score=-3.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 JB1PkK2M28Ve; Wed, 14 Apr 2021 07:29:21 -0700 (PDT) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [131.111.8.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925793A0DE7; Wed, 14 Apr 2021 07:29:21 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from [84.9.76.236] (port=50969 helo=milebook.lan) by ppsw-42.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpsa (PLAIN:fanf2) (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1lWgW6-000h9P-7m (Exim 4.94) (return-path ); Wed, 14 Apr 2021 15:29:18 +0100 Date: Wed, 14 Apr 2021 15:29:17 +0100 From: Tony Finch To: "Eliot Lear (elear)" cc: Yakov Shafranovich , "art@ietf.org" , "saag@ietf.org" In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="0-1013978039-1618410376=:43284" Content-ID: <1c76cb8c-7674-e992-7841-7ede80ba9fc4@cam.ac.uk> Sender: Tony Finch Archived-At: Subject: Re: [saag] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 14:29:26 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1013978039-1618410376=:43284 Content-Type: text/plain; CHARSET=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <8ceef9dc-2521-14dc-fe49-3119c0b28bdc@cam.ac.uk> Eliot Lear (elear) wrote: > The question is whether you need something that is easy to parse or > something that is human readable and can be localized. It SEEMs that > this draft is intended to be human readable, and so 5322 doesn=E2=80=99t = seem > out of bounds. security.txt is also likely to be written by humans, and RFC 5322 dates have a lot of subtle details that are difficult to get right. For instance, what is a parser supposed to do if the day of week is inconsistent with the date? RFC 3339 is much simpler to write by hand. Tony. --=20 f.anthony.n.finch https://dotat.at/ Viking, North Utsire, South Utsire, Forties: Northerly or northwesterly 3 to 5, becoming variable 3 or less later. Slight or moderate. Showers. Good. --0-1013978039-1618410376=:43284-- From nobody Wed Apr 14 07:52:46 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46713A1137; Wed, 14 Apr 2021 07:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 a2U6kbaICcWi; Wed, 14 Apr 2021 07:52:40 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F9D53A112F; Wed, 14 Apr 2021 07:52:40 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id j6-20020a17090adc86b02900cbfe6f2c96so10974868pjv.1; Wed, 14 Apr 2021 07:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version; bh=qXL0ORFt4NqzcZTnlxk7vTMBEcCSCnr4DcNsRZyIm90=; b=ZPaVhy9NsidFwcLqztWz7W0K2OExgOY2HIsn+HoVRDZwDmyOdQFoSJfETsmSgRCMKe 9QRTZ0D0wI7c9H09bUq+sCDSP5jVPn1r/XhMs+JjBa7PakUKWJkE2VLBkUHypwJP/2GL y8M//T8QRDfY37Hjpzpwz458Vd35ph5GeDEhrIHOzlfw58C/yviVzb/ldeNAK/F92k4s A3mhALOROGJLK66vDNG3kQTR278x6TdrYlvyx+NLxUiBkluEv/nICAI+rhfp9yVPul2v gAtbASZLkotP6fZ4MHrUuWTCu9rbQs9xLe6UR9ErnHLzz75ojc4vQZB1+ejvoXyPLeNS fAdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version; bh=qXL0ORFt4NqzcZTnlxk7vTMBEcCSCnr4DcNsRZyIm90=; b=Q2JLsHxbaZI/ipmZEn/IFZ/xY6+8vltACv3nGW9i8/LyKfIi6UVINwPNpgWtyYsDFk YacRsk9Upnlm8NNiYRS/V1eqIk8R8XKtsXv8xtF1BIVXIvUJ9E9IsnCSIbVKWRWBnYwV UlHn7yapqLYq5fyvRSaO21Cp5sUdDy1ySbPEfET2FqYjng7q68PSeFuDJvat7/XAyLaX b8Ws0nK1yde85jDr2m+CMYNzH8ZYKiHiTwERz8kT4ayzYcquqonyR609ncEZBdhlK5eV SSPekKIotWyclG2Pir38TQjwPThZdWZvpDnR6noUM1BcrA2G2taoOuD90BMTGTBbp4pf Oy1g== X-Gm-Message-State: AOAM533mNsUpF8eiX48Vp33i1fl1G/gidw6WkLyOFkCM481umhB7h6zE KEbd6L8e+hEBbbcZ5zM001r8FyHWRGYb1A== X-Google-Smtp-Source: ABdhPJw+PujL4SB7Ir4ed5zqHUXru1P3IKR+qLB/Wn670xN+PMM7I+30UL5qz4NSCsA6/hN8pSpfNQ== X-Received: by 2002:a17:90a:9312:: with SMTP id p18mr3972199pjo.171.1618411958738; Wed, 14 Apr 2021 07:52:38 -0700 (PDT) Received: from [10.198.42.50] (c-71-231-216-10.hsd1.wa.comcast.net. [71.231.216.10]) by smtp.gmail.com with ESMTPSA id x11sm5348843pjh.0.2021.04.14.07.52.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Apr 2021 07:52:38 -0700 (PDT) Date: Wed, 14 Apr 2021 07:52:31 -0700 From: heather flanagan To: art@ietf.org, saag@ietf.org Message-ID: In-Reply-To: References: X-Readdle-Message-ID: fd0cf01a-af1f-4683-bc9a-a5c12f744b4a@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="607701b4_33d2971b_3b2" Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 14:52:45 -0000 --607701b4_33d2971b_3b2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Apr 13, 2021, 1:06 PM -0700, John C Klensin , wro= te: > > > --On Tuesday, April 13, 2021 19:00 +0000 =22Eliot Lear (elear)=22 > wrote: > > > The question is whether you need something that is easy to > > parse or something that is human readable and can be > > localized. It SEEMs that this draft is intended to be human > > readable, and so 5322 doesn't seem out of bounds. > > I suggest that even for reading by humans in 2021 --as distinct > from 1982 (R=46C 822) or 1977 (R=46C 733, which used day-month-year > ordering)-- the 5322 dates are not easy to understand and use... > at least unless one is an English speaker on this side of the > pond. It was quite wise at the time to spell out the month > name, thereby eliminating the ambiguity associated with, e.g., > 5/10/1977, but still bad news for someone who might think the > fourth month in the Gregorian calendar is, e.g., =D0=B0=D0=BF=D1=80=D0=B5= =D0=BB=D1=8F, > =D8=A3=D8=A8=D8=B1=D9=8A=D9=84 , or =E5=9B=9B=E6=9C=88. > > So I would argue that, for new protocols or data structures in > this increasingly global/ international Internet, and even for > elements visible to humans, sticking as close to ISO 8601 as > possible (with minimal profiling) is the Right Thing to Do. > Much too late now to change the 822/5322 format, turning > supplemental protocols for email into a gray area, but, for new > work, ISO 8601 formats are not just easier to parse but easier > to understand globally and in an unambiguous way. > > Just my opinion, of course. > > I=E2=80=99m going to +1 John=E2=80=99s advice as well,=C2=A0=C2=A0and sug= gest that if/when this group comes to a consensus on the topic, ask the R= =46C Editor to consider including the guidance in the style guide. Heather --607701b4_33d2971b_3b2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline


On Apr 13, 2021, 1:06 PM -0700, John C Klensin <= john-ietf=40jck.com>, wrote:


--On Tuesday, April 13, 2021 19:00 +0000 =22Eliot Lear (elear)=22
<elear=3D40cisco.com=40dmarc.ietf.org> wrote:

The question is whether you need something that is easy to
parse or something that is human readable and can be
localized. It SEEMs that this draft is intended to be human
readable, and so 5322 doesn't seem out of bounds.

I suggest that even for reading by humans in 2021 --as distinct
from 1982 (R=46C 822) or 1977 (R=46C 733, which used day-month-year
= ordering)-- the 5322 dates are not easy to understand and use...
at least unless one is an English speaker on this side of the
pond. It was quite wise at the time to spell out the month
name, thereby eliminating the ambiguity associated with, e.g.,
5/10/1977, but still bad news for someone who might think the
fourth month in the Gregorian calendar is, e.g., =D0=B0=D0=BF=D1=80=D0=B5= =D0=BB=D1=8F,
=D8=A3=D8=A8=D8=B1=D9=8A=D9=84 , or =E5=9B=9B=E6=9C=88.

So I would argue that, for new protocols or data structures in
this increasingly global/ international Internet, and even for
elements visible to humans, sticking as close to ISO 8601 as
possible (with minimal profiling) is the Right Thing to Do.
Much too late now to change the 822/5322 format, turning
supplemental protocols for email into a gray area, but, for new
work, ISO 8601 formats are not just easier to parse but easier
to understand globally and in an unambiguous way.

Just my opinion, of course.



I=E2=80=99m going to +1 John=E2=80=99s advice as well,&=23160;&=23160;and= suggest that if/when this group comes to a consensus on the topic, ask t= he R=46C Editor to consider including the guidance in the style guide.
Heather
--607701b4_33d2971b_3b2-- From nobody Wed Apr 14 09:14:37 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829DC3A1599; Wed, 14 Apr 2021 09:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 oZF1euI9Ki43; Wed, 14 Apr 2021 09:14:29 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80110.outbound.protection.outlook.com [40.107.8.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 219673A1596; Wed, 14 Apr 2021 09:14:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JfINeSB/6HTct7nq1uburscOv9rItPUvt+AzGeCQMYzG6JHxr7Frv083AT2KsPoIBHFsQis1/T8PFcDKlUYyw9TGxe/2HF/OaBcfJTrdLnf15QoqW7piMtqcL/5jGiFnDvqhNN5TTGXXnXBXxLlC1JT/Qga6dRxq4tG/fo/9Pbardl2WXmflIOx0OIg7YpNPuWmy5BfYPa3MbTu/ew9N/cn9P6ihy7ZgyLIrcnJEKVm5/kdvjWFfw1sjkF+os+lEjZqPmEuIxd/K0KMOpJi5/Z84mTtbT/QCL+kOtNGS8h5hwYB1c9DvSsFz3yBu0VT1mvvBjjZ9GBD2aaK1QbkI9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nWUh9PZcs/1/oeLJgVZzRg+HCpqd8poX+ZuX9Fg0Lw8=; b=MtpuLQ9RfW8W4Vds0H8ATTfws0rCYFWymHNcpMvw/inZrt6+qGDd0hFH9iuwUcLK2I12P5kOUHPPbccrAS+42Isp4hc0ZtNdhsmwpHpxzS9tFCHjf4MuPJKOWY5BzYU+VqFeOaI968u0WhCX2COPvSRmXHJNN9dY1gUtolb5LKI6s+baai2GROeOtHtcCIsJUNb7sTgHGn3nfn2IIWlsWTCtoUfJuN0UwxGi0I/zgg+lQLmeMR8IT5qaCYtBnDT0/zYCus1U8s4TSXIv7h/nldUH3Ve6M8x+Jnamwnto2M9o3prbdqi7xrSoebUjxe8g2Fus6+jj+qkowRQnxMraeQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nWUh9PZcs/1/oeLJgVZzRg+HCpqd8poX+ZuX9Fg0Lw8=; b=m+yzJMziEHv6bA+WygKtDZr5YibaLIbNmLPZXZAJ2PTDW6T6eG0GgSnm6PmcC4LJccBRXRxsOK3PPyhKu8XBDHQ+LpyxVY91b1rsZhnfWzmSVUvdsLOljGaK54PdxCZnSQ4OxIBIelreFpNHzao6nJiRtA/eOm/9EHMonPMMMsU= Received: from AM7PR07MB6248.eurprd07.prod.outlook.com (2603:10a6:20b:134::11) by AM5PR0701MB2290.eurprd07.prod.outlook.com (2603:10a6:203:f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.13; Wed, 14 Apr 2021 16:14:26 +0000 Received: from AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::543d:497d:ba3f:5576]) by AM7PR07MB6248.eurprd07.prod.outlook.com ([fe80::543d:497d:ba3f:5576%3]) with mapi id 15.20.4065.006; Wed, 14 Apr 2021 16:14:26 +0000 From: tom petch To: heather flanagan , "art@ietf.org" , "saag@ietf.org" Thread-Topic: [art] [saag] Date formats: RFC3339 vs. RFC 5322 Thread-Index: AQHXMT3L/jiiOWQUwEmp3EvZqxpFrKq0L5TY Date: Wed, 14 Apr 2021 16:14:26 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [86.155.147.182] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1c7819f2-74cd-4739-0927-08d8ff605fc7 x-ms-traffictypediagnostic: AM5PR0701MB2290: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EJA1KdhVlvCFZiU059f5GT5nIh/lxjQTVkgUb2QXu+N2pC8Av3XvYan93qygPafXXOeL2c9fIEWUx3i8kySKZerSoSmNiCOAfGGNdGRUpr8C1ElOZQmpWL700L4zp24/1h440VGWOZr+F0j76iV9FCRGeY6EMRAJIZiLTcYCrCfIjHlkxEEpRh93NK3QdWQxk9T0LK24KmlFwvwfDb4C2mdzkvRVWd5Hko0aDUD3Me2YJyKRHW8ypVhNj3uAYQe8iuprIrXmBKsIaYRdJp1JRyosYqwWdHtJR8QLugbjg8kUzg1B6NaTH1Rm4zenqfTo1nArKNYDECaZ3+Y+P28I5wh6/lX6TUdV6mBQPrzHq3+N2gs6gjNTyiU1oyvSbfH4q/NdHtEQ4B+ZbYnWNSCPWkqj4YaJEB8ksZT7tj+0/jGBzpDnc/YIbUo3wbD3VHENFWMcOSMF4JeSrcBq6vRvktggDO+nrr0wI8+3cpSMFdqXxY7MadQxHzEpK+NALkTDcVlVXcyihOtNBWIYaSek6mAD7hmHVhHF4UjcrAJ2IgRmUp2AjWlJyH/SKy++MEWE/wF3M6XEq79Od/hnVbCvwg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB6248.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(366004)(396003)(376002)(136003)(39860400002)(6506007)(83380400001)(186003)(7696005)(53546011)(26005)(8936002)(38100700002)(8676002)(52536014)(55016002)(91956017)(2906002)(66946007)(66476007)(316002)(64756008)(66446008)(66556008)(9686003)(110136005)(33656002)(71200400001)(86362001)(478600001)(122000001)(76116006)(66574015)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: =?utf-8?B?Vkk3VVQvTGdWZTduZU9xWE9CZHh5K0ZFeDBaVEplQ0dSNlBab1B3cWo1L2c4?= =?utf-8?B?MFBpMFN5NFNEVG5IWTE0YlAzdC9rVi9KK3NLUDRJRnNZYkhieWRFV0MvNFVT?= =?utf-8?B?SjFMVmpQRVc2OFpJeWNOa2l1elh1bFUydm9GckRGdWNNTmx2TjVKdzNuNWFy?= =?utf-8?B?UWZuM3lwaUVYNklsNWNVdDF3VTExK0tZTUZrZ3JUVHRNUFJ0UkVqbTVSQTIr?= =?utf-8?B?MzRtR25XamlmdjY5R1Z6QWpCekU5aGZwVkFJNHJRQ25mYmpsbTFDYS95ZllD?= =?utf-8?B?MkdDNTBmOFNFUm8wZE5Wa2RpWFlnMDhzY1V3enEvN05lZHkxd0VrWW85TGVk?= =?utf-8?B?U3BEaFNhZE1HcGNna095SGZrQ2NPdFk4L2gwNTlvT1J0V0xrRTVRY1BWZDdV?= =?utf-8?B?QTlsVWF2bVQvYnRXWHpLeHdKYm5OenE2RHNpLzJ5bEJUZnBiZVI2WitjZjNk?= =?utf-8?B?dWxVdHQrejBNREpRSk5zZlpwN1d2MXNOdVBmTXA1SDlrNDRzSzE4UXNzTWJz?= =?utf-8?B?cmQrVy9tbGduZ0RuNkNoOWFvekJnc0x3MXRBNkp4VzNUVG9JSDNwU2RjYWd4?= =?utf-8?B?b1p2bGxXcmJaaGFnSTVwTTVRWktJSGJTbGxkR3hLVTNPbGRwTUpEeCtOZ3BD?= =?utf-8?B?a056cFhXbTFBY1VWaWJmVy9yTWlHZUY3VGFuc1l2SnBDanZ4SmhYbXVDWCt2?= =?utf-8?B?ZWRaYVkrTFgrRjRwTFBKOXFWdFRiNjNtRUtMemhpa3d3T2o3MkpoQlA2Tk5W?= =?utf-8?B?RCttdjN4VUNFbi94WWxybFFGcVcvMTVkQWpuS3ZUeGd0cEtNTUdoeWhISHFV?= =?utf-8?B?SklYQXhHZjcxTWV0TDVSSVB6cnpOVWw2eFJwL1VZVkJHRkdUaHhDbWhObEFv?= =?utf-8?B?R0k5ODFsbUZycUFOd0ExT0tlbHQ1VmxWSkFkWHVzdGQwS1lraHVmaDRmTzl1?= =?utf-8?B?a1Vjd2NGS0dXUGVjQXRrdEtyQjNGV3BpbkM4cFFQQUg1OEc1T3F0ZU5vemMr?= =?utf-8?B?L1dJTFI3T2VGbHMyRUp6WW9iUzhXclAweXRyamtsL2d6MSt0U00xRkRkSWQ0?= =?utf-8?B?RW42anBwbGwwWGhUWm5DQlJSMDRZaXdHR0kxZUtCMGpCL3QxeU9oM3drT1dV?= =?utf-8?B?U2NEMldTd1NhV1NQbWRKVGQwRVFqRzRIcWtoZ2pEZXkyYkJqcHJrWWt4aHRx?= =?utf-8?B?dFE5S1F6MVQ2WkdxUTNlNGc4QW5LckZIaUNzWDU3bXZJSnhhcklnYlNlYWRJ?= =?utf-8?B?SnlvcmlwcWdJTTN4R0RRSjM1ME41czFSZzlIYkYxYWN0dDRLNFRYdmh5WmlQ?= =?utf-8?B?eTNVR2RvcXAvTTJ6eWRGekdQUlFacjIwMUczcEpXYTNXWHZuTHQ5N1c1YzRs?= =?utf-8?B?NC8yWUxPWUs2UGxGOUpqZDdVaGhYeXFZKy9RK1djOFRLcDZlODdHNzlhMC9p?= =?utf-8?B?cGRoaUJwcExzL3NMc1NkNTBUU2Qyd2FNcnJmY285bENHK21pTGN0cWRYSVg4?= =?utf-8?B?Rk1iQnAzOG5iSUZsRnJDWXFBOXR4S0VaUmVybkx6RXUybDhKVGpiTWFpZ3JS?= =?utf-8?B?WGJmbldXTmlHQWhPbnY4RlB4MnV5c2NCYWR2WFpmNDNGb1QyNjBCaFJMNGM1?= =?utf-8?B?ck56Q0dQSEJXNTJNWlJiK0V1NU5tSGZ0cnRSeHZUc0Z3ZndsUlBuWHVBWGVG?= =?utf-8?B?dkdyLzRlQmVVSlB3VXE1djNVWFp2VUMweVVOWjE5MWFDTktkbmxqaXFHdEs2?= =?utf-8?Q?Has5GA5Oui9DJZcZAc=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM7PR07MB6248.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1c7819f2-74cd-4739-0927-08d8ff605fc7 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Apr 2021 16:14:26.0622 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: inRM9E4Ge1ybgwohSeVNi3YGraZZy+tPPqLYpqYuQiJQHW0kRYshcgsGs/WFJ01J8obKJ/vE7HGnLkiVaptc9Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2290 Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 16:14:34 -0000 RnJvbTogYXJ0IDxhcnQtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIGhlYXRoZXIgZmxh bmFnYW4gPGhsZmxhbmFnYW5AZ21haWwuY29tPgpTZW50OiAxNCBBcHJpbCAyMDIxIDE1OjUyCgpP biBBcHIgMTMsIDIwMjEsIDE6MDYgUE0gLTA3MDAsIEpvaG4gQyBLbGVuc2luIDxqb2huLWlldGZA amNrLmNvbT4sIHdyb3RlOgoKCi0tT24gVHVlc2RheSwgQXByaWwgMTMsIDIwMjEgMTk6MDAgKzAw MDAgIkVsaW90IExlYXIgKGVsZWFyKSIKPGVsZWFyPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3Jn PiB3cm90ZToKClRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHlvdSBuZWVkIHNvbWV0aGluZyB0aGF0 IGlzIGVhc3kgdG8KcGFyc2Ugb3Igc29tZXRoaW5nIHRoYXQgaXMgaHVtYW4gcmVhZGFibGUgYW5k IGNhbiBiZQpsb2NhbGl6ZWQuIEl0IFNFRU1zIHRoYXQgdGhpcyBkcmFmdCBpcyBpbnRlbmRlZCB0 byBiZSBodW1hbgpyZWFkYWJsZSwgYW5kIHNvIDUzMjIgZG9lc24ndCBzZWVtIG91dCBvZiBib3Vu ZHMuCgpJIHN1Z2dlc3QgdGhhdCBldmVuIGZvciByZWFkaW5nIGJ5IGh1bWFucyBpbiAyMDIxIC0t YXMgZGlzdGluY3QKZnJvbSAxOTgyIChSRkMgODIyKSBvciAxOTc3IChSRkMgNzMzLCB3aGljaCB1 c2VkIGRheS1tb250aC15ZWFyCm9yZGVyaW5nKS0tIHRoZSA1MzIyIGRhdGVzIGFyZSBub3QgZWFz eSB0byB1bmRlcnN0YW5kIGFuZCB1c2UuLi4KYXQgbGVhc3QgdW5sZXNzIG9uZSBpcyBhbiBFbmds aXNoIHNwZWFrZXIgb24gdGhpcyBzaWRlIG9mIHRoZQpwb25kLiBJdCB3YXMgcXVpdGUgd2lzZSBh dCB0aGUgdGltZSB0byBzcGVsbCBvdXQgdGhlIG1vbnRoCm5hbWUsIHRoZXJlYnkgZWxpbWluYXRp bmcgdGhlIGFtYmlndWl0eSBhc3NvY2lhdGVkIHdpdGgsIGUuZy4sCjUvMTAvMTk3NywgYnV0IHN0 aWxsIGJhZCBuZXdzIGZvciBzb21lb25lIHdobyBtaWdodCB0aGluayB0aGUKZm91cnRoIG1vbnRo IGluIHRoZSBHcmVnb3JpYW4gY2FsZW5kYXIgaXMsIGUuZy4sINCw0L/RgNC10LvRjywK2KPYqNix 2YrZhCAsIG9yIOWbm+aciC4KClNvIEkgd291bGQgYXJndWUgdGhhdCwgZm9yIG5ldyBwcm90b2Nv bHMgb3IgZGF0YSBzdHJ1Y3R1cmVzIGluCnRoaXMgaW5jcmVhc2luZ2x5IGdsb2JhbC8gaW50ZXJu YXRpb25hbCBJbnRlcm5ldCwgYW5kIGV2ZW4gZm9yCmVsZW1lbnRzIHZpc2libGUgdG8gaHVtYW5z LCBzdGlja2luZyBhcyBjbG9zZSB0byBJU08gODYwMSBhcwpwb3NzaWJsZSAod2l0aCBtaW5pbWFs IHByb2ZpbGluZykgaXMgdGhlIFJpZ2h0IFRoaW5nIHRvIERvLgpNdWNoIHRvbyBsYXRlIG5vdyB0 byBjaGFuZ2UgdGhlIDgyMi81MzIyIGZvcm1hdCwgdHVybmluZwpzdXBwbGVtZW50YWwgcHJvdG9j b2xzIGZvciBlbWFpbCBpbnRvIGEgZ3JheSBhcmVhLCBidXQsIGZvciBuZXcKd29yaywgSVNPIDg2 MDEgZm9ybWF0cyBhcmUgbm90IGp1c3QgZWFzaWVyIHRvIHBhcnNlIGJ1dCBlYXNpZXIKdG8gdW5k ZXJzdGFuZCBnbG9iYWxseSBhbmQgaW4gYW4gdW5hbWJpZ3VvdXMgd2F5LgoKSnVzdCBteSBvcGlu aW9uLCBvZiBjb3Vyc2UuCgoKCknigJltIGdvaW5nIHRvICsxIEpvaG7igJlzIGFkdmljZSBhcyB3 ZWxsLCAgYW5kIHN1Z2dlc3QgdGhhdCBpZi93aGVuIHRoaXMgZ3JvdXAgY29tZXMgdG8gYSBjb25z ZW5zdXMgb24gdGhlIHRvcGljLCBhc2sgdGhlIFJGQyBFZGl0b3IgdG8gY29uc2lkZXIgaW5jbHVk aW5nIHRoZSBndWlkYW5jZSBpbiB0aGUgc3R5bGUgZ3VpZGUuCgoKPHRwPgp3aGljaCBJIG5vdGUg aXMgbm90IHRoZSBmb3JtYXQgdGhhdCB3ZSBhcmUgYWxsb3dlZCB0byB1c2UgaW4gYW4gUkZDIHdo ZW4gaXQgY29tZXMgdG8gcmVmZXJlbmNlczotKAoKVG9tIFBldGNoCgoKCkhlYXRoZXIK From nobody Wed Apr 14 09:18:18 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA063A15C1; Wed, 14 Apr 2021 09:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 08trfZmSBAzx; Wed, 14 Apr 2021 09:18:12 -0700 (PDT) Received: from smtp.ucolick.org (hunan.ucolick.org [128.114.23.233]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8353A15BF; Wed, 14 Apr 2021 09:18:11 -0700 (PDT) Received: from smtp.ucolick.org (localhost [127.0.0.1]) by smtp.ucolick.org (Postfix) with ESMTP id A339327DF; Wed, 14 Apr 2021 09:18:10 -0700 (PDT) Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183]) by smtp.ucolick.org (Postfix) with ESMTP id 9ECF82742; Wed, 14 Apr 2021 09:18:10 -0700 (PDT) Received: from geneva.ucolick.org (localhost [127.0.0.1]) by geneva.ucolick.org (Postfix) with ESMTP id 8C0EA6BF; Wed, 14 Apr 2021 09:18:10 -0700 (PDT) Received: (from sla@localhost) by geneva.ucolick.org (8.14.7/8.14.7/Submit) id 13EGI8Pt021824; Wed, 14 Apr 2021 09:18:08 -0700 Date: Wed, 14 Apr 2021 09:18:08 -0700 From: Steve Allen To: Alan DeKok Cc: Stian Soiland-Reyes , Nico Williams , "Eliot Lear (elear)" , "saag@ietf.org" , "art@ietf.org" Message-ID: <20210414161808.GC19804@ucolick.org> References: <20210413191937.GK9612@localhost> <5F841FEF-7985-424B-A925-336AC3265D8F@manchester.ac.uk> <3E679B11-0D23-4746-9938-D6532276690F@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3E679B11-0D23-4746-9938-D6532276690F@deployingradius.com> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 16:18:16 -0000 On Wed 2021-04-14T07:16:48-0400 Alan DeKok hath writ: > What we've learned in the AAA environment (ISP / Telco) is that there are two reasonable choices for dates: > > 1) whatever you use locally, because it will never go off-system, and no one else will ever see it > > 2) RFC 3339 I offer that every datetime should be ISO 8601-like except in cases where bureaucratic requirements demand something different. -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m From nobody Wed Apr 14 10:05:26 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71DDE3A17A1; Wed, 14 Apr 2021 10:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 AxD77ZNB2Qq4; Wed, 14 Apr 2021 10:05:16 -0700 (PDT) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178B73A17A9; Wed, 14 Apr 2021 10:05:15 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id em21-20020a17090b0155b029014e204a81e6so3304006pjb.1; Wed, 14 Apr 2021 10:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version; bh=kBwTJd+dF5U9Mzd2fIreMppj7xhJkpw7PbTg4G2dAMY=; b=nSy+GHaI7zVSHpMJ66YsA8Q1qYt30TdcGzjShysnfU5MFDZjqhiNpE5Hm+aacsxq0y VDbfXgDNddqrGzGkANbGvgOtNkr0k3poUXSQoIpmROrssh+Op2DNZxrKMEFHIVlaGQVg PBVzfsMmmFbQTZ5VV1tKm8CtkwWxKjGuqC3s3U772hik+6Oxi8hSwK2OVFwFhcSHn7iH RhE6/QoRnBNjCZ2jiGlVNFfolyMLOzxdeuZ1KiYcTNEZaQCZnE7GxjJkDkbrzQOE8fKC D6EGVj28g+o6CwrtRBz9aq+xk58tKq9Xgb2Ih7/ad/TeLzmCcudfHx0JOniSTezqlDc5 qgTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version; bh=kBwTJd+dF5U9Mzd2fIreMppj7xhJkpw7PbTg4G2dAMY=; b=W6mtC+mpLxde+7r25Vze5HDN7MOkfXxDYoRZqlBajAsDfn979Vy+PDzGLqTPme5267 f5yH8WgIOn5mv45oP4u+xvOBTONEUIG9Hr4Qvq96DKbas3DDL0ShuBeH+0Y40y3ddl7+ f5wcJjWM0kU7d3bchTqJFSjfXDCrUT12kDgYZAC6O8jAOOGw/tdFMV9RW+AjHMskxxox Fi+FV6qzoWu5Asf7ZxgeaP7+JDdeQHdfSoHlbZ9rxogEAmsjqd9I/4TqzhqLbCCzP1rD t8Sm/GbIKvGR5ciayWtTSz/TCCSps402DraZMQeFX2Ai/7k/TgaOfkCCJzKQbk4tUz+N QjJw== X-Gm-Message-State: AOAM532u7aEbP3I7oyjfCaOZfPcGjKz/Qw+CFDDiwrIU7masmac37Ph+ fPxxNhvrpLT5dTusN/2OiaVcSyJG7t4G4A== X-Google-Smtp-Source: ABdhPJyx2tceQyEbhIdh5oHHiTchNV+HgfT0nNpXlV8b+9mKJIwk2gPRM8bmjHqjLimdlwy4epzZwg== X-Received: by 2002:a17:90a:ec09:: with SMTP id l9mr4644572pjy.141.1618419914609; Wed, 14 Apr 2021 10:05:14 -0700 (PDT) Received: from [10.198.42.50] (c-71-231-216-10.hsd1.wa.comcast.net. [71.231.216.10]) by smtp.gmail.com with ESMTPSA id u7sm31294pjx.8.2021.04.14.10.05.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Apr 2021 10:05:13 -0700 (PDT) Date: Wed, 14 Apr 2021 10:05:07 -0700 From: heather flanagan To: "=?utf-8?Q?art=40ietf.org?=" , "=?utf-8?Q?saag=40ietf.org?=" , tom petch Message-ID: <9dcae7aa-369c-401f-87fc-dabb581a1f3a@Spark> In-Reply-To: References: X-Readdle-Message-ID: 9dcae7aa-369c-401f-87fc-dabb581a1f3a@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="607720c8_412d9f39_3b2" Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 17:05:22 -0000 --607720c8_412d9f39_3b2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Apr 14, 2021, 9:14 AM -0700, 40cisco.com=40dmarc.ietf.org, wrote: > > I=E2=80=99m going to +1 John=E2=80=99s advice as well, and suggest that= if/when this group comes to a consensus on the topic, ask the R=46C Edit= or to consider including the guidance in the style guide. > > > which I note is not the format that we are allowed to use in an R=46C w= hen it comes to references:-( Ah, yes, the format of bibliographic references is its own special beasti= e. That=E2=80=99s driven by the Chicago Manual of Style format. I=E2=80=99= d suggest letting that particular sleeping dog alone, and focus on what s= hould be standard in the body of the document for the material targeted t= o humans. If you really want another thing to poke at, complete the discu= ssion with consensus on what should be standard for machine-readable (I h= onestly don=E2=80=99t know if there=E2=80=99s already consensus on that o= r not). Heather --607720c8_412d9f39_3b2 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline


On Apr 14, 2021, 9:14 AM -0700, 40cisco.com=40dmarc= .ietf.org, wrote:

I=E2=80=99m going to +1 John=E2=80=99s advice as well, and suggest that i= f/when this group comes to a consensus on the topic, ask the R=46C Editor= to consider including the guidance in the style guide.

<tp>
which I note is not the format that we are allowed to use in an R=46C whe= n it comes to references:-(

Ah, yes, the format of bibliographic references is its own special beasti= e. That=E2=80=99s driven by the Chicago Manual of Style format. I=E2=80=99= d suggest letting that particular sleeping dog alone, and focus on what s= hould be standard in the body of the document for the material targeted t= o humans. If you really want another thing to poke at, complete the discu= ssion with consensus on what should be standard for machine-readable (I h= onestly don=E2=80=99t know if there=E2=80=99s already consensus on that o= r not).&=23160;

Heather
--607720c8_412d9f39_3b2-- From nobody Wed Apr 14 12:37:15 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BAB3A1CF6; Wed, 14 Apr 2021 12:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 sqtgs27Fkp8f; Wed, 14 Apr 2021 12:37:04 -0700 (PDT) Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 741213A1CF1; Wed, 14 Apr 2021 12:37:04 -0700 (PDT) Received: by mail-yb1-f170.google.com with SMTP id o10so23418045ybb.10; Wed, 14 Apr 2021 12:37:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=w9ai63aRpL2q0ywtr3rhR4Cit7nJMxm+RarrPA+po8E=; b=A5bFtVI1rLokr0lFdkRxg3qyH4nUoWTYQp+fHunFfI/uPPFNttxWlGrPQddCKZNN9b Cy/EhbJLRQeQ9ecsUvjLxI8PRg3/CNnXEWq0z1dDB7TGJishoqX0BsqRk5LCxzl25Uc8 W7LMAQADLTymKzl+NqoLCjTRcCGe+tEb//M6x7TcSqkJnCFPavY3bIjfyJbPSNwgiynL D1HiehA/iPpytAXzlYpmPcOYtDWVrhMxLzkRD3TjpPd8dhmgNtHFc8s+wBEZWuFI8J8u 58vtHaog3SNSbxB+p6KuUq30gmyOgQiKZ22gZf5aCdHuW0/lWldrQXFIPll4y0qXCXJp eu1Q== X-Gm-Message-State: AOAM530Zpc5K9nKFCOPl3dCU0WfS55VqkDlvfjlNq/NTYKJJAYcbgp8w QqsmxncTb0g9KdYfuhMRn/lQihwYsUnwRHhw8WQbYpbt X-Google-Smtp-Source: ABdhPJxlmrtQD/ZeYxzgMPrTOd7oTpDUn7QiR4aFeS8JBqTTccnVGG+tMbBDcm1QjUPHVyMYqkltDvbdWW/zn0aPKgA= X-Received: by 2002:a25:4c7:: with SMTP id 190mr11178534ybe.480.1618429023451; Wed, 14 Apr 2021 12:37:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Phillip Hallam-Baker Date: Wed, 14 Apr 2021 15:36:50 -0400 Message-ID: To: John C Klensin Cc: "Eliot Lear (elear)" , Yakov Shafranovich , "General Area Review Team (gen-art@ietf.org)" , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000097e0f05bff3df7c" Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 19:37:09 -0000 --000000000000097e0f05bff3df7c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am also going to strongly +1 John here. At this point, the only question I would consider in a protocol is the choice of UTC or TAI. Unfortunately, the method of platform handling of UTC means that all date time values recorded in electronic documents are inherently ambiguous, a state of affairs that will persist until the cretinous notion of leap seconds is done away with. On Tue, Apr 13, 2021 at 4:06 PM John C Klensin wrote: > > > --On Tuesday, April 13, 2021 19:00 +0000 "Eliot Lear (elear)" > wrote: > > > The question is whether you need something that is easy to > > parse or something that is human readable and can be > > localized. It SEEMs that this draft is intended to be human > > readable, and so 5322 doesn't seem out of bounds. > > I suggest that even for reading by humans in 2021 --as distinct > from 1982 (RFC 822) or 1977 (RFC 733, which used day-month-year > ordering)-- the 5322 dates are not easy to understand and use... > at least unless one is an English speaker on this side of the > pond. It was quite wise at the time to spell out the month > name, thereby eliminating the ambiguity associated with, e.g., > 5/10/1977, but still bad news for someone who might think the > fourth month in the Gregorian calendar is, e.g., =D0=B0=D0=BF=D1=80=D0=B5= =D0=BB=D1=8F, > =D8=A3=D8=A8=D8=B1=D9=8A=D9=84 , or =E5=9B=9B=E6=9C=88. > > So I would argue that, for new protocols or data structures in > this increasingly global/ international Internet, and even for > elements visible to humans, sticking as close to ISO 8601 as > possible (with minimal profiling) is the Right Thing to Do. > Much too late now to change the 822/5322 format, turning > supplemental protocols for email into a gray area, but, for new > work, ISO 8601 formats are not just easier to parse but easier > to understand globally and in an unambiguous way. > > Just my opinion, of course. > > > john > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art > --000000000000097e0f05bff3df7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I a= m also going to strongly=C2=A0+1 John here.

At this point, the only question I would consider in a= protocol is the choice of UTC or TAI.=C2=A0

Unfortunately, the method of platform handling of UTC = means that all date time values recorded in electronic documents are inhere= ntly ambiguous, a state of affairs that will persist until the cretinous no= tion of leap seconds is done away with.




<= /div>

On Tue, Apr 13, 2021 at 4:06 PM John C Klensin <john-ietf@jck.com> wrote:


--On Tuesday, April 13, 2021 19:00 +0000 "Eliot Lear (elear)"
<elear=3D40cisco.com@dmarc.ietf.org> wrote:

> The question is whether you need something that is easy to
> parse or something that is human readable and can be
> localized.=C2=A0 It SEEMs that this draft is intended to be human
> readable, and so 5322 doesn't seem out of bounds.

I suggest that even for reading by humans in 2021 --as distinct
from 1982 (RFC 822) or 1977 (RFC 733, which used day-month-year
ordering)-- the 5322 dates are not easy to understand and use...
at least unless one is an English speaker on this side of the
pond.=C2=A0 It was quite wise at the time to spell out the month
name, thereby eliminating the ambiguity associated with, e.g.,
5/10/1977, but still bad news for someone who might think the
fourth month in the Gregorian calendar is, e.g., =D0=B0=D0=BF=D1=80=D0=B5= =D0=BB=D1=8F,
=D8=A3=D8=A8=D8=B1=D9=8A=D9=84 , or =E5=9B=9B=E6=9C=88.

So I would argue that, for new protocols or data structures in
this increasingly global/ international Internet, and even for
elements visible to humans, sticking as close to ISO 8601 as
possible (with minimal profiling) is the Right Thing to Do.
Much too late now to change the 822/5322 format, turning
supplemental protocols for email into a gray area, but, for new
work, ISO 8601 formats are not just easier to parse but easier
to understand globally and in an unambiguous way.

Just my opinion, of course.


=C2=A0 =C2=A0 john

_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art
--000000000000097e0f05bff3df7c-- From nobody Wed Apr 14 16:55:15 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4A03A2539; Wed, 14 Apr 2021 16:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 k_bIKUH474dY; Wed, 14 Apr 2021 16:55:10 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BE3F3A2533; Wed, 14 Apr 2021 16:55:09 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 13ENswHe001894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Apr 2021 19:55:03 -0400 Date: Wed, 14 Apr 2021 16:54:57 -0700 From: Benjamin Kaduk To: Nico Williams Cc: Paul Hoffman , art@ietf.org, saag@ietf.org Message-ID: <20210414235457.GY79563@kduck.mit.edu> References: <901F4345-91B6-42CA-9F68-27DB4C539F3D@vpnc.org> <20210413200101.GL9612@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210413200101.GL9612@localhost> Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 23:55:13 -0000 On Tue, Apr 13, 2021 at 03:01:02PM -0500, Nico Williams wrote: > On Tue, Apr 13, 2021 at 12:30:21PM -0700, Paul Hoffman wrote: > > Given that the date in that section of that draft is meant to be machine > > parsed, choosing RFC 5322 (ne 822) date formats is a particularly bad idea, > > given the existence of RFC 3339. > > I mean, strptime() can handle both, and since everything is written in C > (which is why we so badly need security.txt!), that's enough. But yes, > ISO 8601 is much easier to parse. And it will be even easier to compare > dates if security.txt ends up using Zulu time, since then plain string > comparison (even memcmp()!) is enough. > > Thinking about implementation... I suddenly wonder why security.txt > should have expiration instead of a TTL. I'm pretty sure what's really > intended is that I not cache security.txt files too long so that they > can be updated. Indeed, sections 3.5.5 and 6.3 make it clear that this > is about caching. > > An optional publication time (ISO 8601), and a required TTL measured in > hours or days would be more than sufficient, and maybe superior to a > notAfter. Unless the point of `Expires` is also to force the publisher > to keep security.txt up to date. Yes, that. We got a lot of LC feedback that (okay, I might be exaggerating for effect) the future Internet would be littered with piles of stale security.txt files to the extent that the mechanism would be rendered useless due to the expectation of stale content. Adding "Expires" serves as something of a "dead-man's switch" that lets stale content age out relatively gracefully. > Implementation-wise, I see a few ways in which I would handle `Expires` > information: > > 1) Comparison. E.g., to determine if a security.txt is stale, or to > sort/index/search archived security.txt files, in which case I'd have > two choices: > > 1a) if the format is ISO 8601 zulu, then format current time then > string compare, > 1b) parse the `Expires` into local time of day form and compare to > current time. > > (1a) is simpler, but only works for ISO 8601 Zulu times. > > 3) Authoring/production of security.txt files, where I only need to > format time, not parse it. > > Clearly it's easier to only have to format time and never have to parse > it. > > That said, strptime() and similar are widely available and easy enough > to use, so I do think there's an readability argument to make. But ISO > 8601 is still easier to read than RFC 5322 time, especially for > non-English speakers. And I think the authors have a clear answer for what to do here. Thanks to everyone for the feedback. -Ben From nobody Wed Apr 14 19:33:32 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2353A2A3D for ; Wed, 14 Apr 2021 19:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.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 15laNBsvjjV3 for ; Wed, 14 Apr 2021 19:33:25 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5C93A2A3F for ; Wed, 14 Apr 2021 19:33:25 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id b136-20020a1c1b8e0000b029012c69da2040so4122096wmb.1 for ; Wed, 14 Apr 2021 19:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=1pIirE+Jo0UbrZ8VnGdAKmJoCjaKGkK9OPSb4G791+Y=; b=ggYEdk+3GWXyxJ09hB02Dby7SI271yoxV7w0kjmKYSGGKpVcvWj8pBzBdv+yuDTf/k n7HN+kM4YlWezQ5JvDj4yEHhFu551G6m0qVq8E9UfOTto0bcZEIBHE4ElLuIxzwaH8W0 P5URFHYEp/16gIIolHqXlV04iHfUcBUuzDmFJ5pKwggFvxQWIo6tYRaMyj203Nn6T9ZM BN/Ebp0SY9aykmcrwpNDsClK7yw9FuywSO4KJUse6N1I5oYDnxH+Ox8tR3qhwodF6RGm 5NApmun3mHNGxx9lyAGYaCwsSYtXvQnKxOVUXErDbcNgoWKEI8ufWtPkNr4DObgg41su u0Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1pIirE+Jo0UbrZ8VnGdAKmJoCjaKGkK9OPSb4G791+Y=; b=kWpV3Or7OT68cx8R3crYDGzKkrV0LhXLGH/2hoS+VeC9rG+poitRauGoDU8dagcvd4 0hURAso2yTZUM3iQNhmCgudfwxH0Pd6R3qZPU9SkQzkujULpmc+vGvpNk/j9UZisII4K GsWo9s8G/K8Trn2o0p4jgnacEWL5GJ3Jfk90S9cgTWn3L1encK99+v72czvpFrVFxZsm p+R4n6Y8kSREl6TOn2ONABtF6E2mPLShmB2wEL4YNpArsj3E5k+lR02UrkhTTPaJTw+E K62ioIeaCyazxiEs7wLoOS/qDntF1W1hqKzvLZSVV5oHgTwEUgnBTZ/0+pKq1ODDmsgC Sj7A== X-Gm-Message-State: AOAM533SRtAZpLQFZie+A4X191Si68YFVnAGZlzCcLVysV0FIK23KX8A nmqcWvj84uJ0ap0zthe/QrPGDIZU71QgrGNXJ+RyDKsBMKEddQ== X-Google-Smtp-Source: ABdhPJw5CDZKXa7k/fDaEjpmojTZYfG54aH+4V/DBthXcaKYCriLeXtt36q8mdnFsezrBkQ1W+k2HfA7/rcEjoL8P7M= X-Received: by 2002:a05:600c:20c:: with SMTP id 12mr726465wmi.138.1618454002049; Wed, 14 Apr 2021 19:33:22 -0700 (PDT) MIME-Version: 1.0 From: Yakov Shafranovich Date: Wed, 14 Apr 2021 22:32:47 -0400 Message-ID: To: saag@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] Best practices for verifying authenticity of OpenPGP keys? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 02:33:31 -0000 (this is another issue that was recently raised by an implementer of "security.txt") What is the current best practice for verifying whether a given OpenPGP key is real and valid? Not clear if Web of Trust is widely used anymore, PKI isn't applicable and public keyservers have been targeted in the past by poisoning attacks. To me, the most common approach seems to be publishing the keys or their fingerprints on the web where they can be retrieved with TLS, essentially relying on public PKI. This appears to be the approach used by OpenSSL, Tails, Tor, etc. See: https://www.openssl.org/community/omc.html https://tails.boum.org/install/mac/usb-download/index.en.html https://support.torproject.org/tbb/how-to-verify-signature/ Thanks From nobody Thu Apr 15 03:18:23 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84153A19BC for ; Thu, 15 Apr 2021 03:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=josefsson.org header.b=SLxtVLJK; dkim=pass (2736-bit key) header.d=josefsson.org header.b=Yq5YmO9Z 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 nZPY1Vll7MyY for ; Thu, 15 Apr 2021 03:18:16 -0700 (PDT) Received: from uggla.sjd.se (uggla.sjd.se [IPv6:2001:9b1:8633::107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4BE03A19B7 for ; Thu, 15 Apr 2021 03:18:14 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=ed2101; h=Content-Type:MIME-Version:Message-ID:In-Reply-To :Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding :Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=miEDslKc2Hqh+WPXNZvU4/c68Vw1RSnwTls/252brck=; t=1618481895; x=1619691495; b=SLxtVLJKU5WbEyiXsVnq+qggi95+rA1VOIy0C+L0LMO8NYzBBla1wf6oCCizdU+4yLHIvefY8T bLrp9Y6/eyBg==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=rsa2101; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=miEDslKc2Hqh+WPXNZvU4/c68Vw1RSnwTls/252brck=; t=1618481895; x=1619691495; b=Yq5YmO9Z139QBdkg7E8I29ZNfpv9ooMW51RtOpYFUYKHKDQ+i3It0WRMYRWGiAShqrgbrM/XHX 8j8q/Hv4btsFGpPsyFYKEaoxHGaGrEIAdPkWDvMDoy+tP6DlYvr57FozGyN5+ZJP6AUCumrYPbYL0 D8Z7v9Q8lWHQhawyttk4NCn/2HaNzOFl8fMZyYqIzPn8+7TcLINg33FbizG0FvjnJneAjx92j2kmj ZUW+MahFbe/OykpHJpH2fSjkAdZDKFU/FcJYLl9VkJBYG/KgA6zRGfZFRtQNlBIb+KFJY4Y2Phy8k +7HzA3dQQQL3WkaZn7Wl8cHzoOoy3yXU2v86//4c3Y4OXzfJho1k3AOwmHAtx/eDDDqHwXxGnYVKS QmcNgIFl4k0vBztq+WvGfaLrsjOxy8S+Rwtfq2mln08UezYSRqsVu1ZRZKcxDAa3/W4Rogl722 ; Received: from [2001:9b1:41ac:ff00:c14a:d2e3:44b0:37b7] (port=58824 helo=latte) by uggla.sjd.se with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lWz4W-00018e-Tq; Thu, 15 Apr 2021 10:18:04 +0000 From: Simon Josefsson To: Yakov Shafranovich Cc: saag@ietf.org References: OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt X-Hashcash: 1:22:210415:saag@ietf.org::dqPg8hK/90PEdN2W:HjQC X-Hashcash: 1:22:210415:yakov@nightwatchcybersecurity.com::9ZFdw4UBp3k4IHpK:khFQ Date: Thu, 15 Apr 2021 12:18:02 +0200 In-Reply-To: (Yakov Shafranovich's message of "Wed, 14 Apr 2021 22:32:47 -0400") Message-ID: <87y2djq2at.fsf@latte.josefsson.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [saag] Best practices for verifying authenticity of OpenPGP keys? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 10:18:22 -0000 --=-=-= Content-Type: text/plain Yakov Shafranovich writes: > (this is another issue that was recently raised by an implementer of > "security.txt") > > What is the current best practice for verifying whether a given > OpenPGP key is real and valid? Not clear if Web of Trust is widely > used anymore, PKI isn't applicable and public keyservers have been > targeted in the past by poisoning attacks. > > To me, the most common approach seems to be publishing the keys or > their fingerprints on the web where they can be retrieved with TLS, > essentially relying on public PKI. This appears to be the approach > used by OpenSSL, Tails, Tor, etc. Indeed, see: https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-11 /Simon > See: > https://www.openssl.org/community/omc.html > https://tails.boum.org/install/mac/usb-download/index.en.html > https://support.torproject.org/tbb/how-to-verify-signature/ > > Thanks > --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSjzJyHC50xCrrUzy9RcisI/kdFogUCYHgS2gAKCRBRcisI/kdF oq6vAP9qpbJU+rlaec8UQyF15IKEAzxCbw6/Ea2qXjHeSPuZEAEAsjcbyq69an03 qdpLyEP0S44nzJL+wUtuGxJ1FwwE2wQ= =goaE -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 15 03:30:20 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35D6C3A1A24; Thu, 15 Apr 2021 03:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 TjeHua52BTj7; Thu, 15 Apr 2021 03:30:08 -0700 (PDT) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110077.outbound.protection.outlook.com [40.107.11.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35BB93A1A1E; Thu, 15 Apr 2021 03:30:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b5F41TIiC99hcKf1JRp+TFgWYowQPv64fN/u2+FLrSIH7vUz/DHvBHu/1IejliufRPSdG+uqsZ5YdmKJfYehLFwKDUK8M0E/NUuGmuwOMmPIRxdPLc506Mdl3Vx4IqIyUKZB7bufO+16JP9sevnhBM0qGbfTDJOnm0ASHhQxCJwmiKzsHrgxQLGrTnSYYoixlmVSlhgEd/aAfKWgttDHSVeUUTkeWAo1gybgM6+9TBS47wD9hHvB2I5xAMeigyl14l+b/3yM/QzwAQ5aSKQIpsytOUlVXqaICd+MIW8bWqYM8R2fSrJanoN57weSpxObf1i/2HCP5RaJhwHh/y2Vog== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=slINzKqjl6ba/UugfpSWPJaIdO9Lu21yMsZyoRiJFnc=; b=l7/x/7R8NQxoH8/P4rg7uHITtDYDYyJ1Lu4+hkJh3AsJvywL44owxzEUyAFubaHZFubi7YPWYdrNR6QOQp0dj9fQOFJF4igu3GUg+PVqW5PHFkeQUbrCAsiXpe7hnrKHGZ3rpqXNnhOnfGnP4gjOFelFzfAZuJP7ElHCPRSsog+w8UgqpSS0higCW8Lro8MTWTD06YwyPVg7sPgN8slD3RpdKOcwpHNVlxMX2s20/MIAQjfTdoNScr5NTVQ6SzQUhYOphk8fNm/yApL4VKoCcFwEDOzZuKye3UUSQdT6AkyRu7aSsXunBBx7bI0lsLqBYhqgzG1f3+WKALlnYmJS2A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=manchester.ac.uk; dmarc=pass action=none header.from=manchester.ac.uk; dkim=pass header.d=manchester.ac.uk; arc=none Received: from LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:184::9) by LO2P265MB0637.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:6f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.22; Thu, 15 Apr 2021 10:30:03 +0000 Received: from LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM ([fe80::8088:4602:d179:2e9e]) by LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM ([fe80::8088:4602:d179:2e9e%7]) with mapi id 15.20.4020.024; Thu, 15 Apr 2021 10:30:03 +0000 From: Stian Soiland-Reyes To: Phillip Hallam-Baker , John C Klensin CC: "General Area Review Team (gen-art@ietf.org)" , "Eliot Lear (elear)" , Yakov Shafranovich , IETF SAAG Thread-Topic: [art] [saag] Date formats: RFC3339 vs. RFC 5322 Thread-Index: AQHXMJe3QFo8O+lXyEKs6qsGiriCoaqy37UAgAGKIgCAAQpSAA== Date: Thu, 15 Apr 2021 10:30:03 +0000 Message-ID: <1B70AA8F-B9DA-4482-A637-177D318C24DD@manchester.ac.uk> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.43.20110804 authentication-results: hallambaker.com; dkim=none (message not signed) header.d=none;hallambaker.com; dmarc=none action=none header.from=manchester.ac.uk; x-originating-ip: [2001:8b0:a657:68e3:6913:c226:5f1d:58b2] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3d2304d7-65b7-4a19-3f7b-08d8fff96e31 x-ms-traffictypediagnostic: LO2P265MB0637: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: B5rXPH4+Be0LWkION+hkic2vRs9MIy/e0PylrNXxppY2W91wiRV0gDQUty3zuCPhpK+xNtvMlYnu7Lilkc1Vo1rp2wr0kaDGaXfACjBpDM6i6m59laaYrSZRSkRIFop3CLm9t0pWw/lbH+WQKGY//LXBBOwIHq7JW8dta3wU9bgYqnx+nGcsUx5OSsE8yin1nwMGfe29AuBOLqkmA4tMie7+lGgAnoZ9R5wks+9rurUJodltyctAZCjlGT07Xlo6nK+JmzFdC7W/kAfdc+rvlpSkKx+BWm0ZGERkHPrwE59tkviDXoziMIDJWwIFrpFTS0p6lIfQMOsbiij8Qnk4yYNkss+TG9fNBnjlIKQ/Su6GDxa/0p5hN0T4trMLCe9Rf/OxhvTG9Ek31mXMN1dyHi9dg8lyhPMXMaQQ8iJdn720d0fCNEgdkcuITuFcRtuhgOtjG6BqqsDS1s1gRlvfzE0YTkcwP1hcam6tjh+Dkcm2b+FRJipxfQh8AO8QB+V3t8eHHgw+/fEbJb7kLeVOH+pkjyMwTwRrL5Vt6iLo6Ye2inadLcVeB4ILmOUd8qdJ4WGTZ4TLn+C7a8kwFcSNjVDFz8/+nE4cMkrkG+8UdZy520oP9P9tAhAxIhmRbXRiV4PanXrdgR+8Z532l4PscD1N4y2d2x3NDC/q7GIAL+aWg9bbeM38fMRDhLPxQ5hax2m9vkVOJp9brQGNY91TFmm/XK9LxNrX2HvOuWgV7B6tZBQboOeiMPOCwx5FOaDs x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(376002)(396003)(366004)(346002)(478600001)(6512007)(86362001)(83380400001)(66556008)(36756003)(6486002)(786003)(6506007)(122000001)(966005)(8936002)(38100700002)(76116006)(2616005)(2906002)(71200400001)(66446008)(5660300002)(186003)(64756008)(316002)(8676002)(110136005)(4326008)(66946007)(33656002)(66476007)(54906003)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?OHdRdndQQ1NYbUU5a1M4bitRM0J1d1BwdDVPUFlQQnpxQWxHWDBxY0V1dkZp?= =?utf-8?B?VUNwQURjbk9XSGwyL2xiSHNmYVpFbDVOc0JWa24wclYzR1c5VW9pOVBrTFg4?= =?utf-8?B?WS9Iak1ITmc5aFp0TDZENFdmSzhoM0dHZVFpTWtzVHByc2JrUkx3czBFVmV4?= =?utf-8?B?THFUbExKeXBPRC94MHJsTUdGa1lHejZCRHVoSnFCNit2eDFoWDlnMlBESEIv?= =?utf-8?B?ZWZVTkN2Y2hhRDBKN2dkRVpGeUJmUEhsU1M3NVhJNVV3Q21HbTk0YlZjQVAx?= =?utf-8?B?ck9veHgva3p5bzdZUnNTZU1EQkU2N0hlRm5JbWlFM1lGaGZCSVZjOTM3aDMv?= =?utf-8?B?MjQvWTJMRDdWUHFsVk1MMnFZOTIrUVhXRTAyQi84eDlGWE12Ni80TnNlSEVs?= =?utf-8?B?NDZjR1BUOUYzZVY5MktPWEJlelpnQ2ZKTVE2U0huZnhIMzNnZURVZ2FWV0xS?= =?utf-8?B?cWo5OElKaEpEMUZndUlZSElSQU14dmVaZGFpRjU0dWdwcWxKTDliT0RKQzFt?= =?utf-8?B?bnRuL3RHWWIxT2FqZW9aQm9KOHhKdzR2NVRqa2ZQQTR1MFV2aGtvN0xDdmQ0?= =?utf-8?B?Y1dzUFlCaXlrb2FMOCtoenEwVXQwRElCbWlWSU5kbWlERFBDcWo5Z2x2TGhX?= =?utf-8?B?ZFF5WURqTll6ellpV3RDak45K0VKY0FxMlZyOGliVG1qLzBhYkVBUktiWjBZ?= =?utf-8?B?dU9vczE1OFhZRVpRcURST1h6TzRoL0doVWk3aFE4VTNCQUxCQjFQSWdHbVA3?= =?utf-8?B?U2NQdFd0c2RLeExMMTgvNDRHMDFMcHd5K3Q3bG1IdkRFKzJRRDZ4SmtnSGVu?= =?utf-8?B?bm94SGtlTU9XOTRVS3pVWlB5aXJHMDZSeXVFNFF5dmV0eHhqQ2tJZGFaZFF4?= =?utf-8?B?VjhzVTFRcW5DS2VwQlMrVHZBelZlMEN2dEl6RjBVcDIrQWJ5WDZMdHgxaStT?= =?utf-8?B?TDNYQkE0ZnpPNnF3UHQzbmZHTmNLUVVCMWlBcE9DVG1aZ0w2WTJCNXg4L0JC?= =?utf-8?B?bGNLckpBZUhGVDlBbWhnU1BUWG1zbmh1cXZnTFgwSStLZHljdmQwTGY2RW1s?= =?utf-8?B?R1IvOWllQ0gvRnJ4bE5GdzY5UWtkMzZrSEt6QkRObGtwaXZWaWM1RkFCYXpk?= =?utf-8?B?WXFNUFlhd2dvK3FRVTlsNzY5ZUhWUXVkL1ZWM0NxeWVZS2UyWmlIRm8vVjZW?= =?utf-8?B?azZoTTNGdEE3Z2Y1TmtCZlVTeUorOHZ0cncvaXdKc0VsTytSVTB6ZDhDUmJ0?= =?utf-8?B?YnE3anZUK0xoeE5xZHptTEZHNDVUc3hpdXU3TlBMMDRIZ201cXB3K0R1Z0Ry?= =?utf-8?B?YTRrRnBNU1hxWThmVHYvc3NLVVhhRmFzdXNhWVhjNUt4LzRYMHcvS3Z6Umoz?= =?utf-8?B?eVNUVnpNU0p6OUQ1dGx0YXptWHV6eGZsOXZPK1RidUtuY1NuWHZXMkEvTUx1?= =?utf-8?B?K3NZaWwzTVF6cklrY01tL21MbEhWb1kvay9hQVpjSjZFZFhUZzNIcHNONWt4?= =?utf-8?B?WXhKb0JXb05IS1ExeFRCL3JlaGpHN3NKVDNMWEVLc0ZOdGJlSERyb3JHWUZU?= =?utf-8?B?WkMrc1NrdWRwYVJPUHNDakcvM092RzRsVmthMjhrYnNlN0FmcjRrcmc3NDJB?= =?utf-8?B?d0w2bXBIWC9qakFHM1FPSlBKc0EzaEhEWGZOTmZxVDA0cjRJNnErZmprM3o2?= =?utf-8?B?alI0cjlJT3dsaDRJWHJGNDUvdnQ3cU9XbkljUjJkeWgxdjNHaytOaVRzQTlS?= =?utf-8?B?cVhoZDBycTVJQlRVaTR3ZFRQUGs0cVJULzI3c214UjNhSkc2KzM4VGp0MlpN?= =?utf-8?B?N2c0MGRtZ3Q5SHdUcWFiSzR0UUhYY1VhdFpjQ2xlanIzRmdUYW9PQWN4TTlF?= =?utf-8?B?WmJkQzdlV2VsV2tPUnNaL2NLbVBuSU8raXMyUkRTK0dSbUE9PQ==?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <8DAA12E37ED5114E84D1F6ACFA2C8854@GBRP265.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: manchester.ac.uk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO0P265MB2986.GBRP265.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 3d2304d7-65b7-4a19-3f7b-08d8fff96e31 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2021 10:30:03.2222 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c152cb07-614e-4abb-818a-f035cfa91a77 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /kiWPkyqTSywuZLBG9j0yEHJoYklmGZ3ovSAaOLPvqDuHEDdAUolNeksqQqQ9Xl/KcTqcE5udtYGy1TonV6kyYOmZ3vNY97bBFD6FYuVFjI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB0637 Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 10:30:14 -0000 T24gMjAyMS0wNC0xNCBQaGlsbGlwIEhhbGxhbS1CYWtlciA8aWV0ZkBoYWxsYW1iYWtlci5jb20+ IHdyb3RlOg0KDQo+IFVuZm9ydHVuYXRlbHksIHRoZSBtZXRob2Qgb2YgcGxhdGZvcm0gaGFuZGxp bmcgb2YgVVRDIG1lYW5zIHRoYXQgYWxsIGRhdGUgdGltZQ0KPiB2YWx1ZXMgcmVjb3JkZWQgaW4g ZWxlY3Ryb25pYyBkb2N1bWVudHMgYXJlIGluaGVyZW50bHkgYW1iaWd1b3VzLCBhIHN0YXRlIA0K PiBvZiBhZmZhaXJzIHRoYXQgd2lsbCBwZXJzaXN0IHVudGlsIHRoZSBjcmV0aW5vdXMgbm90aW9u IG9mIGxlYXAgc2Vjb25kcyBpcw0KPiBkb25lIGF3YXkgd2l0aC4NCg0KTGVhcCBzZWNvbmRzIHdv bid0IGdvIGF3YXkgdW5sZXNzIHlvdSBjaGFuZ2UgdGhlIGR1cmF0aW9uIG9mIGEgc2Vjb25kIG9y IHBsYW5ldCdzIHJvdGF0aW9uLi4NCg0KSSBkb27igJl0IHRoaW5rIFVUQyBvciBUQUkgbWFrZXMg YSBiaWcgZGlmZmVyZW5jZSBpbiB0aGlzIGRyYWZ0IG9uIHNlY3VyaXR5ISAgQnV0IGl0IGNhbiBt YWtlIGEgYmlnIGRpZmZlcmVuY2UgaWYgYXNzdW1pbmcgMDA6MDA6MDAgVVRDIGFzIGl0IGNhbiBi ZWNvbWUgMjM6NTk6NTkgKG9yIGluZGVlZCAyMzo1OTo2MCkgb24gdGhlIHByZXZpb3VzIGRheS4N Cg0KSGVyZSdzIG15IGxpdHRsZSBkZXZlbG9wZXIgaGludCBpZiBkZWFsaW5nIHdpdGggZGF0ZXMg aW4gdW5rbm93biB0aW1lem9uZXMgYW5kIHVua25vd24gdGltZSwgbmVlZGluZyB0byBiZSB0cmFu c2Zvcm1lZCB0byB0aW1lc3RhbXBzIGZvciBjYWxjdWxhdGlvbnMvY29tcGFyaXNvbnM6DQoNCkFz c3VtZSAxMDowMCBVVEMsIGFuZCB0aGVuIGl0IHdpbGwgYXQgbGVhc3QgYmUgdGhlIHNhbWUgZGF0 ZSBpbiBhbG1vc3QgYWxsIHRpbWV6b25lcyBhbmQgZGF5bGlnaHQgc2F2aW5ncyB0aHJvdWdoIHRo ZSB5ZWFyLiANCg0KUGVyaGFwcyB0byBhdm9pZCBUQUkgcHJvYmxlbSB3ZSBjYW4gYWRkIDE1IG1p bnV0ZXMgdG8gMTA6MTUgVVRDLCBlLmcgaHR0cHM6Ly9ldmVyeXRpbWV6b25lLmNvbS9zL2UwYzQz ZTAyIA0KDQotLSANClN0aWFuIFNvaWxhbmQtUmV5ZXMsIFRoZSBVbml2ZXJzaXR5IG9mIE1hbmNo ZXN0ZXINCmh0dHBzOi8vd3d3LmVzY2llbmNlbGFiLm9yZy51ay8NCmh0dHBzOi8vb3JjaWQub3Jn LzAwMDAtMDAwMS05ODQyLTk3MTgNCsKgwqDCoCBQbGVhc2Ugbm90ZSB0aGF0IEkgbWF5IHdvcmsg ZmxleGlibHkg4oCTIHdoaWxzdCBpdCBzdWl0cyBtZSB0byBlbWFpbCBub3csIA0KwqDCoMKgwqBJ IGRvIG5vdCBleHBlY3QgYSByZXNwb25zZSBvciBhY3Rpb24gb3V0c2lkZSBvZiB5b3VyIG93biB3 b3JraW5nIGhvdXJzLg0KDQoNCg0K From nobody Thu Apr 15 06:14:24 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A80C3A1F4C; Thu, 15 Apr 2021 06:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 k4ParPOusjaz; Thu, 15 Apr 2021 06:14:18 -0700 (PDT) Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753CF3A1F48; Thu, 15 Apr 2021 06:14:18 -0700 (PDT) Received: by mail-yb1-f173.google.com with SMTP id 82so26075100yby.7; Thu, 15 Apr 2021 06:14:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m1d+h0POvX3K+LYDtG6vE6Pb9ch+7XUuOMLagGk8v4E=; b=bRGy/V5pjgpHFUTL0UeFAfE9Gav/cByeJE8nbJKKrEHSl0Ix5QiPHcl1sUIIydxOM8 MrIjXLPk5EnkkTCHve+9SQOxP7lV6ECH+UY8J+AwmyzXQ/Oa5/4wEYxzjb39njcDixR0 2YodH0CDTW5hxaQqMKK5MqUm6Ud0B9l5yVL1JYGhdQdDm/QnGU4YR9v+7oJ+dzLcl+Db aJIVfN+jJhjoM1O3jezp9N/MFrDM3mGZup/KjSwctlocmkGRv4L1++jakeqATtEOWhwX gP05JgT0cWWZMkpnqx+XO1hklOVq3pWJ2mljgnD16ClS28UN3sR8uj4BynlaIz3EIq2Q 2i8w== X-Gm-Message-State: AOAM532q+rDBFEv3Nuqi2uv50IO8L0QTBo1z/TbeeIGS7xZQCkzE0ExT pbEtoZwIqwkazjBpPseg1Pcy+5y1D18IMAKzGSE= X-Google-Smtp-Source: ABdhPJwMa8yCf4bKBo96ReU9nIJyXSz/PaDu1RA56jp7ABxiMUH0SEZdZs3ZPT7ogPcQxuaf07dl4GAeQdAcK8tE6BI= X-Received: by 2002:a25:7752:: with SMTP id s79mr4448895ybc.522.1618492457463; Thu, 15 Apr 2021 06:14:17 -0700 (PDT) MIME-Version: 1.0 References: <1B70AA8F-B9DA-4482-A637-177D318C24DD@manchester.ac.uk> In-Reply-To: <1B70AA8F-B9DA-4482-A637-177D318C24DD@manchester.ac.uk> From: Phillip Hallam-Baker Date: Thu, 15 Apr 2021 09:14:05 -0400 Message-ID: To: Stian Soiland-Reyes Cc: John C Klensin , "General Area Review Team (gen-art@ietf.org)" , "Eliot Lear (elear)" , Yakov Shafranovich , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000ffb7f405c002a3ba" Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 13:14:23 -0000 --000000000000ffb7f405c002a3ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Apr 15, 2021 at 6:30 AM Stian Soiland-Reyes < soiland-reyes@manchester.ac.uk> wrote: > On 2021-04-14 Phillip Hallam-Baker wrote: > > > Unfortunately, the method of platform handling of UTC means that all > date time > > values recorded in electronic documents are inherently ambiguous, a > state > > of affairs that will persist until the cretinous notion of leap seconds > is > > done away with. > > Leap seconds won't go away unless you change the duration of a second or > planet's rotation.. > Untrue, there is no reason that time needs to bear any relation to the rotation of Earth, Saturn or any other planet. The time of noon changes by 15 minutes over the course of a year in Northern Europe. Why not move the longitude lines to compensate instead? > I don=E2=80=99t think UTC or TAI makes a big difference in this draft on > security! But it can make a big difference if assuming 00:00:00 UTC as i= t > can become 23:59:59 (or indeed 23:59:60) on the previous day. > That is only one means of adjusting for leap seconds. Most infrastructure has moved to smearing the second in over a longer time to avoid instability. The people who maintain the parts of various platforms dealing with time know all about leap seconds. But none of the ones I use generate 23:59:60 because the risk of breaking things with an untested, untestable code path is simply too great to be worth doing. And that is the root of the problem, there is no consistency across platforms and applications in applying leap seconds. It is impossible to know whether you are dealing with adjusted or unadjusted time. --000000000000ffb7f405c002a3ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 15, 2021 at 6:30 AM St= ian Soiland-Reyes <soi= land-reyes@manchester.ac.uk> wrote:
On 2021-04-14 Phillip Hallam-Baker <ietf@hallambaker.com= > wrote:

> Unfortunately, the method of platform handling of UTC means that all d= ate time
> values recorded in electronic documents are inherently ambiguous, a st= ate
> of affairs that will persist until the cretinous notion of leap second= s is
> done away with.

Leap seconds won't go away unless you change the duration of a second o= r planet's rotation..

Untrue, there is no reason that t= ime needs to bear any relation to the rotation of Earth, Saturn or any othe= r planet. The time of noon changes by 15 minutes over the course of a year = in Northern Europe.

Why not move the longitude lines to compensate instead= ?
=C2=A0
I don=E2=80=99t think UTC or TAI makes a big difference in this draft on se= curity!=C2=A0 But it can make a big difference if assuming 00:00:00 UTC as = it can become 23:59:59 (or indeed 23:59:60) on the previous day.

That is only one means of adjusting for leap seconds. Most infrastruc= ture has moved to smearing the second in over a longer time to avoid instab= ility. The people who maintain the parts of various platforms dealing with = time know all about leap seconds. But none of the ones I use generate 23:59= :60 because the risk of breaking things with an untested, untestable code p= ath is simply too great to be worth doing.

<= div class=3D"gmail_default" style=3D"font-size:small">And that is the root = of the problem, there is no consistency across platforms and applications i= n applying leap seconds. It is impossible to know whether you are dealing= =C2=A0with adjusted or unadjusted time.


--000000000000ffb7f405c002a3ba-- From nobody Thu Apr 15 06:29:45 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8573A1FD6 for ; Thu, 15 Apr 2021 06:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 qsrQXu68LVWK for ; Thu, 15 Apr 2021 06:29:40 -0700 (PDT) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024DA3A1FD2 for ; Thu, 15 Apr 2021 06:29:39 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id e14so36826748ejz.11 for ; Thu, 15 Apr 2021 06:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=3vndG9J+iiWqTzTwVdMwKjsxHVNF66tBCUzAQueQGLA=; b=WbPIuujRVIyXC3zH6sdCsfqcHgDLf6MfviLtp+KDK6hSz0P/7zzpI5e9WKQfQ6ETyC aX2O135xC0CAtde8rt/+/7/8w2byOff6xBPYzGT3FCQ6eh/0agrZa1aAJJrziaArZDd6 Oliuc//06cDOtfGaMQ3Ys8M/q3dIM1C7scgN2+rXeRf0nGV2sfM0eZ9N9mkUfPTAje3K xdwvgfIqWPGmX6OQmFNQ8KD1tKYbMPZUeonpPiy3nu1JLdm7rNuKrza46/yh5tyCV1+f V9PIo1q0GaDBdJQS4nNai/2Gmx61pjHO6d9qGWdF8KwAhGhh1tuPk/uZ0kVwaChgbHa5 AyoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=3vndG9J+iiWqTzTwVdMwKjsxHVNF66tBCUzAQueQGLA=; b=knDZhw8ZHw+BbKGaOtOUttPkH0Kqj/CWYD/DyaDgrwJCGl5Od0vRaM/qmQjr3DyK+o HIsmu5R37lMfhbvE8WQzJRmxc3eMYz8BwZYnxUTPFCEH6wAD9z7x3EfUD/xYOjreaLzI kjzmrddRSOh2AV5iCxgxEkCkTbfwzj/9ZsXuypANUBOeNnZ8/LV+Xvg8X8cx4xr6oNNM ctL7A9859T3By6XaU3HKB/vqYqwS79RjWkQcQhCFsjUSyWr/nRQswlujz0HobQRgY7sA WqnLRbtayS+XFOFCNeltaBIQedOext9a6CnXs0FAUXpCUi1UUrU4QRx+b+pLPOlxgNqU 6ENw== X-Gm-Message-State: AOAM532zS7bQFBV2HDtOUUe2vUNxobchoxPqgNO44Pdv4xSF+eKSaOIP xel1TnUiq0593K8x5gGM85kWggC3Gsg= X-Google-Smtp-Source: ABdhPJyxMYQ1c0RVO6mZZGnPtQHow1UD6Osj5PYL29HTr4lhbztxtXhPB8UI9uC5VGZ6Je2EXgmyug== X-Received: by 2002:a17:906:1b54:: with SMTP id p20mr3463579ejg.477.1618493377588; Thu, 15 Apr 2021 06:29:37 -0700 (PDT) Received: from bblfish.fritz.box (p5793ad5d.dip0.t-ipconnect.de. [87.147.173.93]) by smtp.gmail.com with ESMTPSA id a18sm1972571ejr.76.2021.04.15.06.29.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Apr 2021 06:29:36 -0700 (PDT) From: Henry Story Content-Type: multipart/signed; boundary="Apple-Mail=_1F6CA4E8-0480-4BF5-8A14-C1798ACC4815"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Thu, 15 Apr 2021 15:29:34 +0200 References: To: Yakov Shafranovich , saag@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [saag] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 13:29:45 -0000 --Apple-Mail=_1F6CA4E8-0480-4BF5-8A14-C1798ACC4815 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii What about unix time: seconds or milliseconds since the Unix Epoch? That removes all kinds of parsing problems as well as calendaring = problems. And it fits well with RFC8941 Structured Fields SfInteger. That is used by Signing HTTP Messages draft in their Signature-Input = header. > On 13. Apr 2021, at 20:43, Yakov Shafranovich = wrote: >=20 > Is there a preference for Internet drafts/RFCs regarding the specific > data/time format to be used? >=20 > Right now we are referencing RFC 5322, but there has been feedback > from multiple people that the ISO 8601 format is easier to parse. This > is in regards to the section 3.5.5 of "draft-foudil-securitytxt-11" > that I am working on: > https://tools.ietf.org/html/draft-foudil-securitytxt-11#section-3.5.4 >=20 > The options I am asking about are the following: > - RFC 3339 (a profile of ISO 8601) > Example: 2021-04-13T06:50:53-07:00 >=20 > - RFC 5322, section 3.3 > Example: Tue, 13 Apr 2021 06:50:53 -0700 >=20 > Thanks >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail=_1F6CA4E8-0480-4BF5-8A14-C1798ACC4815 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEkBsGFQMOBy4HqeUHZyBzEu36kSYFAmB4P74ACgkQZyBzEu36 kSZdSQ/+JG/uZHkTVjMgpRkG1Y99jxHNBUfs26iBQHerphJjI7Hv9sWxspS/McnC 4fUXsQpfXFrYdStkDx8u4VKmhdbrCCaP3l9lo9m+mQ7Qq4dnms9LCbz7GzHJB2YK 50dcU/3AVdURZBrnmZ+8anY8Zl5a1i2QhmX7h5qJ6i5txe7uHRHutP9aOVM7reEm LklWugyNDh8eD2Z1judxqxfgPfPBWnDe6o/IdlUSKwYRHA4fc+auiyRivS6eNPrf Bgxh+SBnARgjusPNxO1odTVt/wS6gVx7s1uajhSJTcg+Krw5+AfSFdT9ps5gykRP RXDIM6bN+tiqRR8Phpqk0E/72ASvxQ7PR+6IZIbuhgoXcBeWeGbPXlBw/oj+h+HO aOTOciEEx7uaswbtPaG5evbD3YgXN+HCvjc9NzvnSglqurAX3LxpSIlC5If1A/X4 AWT3x1j8bmcNcNpejNzXTtIt9Wxfxz9Uujb7na0lpg4MKB5g9dNOksHtgtXUBNft JnPylslCJrk8hjEVdSbxpIcp89LCy13d/dGFQaIvZj4V42lqV1khOm1HuT0YNxN+ iFPB/z3ZxwyDfeSXlZvSMPT4W3+hzi8l4YA9UktmAwqAmYW3G1ZXowJu2zkL38ou 9I5MOcvViZ9cLYlPWX+qtZbX8AjUHQgVKH3IQJgNtWb6ku6ty7c= =BZHI -----END PGP SIGNATURE----- --Apple-Mail=_1F6CA4E8-0480-4BF5-8A14-C1798ACC4815-- From nobody Thu Apr 15 06:36:33 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DBC3A2011 for ; Thu, 15 Apr 2021 06:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 kIOG3NKR4yzZ for ; Thu, 15 Apr 2021 06:36:29 -0700 (PDT) Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [103.96.23.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC5C3A200F for ; Thu, 15 Apr 2021 06:36:28 -0700 (PDT) Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2241.outbound.protection.outlook.com [104.47.71.241]) (Using TLS) by relay.mimecast.com with ESMTP id au-mta-80-FD35FvIFP_qAUvhc2k-5Ag-1; Thu, 15 Apr 2021 23:36:23 +1000 X-MC-Unique: FD35FvIFP_qAUvhc2k-5Ag-1 Received: from PS2PR06CA0002.apcprd06.prod.outlook.com (2603:1096:300:56::14) by SYXPR01MB1104.ausprd01.prod.outlook.com (2603:10c6:0:a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.20; Thu, 15 Apr 2021 13:36:21 +0000 Received: from PU1APC01FT043.eop-APC01.prod.protection.outlook.com (2603:1096:300:56:cafe::2c) by PS2PR06CA0002.outlook.office365.com (2603:1096:300:56::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16 via Frontend Transport; Thu, 15 Apr 2021 13:36:21 +0000 X-MS-Exchange-Authentication-Results: spf=none (sender IP is 130.216.95.224) smtp.mailfrom=cs.auckland.ac.nz; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cs.auckland.ac.nz Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (130.216.95.224) by PU1APC01FT043.mail.protection.outlook.com (10.152.253.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.4042.16 via Frontend Transport; Thu, 15 Apr 2021 13:36:20 +0000 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 16 Apr 2021 01:36:18 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1497.015; Fri, 16 Apr 2021 01:36:18 +1200 From: Peter Gutmann To: Henry Story , Yakov Shafranovich , "saag@ietf.org" Thread-Topic: [saag] Date formats: RFC3339 vs. RFC 5322 Thread-Index: AQHXMJUbN4XJLPxzhEeoIfUp+FDGsqq0zGoAgADKG6g= Date: Thu, 15 Apr 2021 13:36:18 +0000 Message-ID: <1618493778732.39296@cs.auckland.ac.nz> References: , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fe442ce3-2e9d-4d34-028f-08d900137474 X-MS-TrafficTypeDiagnostic: SYXPR01MB1104: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2958 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: WsEYoR04C9tsBzJ46iTZXSz3iZ7Ecxf1Xe2HhD60Jsxj/OdxlT+0hNf1cldf2feIX3Ppyv4udFYZOSEGLJi7qiywCgWaERqhydSQ9nUp1lu+9nELuhp9YNJLqCQHiMEmMdTgw6+/u4gqIVHcnh7i8d9B7qIph3lGZz3V6u13cuCoHySv9OTscae6IcaJ0SbZ2bj/gprO9/KZh+//ChWjsx1VsBlCxd8CP3xb7KYez0kzb+N6VRDkmKo/821CAepmM7EJxJ8+zlY3xVq0684yNQGaJTnQUuYIOE3KYYY5QUh/8xhgBlSuikIhFFyYUzG8myLVa7BHrixFtTBCnQWa5Sbkgz5gH/ZqtfA2g8ien4k+1JvyXnDIS6hzoXTtuQIYOaU9GXl3G3faA6s0Hd7Bpl4mVjlB5hoY77SpyvUXHmFGZJ3HfHv28zR2eN54g2NDHtWGdxI1HvxZZ6OMJBzlzOAtyEIfxcpNK7agv3t8Sdl9MYfAKRsITCHkrTq3HycT5k2wfLoYxpAMiWX5SYwYB1OC4wc7SwyNtgAS9XDnuitT7YxYByOBOwHenaDbP+Col2wwIAF+lJz3zN/QfPAKsBxFSURGoE8o7PnPvzdgKqHXkuRMAE8qmug2bmOhHBGTzpKk/zEs8iriJqzBU+Sk7TV2Irol2Gcr5Wxw37tQr94= X-Forefront-Antispam-Report: CIP:130.216.95.224; CTRY:NZ; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:uxcn13-ogg-d.UoA.auckland.ac.nz; PTR:natgate2-1.auckland.ac.nz; CAT:NONE; SFS:(4636009)(376002)(39830400003)(136003)(396003)(346002)(46966006)(36840700001)(2616005)(478600001)(786003)(356005)(26005)(2906002)(110136005)(47076005)(36906005)(7636003)(336012)(316002)(4744005)(8676002)(36860700001)(70586007)(5660300002)(70206006)(8936002)(82310400003)(86362001)(186003); DIR:OUT; SFP:1101 X-OriginatorOrg: cs.auckland.ac.nz X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Apr 2021 13:36:20.3576 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fe442ce3-2e9d-4d34-028f-08d900137474 X-MS-Exchange-CrossTenant-Id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=d1b36e95-0d50-42e9-958f-b63fa906beaa; Ip=[130.216.95.224]; Helo=[uxcn13-ogg-d.UoA.auckland.ac.nz] X-MS-Exchange-CrossTenant-AuthSource: PU1APC01FT043.eop-APC01.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYXPR01MB1104 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: cs.auckland.ac.nz Content-Language: en-NZ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 13:36:31 -0000 Henry Story wrotes:=0A=0A>What about unix time: sec= onds or milliseconds since the Unix Epoch?=0A=0AIf you're going to use epoc= h-based stuff then go with Julian dates, which is a=0Awell-established way = of fixing moments in time with arbitrary levels of=0Aprecision. It's curre= ntly 2459320.0656944.=0A=0APeter.=0A From nobody Thu Apr 15 07:21:18 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEA13A21C0 for ; Thu, 15 Apr 2021 07:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 AV3-9WWKNH1H for ; Thu, 15 Apr 2021 07:21:12 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 859CD3A21BE for ; Thu, 15 Apr 2021 07:21:12 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 13FEJfJt019987; Thu, 15 Apr 2021 15:21:07 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=1C589/aPKJEm4Gs7HBiEFPBCXcHsCrZQisN3aTrZxRI=; b=bIPfxMmr7/JvuD+MV4XZtxdAH3PNKYSBGHP4GQ+kc3h5HW2lQ22vmitpDriuAKMLoAWr kGIv77TJtsQDVit1HZrJRtwcSCqbdiv2IjA2DuuuZVpbnUK30XMstvTCMfdlpMI+7ul9 fh67JYMJCSK+dpiMxjPnwvwHz5o4JHVEPsm5pDGdLcFJPkprynJWVV8yxrAkQ2u+qGCS QQjM+BlGbPPe50iP6cpHRy59NhudKBhhQ4m2s0i1hULR7jMfZSwEhoDijJAI6LsMfJiu oFhjdoFR5AePSbFF8c5AvvAfh1WGaYGINkl+/kK5StqTbJol/JIPqyyPl2QnU9p0ItUf 9A== Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 37xdntyhja-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Apr 2021 15:21:07 +0100 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 13FEKPtV030434; Thu, 15 Apr 2021 10:21:06 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint8.akamai.com with ESMTP id 37wvb3h4tu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 15 Apr 2021 10:21:06 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 15 Apr 2021 09:21:05 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.012; Thu, 15 Apr 2021 09:21:05 -0500 From: "Salz, Rich" To: Peter Gutmann , Henry Story , Yakov Shafranovich , "saag@ietf.org" Thread-Topic: [saag] Date formats: RFC3339 vs. RFC 5322 Thread-Index: AQHXMJULVnkO8c4vN0Sbfz7e2uWmO6q16WYAgAAB4gD//8l0AA== Date: Thu, 15 Apr 2021 14:21:04 +0000 Message-ID: <3BBACC35-411D-4108-B436-2BA7CC47550F@akamai.com> References: <1618493778732.39296@cs.auckland.ac.nz> In-Reply-To: <1618493778732.39296@cs.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.48.21041102 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: <0774881D6511654D81C6784DDE55EFC1@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-15_06:2021-04-15, 2021-04-15 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 bulkscore=0 malwarescore=0 spamscore=0 mlxlogscore=779 adultscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104150096 X-Proofpoint-GUID: 4IHhgTQuXlrWWGXJIxC5jOyRXlaiy5QO X-Proofpoint-ORIG-GUID: 4IHhgTQuXlrWWGXJIxC5jOyRXlaiy5QO X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-15_06:2021-04-15, 2021-04-15 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 mlxlogscore=716 malwarescore=0 priorityscore=1501 lowpriorityscore=0 bulkscore=0 adultscore=0 suspectscore=0 spamscore=0 phishscore=0 impostorscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104150096 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.34) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint8 Archived-At: Subject: Re: [saag] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 14:21:17 -0000 UGVyaGFwcyBhc2tpbmcgdGhlIE5UUCBmb2xrcyBmb3Igdmlld3M/DQoNCg== From nobody Thu Apr 15 07:36:32 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FD83A223D for ; Thu, 15 Apr 2021 07:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.971 X-Spam-Level: X-Spam-Status: No, score=-3.971 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ReqrtsilkZfw for ; Thu, 15 Apr 2021 07:36:26 -0700 (PDT) Received: from ppsw-32.csi.cam.ac.uk (ppsw-32.csi.cam.ac.uk [131.111.8.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B64C93A2243 for ; Thu, 15 Apr 2021 07:36:13 -0700 (PDT) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from [84.9.76.236] (port=54775 helo=milebook.lan) by ppsw-32.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.156]:25) with esmtpsa (PLAIN:fanf2) (TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1lX36G-000hAR-2e (Exim 4.94) (return-path ); Thu, 15 Apr 2021 15:36:08 +0100 Date: Thu, 15 Apr 2021 15:36:08 +0100 From: Tony Finch To: Henry Story cc: Yakov Shafranovich , saag@ietf.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: Tony Finch Archived-At: Subject: Re: [saag] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 14:36:31 -0000 Henry Story wrote: > What about unix time: seconds or milliseconds since the Unix Epoch? Not human-readable or writable. It's very easy to turn an RFC 3339 date-time into POSIX time. Tony. -- f.anthony.n.finch https://dotat.at/ Rattray Head to Berwick upon Tweed: Southerly or southeasterly 3 or 4, occasionally variable 2 in south, increasing 5 at times later in far north. Smooth or slight. Fair. Good. From nobody Thu Apr 15 07:51:41 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10DEA3A22CC for ; Thu, 15 Apr 2021 07:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 MWLtAsO1Fm_B for ; Thu, 15 Apr 2021 07:51:35 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B8083A22C6 for ; Thu, 15 Apr 2021 07:51:35 -0700 (PDT) Received: from [192.168.217.118] (p548dc27d.dip0.t-ipconnect.de [84.141.194.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FLj392GnKzyZ5; Thu, 15 Apr 2021 16:51:33 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <3BBACC35-411D-4108-B436-2BA7CC47550F@akamai.com> Date: Thu, 15 Apr 2021 16:51:32 +0200 Cc: Peter Gutmann , Henry Story , Yakov Shafranovich , "saag@ietf.org" X-Mao-Original-Outgoing-Id: 640191092.761304-3f1fd1d60a7375f21d5b04c1ae97c229 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1618493778732.39296@cs.auckland.ac.nz> <3BBACC35-411D-4108-B436-2BA7CC47550F@akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [saag] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 14:51:40 -0000 On 2021-04-15, at 16:21, Salz, Rich = wrote: >=20 > Perhaps asking the NTP folks for views? Not needed. We are talking about security.txt, and the question was whether this = text-based format should use RFC 3339 or RFC 5322. The answer is that = the latter is a legacy format with a ton of problems, and RFC 3339 = (preferably simply with UTC time) is the answer. There are great applications for POSIX times (NTP, RFC 8949 tag 0/1), = MJDs (RFC 8943), etc., but all this is not needed for the bog-standard = date/times needed for security.txt. Leap seconds are irrelevant for = this, as are Julian Dates, and probably even time zones (if we assume a = minimum level of skill on the side of the people creating security.txt = files). Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Apr 15 08:54:04 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF863A24D5; Thu, 15 Apr 2021 08:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 j3T7AsjJ_QR3; Thu, 15 Apr 2021 08:53:52 -0700 (PDT) Received: from smtp.ucolick.org (hunan.ucolick.org [128.114.23.233]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3181D3A24D7; Thu, 15 Apr 2021 08:53:52 -0700 (PDT) Received: from smtp.ucolick.org (localhost [127.0.0.1]) by smtp.ucolick.org (Postfix) with ESMTP id 953CB27A2; Thu, 15 Apr 2021 08:53:50 -0700 (PDT) Received: from geneva.ucolick.org (geneva.ucolick.org [128.114.23.183]) by smtp.ucolick.org (Postfix) with ESMTP id 9060420D5; Thu, 15 Apr 2021 08:53:50 -0700 (PDT) Received: from geneva.ucolick.org (localhost [127.0.0.1]) by geneva.ucolick.org (Postfix) with ESMTP id 877E5267; Thu, 15 Apr 2021 08:53:50 -0700 (PDT) Received: (from sla@localhost) by geneva.ucolick.org (8.14.7/8.14.7/Submit) id 13FFrlAV008972; Thu, 15 Apr 2021 08:53:47 -0700 Date: Thu, 15 Apr 2021 08:53:47 -0700 From: Steve Allen To: Phillip Hallam-Baker Cc: Stian Soiland-Reyes , John C Klensin , "General Area Review Team (gen-art@ietf.org)" , "Eliot Lear (elear)" , Yakov Shafranovich , IETF SAAG Message-ID: <20210415155347.GB6366@ucolick.org> References: <1B70AA8F-B9DA-4482-A637-177D318C24DD@manchester.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 15:53:57 -0000 On Thu 2021-04-15T09:14:05-0400 Phillip Hallam-Baker hath writ: > Untrue, there is no reason that time needs to bear any relation to the > rotation of Earth, Saturn or any other planet. The time of noon changes by > 15 minutes over the course of a year in Northern Europe. Ramadan Mubarak! Note that the reason that leap seconds were not abandoned at the 2015 ITU-R WRC is that 6 nations whose national holidays are based on direct observation of celestial events objected. International legal issues are why leap seconds were created in 1970. This thread needs to leave here now and move to someplace like the Leap Seconds Discussion List. https://pairlist6.pair.net/mailman/listinfo/leapsecs -- Steve Allen WGS-84 (GPS) UCO/Lick Observatory--ISB 260 Natural Sciences II, Room 165 Lat +36.99855 1156 High Street Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 https://www.ucolick.org/~sla/ Hgt +250 m From nobody Thu Apr 15 12:32:26 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086A63A1B1C; Thu, 15 Apr 2021 12:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 X2nAbu8vfRid; Thu, 15 Apr 2021 12:32:19 -0700 (PDT) Received: from mail-yb1-f175.google.com (mail-yb1-f175.google.com [209.85.219.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8FA93A2C01; Thu, 15 Apr 2021 12:32:05 -0700 (PDT) Received: by mail-yb1-f175.google.com with SMTP id 82so27423499yby.7; Thu, 15 Apr 2021 12:32:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iZYO7Ch7NJHaH4c7PGToEDgc650m7QDMI7yLQiX1j2o=; b=U4pPkgQFXl18tQyK79PgA7BLplrWqK7BYXwOxVB5c0N12vKM0+GYVJl661p5/g783F W6tzeq/7PoDQKWkIhG278U2MzkRRbl0ITS8LQ+vtq9lgx0cJd091UkblIjrCjXnVGC+c KUKzKnMQNIXRk5U5gi60IoamR34/Qt9crp+0mkmJnBaR6HeRpx5F9wAZyusbrSkR5512 Oy64uVcXyQJlFnLB12Y+k2Fl57QOsYVPyFanVorEAek7ZHwRruvsVu86a8NzSTiIFMuP 1RtlHcXPIi4ocJebQJr513PcByc3zlK3K/QhKWAnocq1gLHA5OQSoZrSheUwIBRLZ1y6 kqVQ== X-Gm-Message-State: AOAM531Ux8ZwGcYd6YrT84AtXbLf/jgfpY764wROWmYWP4RVKvCU3zWN OV1ziQvChPuTjB+CMpxEr+m8F9bRpvtYaiQhczk= X-Google-Smtp-Source: ABdhPJxbGrFlU7aj9LZn/nr8Te3Ommii458+xDYZpCVByQaAOWeK1XfwmY7ZjRncwB2AXN5TwqPeJ7MlwptKERm4jH8= X-Received: by 2002:a25:aa90:: with SMTP id t16mr6339292ybi.56.1618515093535; Thu, 15 Apr 2021 12:31:33 -0700 (PDT) MIME-Version: 1.0 References: <1B70AA8F-B9DA-4482-A637-177D318C24DD@manchester.ac.uk> <20210415155347.GB6366@ucolick.org> In-Reply-To: <20210415155347.GB6366@ucolick.org> From: Phillip Hallam-Baker Date: Thu, 15 Apr 2021 15:31:23 -0400 Message-ID: To: Steve Allen Cc: Stian Soiland-Reyes , John C Klensin , "General Area Review Team (gen-art@ietf.org)" , "Eliot Lear (elear)" , Yakov Shafranovich , IETF SAAG Content-Type: multipart/alternative; boundary="00000000000036c56705c007e91f" Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 19:32:24 -0000 --00000000000036c56705c007e91f Content-Type: text/plain; charset="UTF-8" On Thu, Apr 15, 2021 at 11:53 AM Steve Allen wrote: > On Thu 2021-04-15T09:14:05-0400 Phillip Hallam-Baker hath writ: > > Untrue, there is no reason that time needs to bear any relation to the > > rotation of Earth, Saturn or any other planet. The time of noon changes > by > > 15 minutes over the course of a year in Northern Europe. > > Ramadan Mubarak! Note that the reason that leap seconds were not > abandoned at the 2015 ITU-R WRC is that Is actually that nobody threatened to take away the toys from the astronomers. Big Tech is more than big enough to end UTC, all it takes is the willpower to move to a different scale. > 6 nations whose national > holidays are based on direct observation of celestial events objected. > If their holidays are based on observing celestial bodies, they should be observing said bodies and UTC is precisely irrelevant. > International legal issues are why leap seconds were created in 1970. > Yet more of your vague, unspecified 'reasons'. The real reason is a bunch of astronomers get a feeling of importance from coming down from the mountain and telling everyone to snap their heels at their direction. > This thread needs to leave here now and move to someplace like the > Leap Seconds Discussion List. > https://pairlist6.pair.net/mailman/listinfo/leapsecs Not a list where the decision makers are. --00000000000036c56705c007e91f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Apr 15, 2021 at 11:53 AM Steve Allen <sla@ucolick.org> wrote:
On Thu 2021-04-15T09:14:05-= 0400 Phillip Hallam-Baker hath writ:
> Untrue, there is no reason that time needs to bear any relation to the=
> rotation of Earth, Saturn or any other planet. The time of noon change= s by
> 15 minutes over the course of a year in Northern Europe.

Ramadan Mubarak!=C2=A0 Note that the reason that leap seconds were not
abandoned at the 2015 ITU-R WRC is that

Is actually that nobod= y threatened to take away the toys from the astronomers.

Big Tech is more than big enough to end UTC= , all it takes is the willpower to move to a different scale.

=C2=A0
6 nations whose national
holidays are based on direct observation of celestial events objected.
<= /blockquote>

If their holidays are based on observing celestial bodies, they= should be observing said bodies and UTC is precisely irrelevant.

=
=C2=A0
International legal issues are why leap seconds were created in 1970.

Yet more of your vague, unspecified 'reasons'.

The real reason is a bunch= of astronomers get a feeling of importance from coming down from the mount= ain and telling everyone to snap their heels at their direction.=C2=A0

=C2=A0
This thread needs to leave here now and move to someplace like the<= br> Leap Seconds Discussion List.
https://pairlist6.pair.net/mailman/listinfo/leap= secs

Not a list where the decision makers are.
--00000000000036c56705c007e91f-- From nobody Thu Apr 15 12:58:46 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF273A2CBB; Thu, 15 Apr 2021 12:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 C7eoxQ3P8hbi; Thu, 15 Apr 2021 12:58:40 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9187D3A2CB7; Thu, 15 Apr 2021 12:58:37 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1lX88E-0006j7-B2; Thu, 15 Apr 2021 19:58:30 +0000 Date: Thu, 15 Apr 2021 12:58:29 -0700 Message-ID: From: Randy Bush To: Simon Josefsson Cc: saag@ietf.org In-Reply-To: <87y2djq2at.fsf@latte.josefsson.org> References: <87y2djq2at.fsf@latte.josefsson.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [saag] Best practices for verifying authenticity of OpenPGP keys? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Apr 2021 19:58:45 -0000 > https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-11 use and like randy --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header butchery From mbaushke@gmail.com Wed Apr 14 13:53:54 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB4D3A1F71; Wed, 14 Apr 2021 13:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ju1q213nyx45; Wed, 14 Apr 2021 13:53:49 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE853A1F6C; Wed, 14 Apr 2021 13:53:49 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id t140so15288451pgb.13; Wed, 14 Apr 2021 13:53:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:in-reply-to:date:cc:message-id:references :to; bh=QFEcil5S4UqL30TwixUvM+6zbG1Vo3amR/IKACBupo4=; b=MwVzVd/76C2YJ4/tlspIH9yXcbWFsPVeeZZAEeVJWSLNfdSpOspiFWuAsQA1zB5qjS TOHszxRP0FKw4eszX5udGsAw9osDq6+ODs1kMJ/LfwekE2qI8H8my/oZTmIKNLfVMZPB O6XMefNzDX3wkPR2vMwJdz1N70HnYeDTTEIHOvZOTxG3BoS7PdptZtIzTe4ig7oQvRua mQvjnNS8iE8DndJk2y7uV+8/AlUW9aiIMJdwRcvafrHeTWvs2VXC/GeyN3RXBbc//ni0 wECWCB/ir4x8lExCCbGJguifM2B092UJBoMiC6MW6LQ0BPvFxNIathGgZDdE8fzgRnp9 Iwgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:in-reply-to:date:cc :message-id:references:to; bh=QFEcil5S4UqL30TwixUvM+6zbG1Vo3amR/IKACBupo4=; b=ZaTW/05HXwF3fwd2K8TQAd6Yv3PM+OvnB9mpdjYTOg/o44DF48M8g3oZl0zBsCIqZe 0YbpgsDfofUaGVzzmMvrUFkm7bXZQ4SS6kI6iXNrIfRUfjNwJaB9/1VrrxXqIL1M+Mxi mYZoc+wTJR9elmjjl8edpe5P+VfY8KRN2pqE11oVMphS7g73MwaYLTKtMq/aSlVqMINS qeaFAVmUHX4UeMq8XgHYcO3amfPnn5sK9jFkz/orA8YZfmL4+cTGfyDTFHrtbIdnxABD Vlnzi20ddvV6AT+WvrLc1VRLVL6B/VaDNbgMiT3JJa6FOTM1X/PFRJax6X1fxmTpjvpc b8hA== X-Gm-Message-State: AOAM530P786bSqHc8pp9UqZUOpdzDNtY3mplFiqGtSpxX4/EubiQ2uVP OdAmMoHr/dcmSa44Z+j4hbs= X-Google-Smtp-Source: ABdhPJy4O95Lo8o41V/62BGDBMQ9YeYy4Wex1t6+Pum0/KDQGlUtEVcpDKeL5i0zslwbaKGvZ+EXiQ== X-Received: by 2002:a63:531b:: with SMTP id h27mr163855pgb.395.1618433628254; Wed, 14 Apr 2021 13:53:48 -0700 (PDT) Received: from [192.168.2.122] (c-98-234-187-55.hsd1.ca.comcast.net. [98.234.187.55]) by smtp.gmail.com with ESMTPSA id h8sm248938pjp.37.2021.04.14.13.53.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Apr 2021 13:53:47 -0700 (PDT) From: "Mark Baushke (ietf)" X-Google-Original-From: "Mark Baushke (ietf)" Content-Type: multipart/alternative; boundary="Apple-Mail=_5D14A785-0156-4577-BEAD-D61EEC8A0977" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) In-Reply-To: Date: Wed, 14 Apr 2021 13:53:46 -0700 Cc: "General Area Review Team (gen-art@ietf.org)" , "Eliot Lear (elear)" , IETF SAAG , Phillip Hallam-Baker Message-Id: <73A9FC4B-47DE-437F-9C90-BC0995B3E3C0@gmail.com> References: To: John C Klensin X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: X-Mailman-Approved-At: Sat, 17 Apr 2021 16:32:40 -0700 Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2021 20:57:00 -0000 --Apple-Mail=_5D14A785-0156-4577-BEAD-D61EEC8A0977 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am also going to +1 John's suggestion. ISO 8601 and Zulu time are = highly desirable in new standards. I will also ask how many digits are needed for sub-second precision. The Precision Time Protocol (IEEE 1588-2019) gets to microsecond and = possibly nanosecond range (to be fair, I have not read the 2019 = additions). Some of the Deep Space Network seems to express measurements with very = fine grained values and small angles (11 nrad). Although the ABNF in RFC 3339 hints at sub-second values, it does not = actually use examples. Twelve digits after the decimal point expresses pico seconds which is = just silly and unrealistic at present, but micro seconds seem plausible = in many contexts. If new standards are forward looking, then the = expression should possibly be considered. (I do not see a need to consider femto, atto, zepto, or yacto seconds at = the present time.) YYYY-MM-DDThh:mm:ss.nnnnnnnnnnnnZ Fwiw: I agree that leap seconds is a pain. Be safe, stay healthy, -- Mark > On Apr 14, 2021, at 12:36 PM, Phillip Hallam-Baker = wrote: >=20 > I am also going to strongly +1 John here. >=20 > At this point, the only question I would consider in a protocol is the = choice of UTC or TAI.=20 >=20 > Unfortunately, the method of platform handling of UTC means that all = date time values recorded in electronic documents are inherently = ambiguous, a state of affairs that will persist until the cretinous = notion of leap seconds is done away with. >=20 >=20 >=20 >=20 >=20 > On Tue, Apr 13, 2021 at 4:06 PM John C Klensin > wrote: >=20 >=20 > --On Tuesday, April 13, 2021 19:00 +0000 "Eliot Lear (elear)" > > wrote: >=20 > > The question is whether you need something that is easy to > > parse or something that is human readable and can be > > localized. It SEEMs that this draft is intended to be human > > readable, and so 5322 doesn't seem out of bounds. >=20 > I suggest that even for reading by humans in 2021 --as distinct > from 1982 (RFC 822) or 1977 (RFC 733, which used day-month-year > ordering)-- the 5322 dates are not easy to understand and use... > at least unless one is an English speaker on this side of the > pond. It was quite wise at the time to spell out the month > name, thereby eliminating the ambiguity associated with, e.g., > 5/10/1977, but still bad news for someone who might think the > fourth month in the Gregorian calendar is, e.g., =D0=B0=D0=BF=D1=80=D0=B5= =D0=BB=D1=8F, > =D8=A3=D8=A8=D8=B1=D9=8A=D9=84 , or =E5=9B=9B=E6=9C=88. >=20 > So I would argue that, for new protocols or data structures in > this increasingly global/ international Internet, and even for > elements visible to humans, sticking as close to ISO 8601 as > possible (with minimal profiling) is the Right Thing to Do. > Much too late now to change the 822/5322 format, turning > supplemental protocols for email into a gray area, but, for new > work, ISO 8601 formats are not just easier to parse but easier > to understand globally and in an unambiguous way. >=20 > Just my opinion, of course. >=20 >=20 > john >=20 > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art = > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail=_5D14A785-0156-4577-BEAD-D61EEC8A0977 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = am also going to +1 John's suggestion. ISO 8601 and Zulu time are highly = desirable in new standards.

I will also ask how many digits are needed for sub-second = precision.

The = Precision Time Protocol (IEEE 1588-2019) gets to microsecond and = possibly nanosecond range (to be fair, I have not read the 2019 = additions).

Some= of the Deep Space Network seems to express measurements with very fine = grained values and small angles (11 nrad).

Although the ABNF in RFC 3339 hints at = sub-second values, it does not actually use examples.

Twelve digits after the = decimal point expresses pico seconds which is just silly and unrealistic = at present, but micro seconds seem plausible in many contexts. If new = standards are forward looking, then the expression should possibly be = considered.
(I do not see a need to consider femto, = atto, zepto, or yacto seconds at the present time.)

YYYY-MM-DDThh:mm:ss.nnnnnnnnnnnnZ

Fwiw: I agree that leap seconds is a = pain.

  =       Be safe, stay healthy,
  =       -- Mark

On Apr 14, 2021, at 12:36 PM, = Phillip Hallam-Baker <ietf@hallambaker.com> wrote:

I am = also going to strongly +1 John here.

At= this point, the only question I would consider in a protocol is the = choice of UTC or TAI. 

Unfortunately, the = method of platform handling of UTC means that all date time values = recorded in electronic documents are inherently ambiguous, a state of = affairs that will persist until the cretinous notion of leap seconds is = done away with.





On Tue, Apr 13, 2021 at 4:06 PM John C = Klensin <john-ietf@jck.com> wrote:


--On Tuesday, April 13, 2021 19:00 +0000 "Eliot Lear (elear)"
<elear=3D40cisco.com@dmarc.ietf.org> = wrote:

> The question is whether you need something that is easy to
> parse or something that is human readable and can be
> localized.  It SEEMs that this draft is intended to be = human
> readable, and so 5322 doesn't seem out of bounds.

I suggest that even for reading by humans in 2021 --as distinct
from 1982 (RFC 822) or 1977 (RFC 733, which used day-month-year
ordering)-- the 5322 dates are not easy to understand and use...
at least unless one is an English speaker on this side of the
pond.  It was quite wise at the time to spell out the month
name, thereby eliminating the ambiguity associated with, e.g.,
5/10/1977, but still bad news for someone who might think the
fourth month in the Gregorian calendar is, e.g., =D0=B0=D0=BF=D1=80=D0=B5=D0= =BB=D1=8F,
=D8=A3=D8=A8=D8=B1=D9=8A=D9=84 , or =E5=9B=9B=E6=9C=88.

So I would argue that, for new protocols or data structures in
this increasingly global/ international Internet, and even for
elements visible to humans, sticking as close to ISO 8601 as
possible (with minimal profiling) is the Right Thing to Do.
= Much too late now to change the 822/5322 format, turning
supplemental protocols for email into a gray area, but, for new
work, ISO 8601 formats are not just easier to parse but easier
to understand globally and in an unambiguous way.

Just my opinion, of course.


    john

_______________________________________________
art mailing list
art@ietf.org
https://www.ietf.org/mailman/listinfo/art
_______________________________________________
saag = mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

= --Apple-Mail=_5D14A785-0156-4577-BEAD-D61EEC8A0977-- From nobody Sat Apr 17 17:29:50 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8573A396B; Sat, 17 Apr 2021 17:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ZpyVffRNDxec; Sat, 17 Apr 2021 17:29:39 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5BE3A392C; Sat, 17 Apr 2021 17:29:38 -0700 (PDT) Received: from [192.168.217.118] (p548dc27d.dip0.t-ipconnect.de [84.141.194.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4FN9nC4tpvzyms; Sun, 18 Apr 2021 02:29:35 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <73A9FC4B-47DE-437F-9C90-BC0995B3E3C0@gmail.com> Date: Sun, 18 Apr 2021 02:29:35 +0200 Cc: "General Area Review Team (gen-art@ietf.org)" , IETF SAAG X-Mao-Original-Outgoing-Id: 640398574.988788-a963a53b54d06aaf88aa8c5f99bfef7c Content-Transfer-Encoding: quoted-printable Message-Id: References: <73A9FC4B-47DE-437F-9C90-BC0995B3E3C0@gmail.com> To: "Mark Baushke (ietf)" X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2021 00:29:44 -0000 On 2021-04-14, at 22:53, Mark Baushke (ietf) wrote: >=20 > Twelve digits after the decimal point expresses pico seconds which is = just silly and unrealistic at present, but micro seconds seem plausible = in many contexts. If new standards are forward looking, then the = expression should possibly be considered. > (I do not see a need to consider femto, atto, zepto, or yacto seconds = at the present time.) I don=E2=80=99t know why this discussion is continuing on the SAAG list, = but let me add one factoid anyway: The CBOR tag defined in draft-bormann-cbor-time-tag supports picosecond = resolution [1] because the Haskell date/time libraries need that (which = in turn probably just try to be one step ahead of UNIX nanosecond = resolution). (The CBOR tag also has femtosecond and attosecond = resolution, because these are still cheap with 64-bit integers. = Zeptoseconds, yoctoseconds, and anything else down to and beyond Planck = units can be added later based on bignums.) A light-nanosecond is ~ 300 mm (~ a foot), a light-picosecond still is ~ = 0.3 mm (~ 12 thou), which is well beyond the tolerances to which e.g. = connectors can be manufactured, so while these are not easy to achieve = as date-time precisions, as durations (time differences) they are in = wide use (as are femtoseconds and even attoseconds). RFC 3339 has no problem with decimal fractions at all, so there is no = need for invention as long as we talk about text strings for date-times. Gr=C3=BC=C3=9Fe, Carsten [1]: = https://www.ietf.org/archive/id/draft-bormann-cbor-time-tag-04.html#name-k= eys-3-6-9-12-15-18 From nobody Sat Apr 17 18:32:47 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5393E3A3B79 for ; Sat, 17 Apr 2021 18:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=metapolymath.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 pGfuEUVN_mBE for ; Sat, 17 Apr 2021 18:32:39 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 532E33A3B74 for ; Sat, 17 Apr 2021 18:32:39 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id 12so50395505lfq.13 for ; Sat, 17 Apr 2021 18:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metapolymath.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=kC6wl4kQWwmB+V81+0TqFIYMIWKFDqse02BW9BjqlQU=; b=ItF9pUjUFzXDI0AdG7ubljwbI2UJ4iLAGCZqgip0rtVikLuPOeadthrz9QAYL26bZ3 FxXh0Mb7glzwNgr/HHF8jJ5R7ExTpFzDXZrla8nDSUFTY4VBtEgj/H7KTG0gRXWI0HcG Ef5VAVcbhPwdTE5w8q5iPHb4NLATSbtlbe/4LJOKiZus5++5mtOPCqSCzB8OWQQlzwWa p5I4tdbCczF9J4h1rgKgVNmFd9r+WLYy306LXTdIcrd3fJzDrMOFZEfTBqr2yExUUqcp Ly/10hdvfRca9UU8Y6jSbHmwisc6kqd3o4r4ENHYavhvEs0XPU2eI8qyq/meQTEooCFZ 7mcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=kC6wl4kQWwmB+V81+0TqFIYMIWKFDqse02BW9BjqlQU=; b=oEIJSRegtGWu5xbP/TxKtgKplMcDG+LPQiv5OTuIVCrKnJBhnUXwJ0TsG8i8xXgSuM 7bIISmwrKYEEcHyPALeOiZRKPvPPpGDZRb+HpdO8jenjWbigk/p40hAsFUf0JRHbPHUt 67suViXUYbz6Tuh2lOqAy5+vtkL5GgQ5CYUt9Zl0/FjD0Q/RF5bqbFkNVv8JsBRfZJsY aFpqNqcCTlHO/q5gTVE3UalE6ANL86BRsbnrRxVdSnv6/maOCoM1sH4MyCjFzsWxCHbh 4z7iWRhpyttJ5h3Lc0iEkzI4O8/bG0W+W87TXMU3T4IE1H0sl+CaYt1pV3+12SFsCZXN p7hw== X-Gm-Message-State: AOAM530rv2nkQ/g2UZKt7irCqXZYOjlgDNkf4uvV5/s+cMpQuYJ6Gfd0 AydW6GAtw8zefZDfMCcdvj6FGdEEXZGxrln/W03qPg== X-Google-Smtp-Source: ABdhPJzdPxS57go2PUFC6X0tRb7L/W7fuEIVMeD55I+g3yYSqwBOBH1hRJHtrxk352KZ8WKc25hl/jLHwcVjhCwptgw= X-Received: by 2002:a19:711d:: with SMTP id m29mr215327lfc.660.1618709551855; Sat, 17 Apr 2021 18:32:31 -0700 (PDT) MIME-Version: 1.0 References: <73A9FC4B-47DE-437F-9C90-BC0995B3E3C0@gmail.com> In-Reply-To: From: Metapolymath Majordomo Date: Sat, 17 Apr 2021 20:32:21 -0500 Message-ID: To: "General Area Review Team (gen-art@ietf.org)" , IETF SAAG Content-Type: multipart/alternative; boundary="000000000000d54e4405c0352fbf" Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2021 01:32:46 -0000 --000000000000d54e4405c0352fbf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yakov, I'm inclined to agree with Carsten. RFC 3339 section 5 seems to cover the general guide and recommends use of ISO 8601 for internet protocols. To the point on fractions of a second with RFC 3339 =C2=A7 5.3 Rarely Used Options. Then my current understanding when a rarely used option is needed for communicating an information interchange that needs such precision the use of ISO 8601-1:2019 and ISO 8601-2:2019 contain the guidance for what should be used. That being noted, was there something of security interest that is not fully covered by RFC 3339, ISO 8601-1:2019 and ISO 8601-2:2019 or a proposed RFC for SAAG that is not covered by these standards that we can look at specifically that you're concerned about? If so, please provide your specific concerns. With Regard, Kronah Wood Metapolymath, LLC PO Box 19236 Lenexa, KS 66219-9236 +1.2139158297 Sent from Mobile On Sat, Apr 17, 2021, 7:30 PM Carsten Bormann wrote: > On 2021-04-14, at 22:53, Mark Baushke (ietf) wrote: > > > > Twelve digits after the decimal point expresses pico seconds which is > just silly and unrealistic at present, but micro seconds seem plausible i= n > many contexts. If new standards are forward looking, then the expression > should possibly be considered. > > (I do not see a need to consider femto, atto, zepto, or yacto seconds a= t > the present time.) > > I don=E2=80=99t know why this discussion is continuing on the SAAG list, = but let > me add one factoid anyway: > > The CBOR tag defined in draft-bormann-cbor-time-tag supports picosecond > resolution [1] because the Haskell date/time libraries need that (which i= n > turn probably just try to be one step ahead of UNIX nanosecond > resolution). (The CBOR tag also has femtosecond and attosecond resolutio= n, > because these are still cheap with 64-bit integers. Zeptoseconds, > yoctoseconds, and anything else down to and beyond Planck units can be > added later based on bignums.) > > A light-nanosecond is ~ 300 mm (~ a foot), a light-picosecond still is ~ > 0.3 mm (~ 12 thou), which is well beyond the tolerances to which e.g. > connectors can be manufactured, so while these are not easy to achieve as > date-time precisions, as durations (time differences) they are in wide us= e > (as are femtoseconds and even attoseconds). > > RFC 3339 has no problem with decimal fractions at all, so there is no nee= d > for invention as long as we talk about text strings for date-times. > > Gr=C3=BC=C3=9Fe, Carsten > > [1]: > https://www.ietf.org/archive/id/draft-bormann-cbor-time-tag-04.html#name-= keys-3-6-9-12-15-18 > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --000000000000d54e4405c0352fbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yakov,

I'm inclined to agree with Carsten.
RFC 3339 section 5 seems to cover the general guide and recommend= s use of ISO 8601 for internet protocols. To the point on fractions of a se= cond with RFC 3339 =C2=A7 5.3 Rarely Used Options.=C2=A0

Then my current understanding when a rarel= y used option is needed for communicating an information interchange that n= eeds such precision the use of=C2=A0
ISO 8601-1:2019= and ISO 8601-2:2019 contain the guidance for what should be used.=C2=A0

That being noted, was ther= e something of security interest that is not fully covered by RFC 3339, ISO= =C2=A08601-1:2019 and ISO 8601-2:201= 9 or=C2=A0a proposed RFC for SAAG that is not covered by these stand= ards that we can look at specifically that you're concerned about? If s= o, please provide your specific concerns.

=


With Regard,

Kronah Wood
Metapo= lymath, LLC
PO Box 19236
Lenexa, KS 66219-9236
+1.2139158297
Sent from Mobile




=C2=A0=C2=A0=C2=A0

On Sa= t, Apr 17, 2021, 7:30 PM Carsten Bormann <cabo@tzi.org> wrot= e:
On 2021-04-14, at 22:53, Mark Ba= ushke (ietf) <mbaushke@gmail.com> wrote: >
> Twelve digits after the decimal point expresses pico seconds which is = just silly and unrealistic at present, but micro seconds seem plausible in = many contexts. If new standards are forward looking, then the expression sh= ould possibly be considered.
> (I do not see a need to consider femto, atto, zepto, or yacto seconds = at the present time.)

I don=E2=80=99t know why this discussion is continuing on the SAAG list, bu= t let me add one factoid anyway:

The CBOR tag defined in draft-bormann-cbor-time-tag supports picosecond res= olution [1] because the Haskell date/time libraries need that (which in tur= n probably just try to be one step ahead of UNIX nanosecond resolution).=C2= =A0 (The CBOR tag also has femtosecond and attosecond resolution, because t= hese are still cheap with 64-bit integers.=C2=A0 Zeptoseconds, yoctoseconds= , and anything else down to and beyond Planck units can be added later base= d on bignums.)

A light-nanosecond is ~ 300 mm (~ a foot), a light-picosecond still is ~ 0.= 3 mm (~=C2=A0 =C2=A012 thou), which is well beyond the tolerances to which = e.g. connectors can be manufactured, so while these are not easy to achieve= as date-time precisions, as durations (time differences) they are in wide = use (as are femtoseconds and even attoseconds).

RFC 3339 has no problem with decimal fractions at all, so there is no need = for invention as long as we talk about text strings for date-times.

Gr=C3=BC=C3=9Fe, Carsten

[1]: https://www.ietf.org/archive/id/draft-bormann= -cbor-time-tag-04.html#name-keys-3-6-9-12-15-18

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mail= man/listinfo/saag
--000000000000d54e4405c0352fbf-- From nobody Sat Apr 17 18:37:28 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775D93A3B95 for ; Sat, 17 Apr 2021 18:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nightwatchcybersecurity-com.20150623.gappssmtp.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 yeFMO2NUNXw7 for ; Sat, 17 Apr 2021 18:37:22 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB8D3A3B92 for ; Sat, 17 Apr 2021 18:37:21 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id h4so21327973wrt.12 for ; Sat, 17 Apr 2021 18:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=op9iyuIecOrRX04uw4YcNgSLej+KbX6zMjWudSfL6Os=; b=t5BKGY4/TdyOdCAsc0r4RB/JEwYmpsIeZ+zk3T1ZVXLKO7DTci6NW36CnU4T7TNX6O lyeBiRw8x9rRrhfzQg9VmKk4mECi4J3XNoWCB+sHFzDkQqaj8vmAJN6/gTwv80ZQO1jr RRbIxYgTd3NbowrpI0JXlYWCG4ottOS7OG+nmaIPPVw+kzknI3nxVmcYncWnkqaARW/Q p2+OwZJ6hwUoEDWRn8h8pC7RV6KHFmqAOYbR2ffc1RPYKlGJIXfe60riUeQeVpXXAjHs 4pKBOFN7b7bkH107BGEJmHaaOt8+G3EPu+09CiPx0GEyw1xzihtyxtyySiibiVk/eQ5I SdYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=op9iyuIecOrRX04uw4YcNgSLej+KbX6zMjWudSfL6Os=; b=t0EC7Sq9UeGkqyyLqPlcVtRI/hDuGD96CQ6bVNSeJGjsDbW7Bxi1zfD1K8gFxexidN +GcRBMIhlcNkL+qKwF9O9IUyf0u7QPx2uQ/MdptoWvRX3irc4+4d41hbMlRp+PraD2gO 33Qkl2pbOZz2RnrgK7gCNNjEugt+HiG/4+8D1aC5sChg3bDVFCynR0J9gJfsD6uirsO6 nB19kWtozAL1KcrB9Z6zOvXeVJMt72E0/UiGMysCq5Zurb1RIz8flvecgkj2WNkaKdEq bngnlEF6fBQfe6axW44LPFiHIFDKnDfFw6Zt/UBxgzbitua89+9Y0M9CCL4Ty6tcTN/O XjiQ== X-Gm-Message-State: AOAM532TcYSneY/IN8ldscNJYHwYpB8wjmp7uoJhJXwumIF7OygwnWLC NHa9ufwF4dEynuP2pc93ocm9WWn+MntfT6Jx2XoCmw== X-Google-Smtp-Source: ABdhPJygTs7HSGiNDYswrrI0qvz6cjFlSTGgNEkp0i1GC4mPr10GP6sMPRvAREFB2OLjUWwUxdydCEzXrVNZadwjlFo= X-Received: by 2002:a5d:4fc9:: with SMTP id h9mr6457385wrw.172.1618709839328; Sat, 17 Apr 2021 18:37:19 -0700 (PDT) MIME-Version: 1.0 References: <73A9FC4B-47DE-437F-9C90-BC0995B3E3C0@gmail.com> In-Reply-To: From: Yakov Shafranovich Date: Sat, 17 Apr 2021 21:36:43 -0400 Message-ID: To: Metapolymath Majordomo Cc: "General Area Review Team (gen-art@ietf.org)" , IETF SAAG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [saag] [art] Date formats: RFC3339 vs. RFC 5322 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Apr 2021 01:37:27 -0000 I think the consensus is clear - to use ISO 8601 / RFC 3339. Thank you all! On Sat, Apr 17, 2021 at 9:32 PM Metapolymath Majordomo wrote: > > Hi Yakov, > > I'm inclined to agree with Carsten. > RFC 3339 section 5 seems to cover the general guide and recommends use of= ISO 8601 for internet protocols. To the point on fractions of a second wit= h RFC 3339 =C2=A7 5.3 Rarely Used Options. > > Then my current understanding when a rarely used option is needed for com= municating an information interchange that needs such precision the use of > ISO 8601-1:2019 and ISO 8601-2:2019 contain the guidance for what should = be used. > > That being noted, was there something of security interest that is not fu= lly covered by RFC 3339, ISO 8601-1:2019 and ISO 8601-2:2019 or a proposed = RFC for SAAG that is not covered by these standards that we can look at spe= cifically that you're concerned about? If so, please provide your specific = concerns. > > > > With Regard, > > Kronah Wood > Metapolymath, LLC > PO Box 19236 > Lenexa, KS 66219-9236 > +1.2139158297 > > Sent from Mobile > > > > > > > On Sat, Apr 17, 2021, 7:30 PM Carsten Bormann wrote: >> >> On 2021-04-14, at 22:53, Mark Baushke (ietf) wrote: >> > >> > Twelve digits after the decimal point expresses pico seconds which is = just silly and unrealistic at present, but micro seconds seem plausible in = many contexts. If new standards are forward looking, then the expression sh= ould possibly be considered. >> > (I do not see a need to consider femto, atto, zepto, or yacto seconds = at the present time.) >> >> I don=E2=80=99t know why this discussion is continuing on the SAAG list,= but let me add one factoid anyway: >> >> The CBOR tag defined in draft-bormann-cbor-time-tag supports picosecond = resolution [1] because the Haskell date/time libraries need that (which in = turn probably just try to be one step ahead of UNIX nanosecond resolution).= (The CBOR tag also has femtosecond and attosecond resolution, because the= se are still cheap with 64-bit integers. Zeptoseconds, yoctoseconds, and a= nything else down to and beyond Planck units can be added later based on bi= gnums.) >> >> A light-nanosecond is ~ 300 mm (~ a foot), a light-picosecond still is ~= 0.3 mm (~ 12 thou), which is well beyond the tolerances to which e.g. co= nnectors can be manufactured, so while these are not easy to achieve as dat= e-time precisions, as durations (time differences) they are in wide use (as= are femtoseconds and even attoseconds). >> >> RFC 3339 has no problem with decimal fractions at all, so there is no ne= ed for invention as long as we talk about text strings for date-times. >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> [1]: https://www.ietf.org/archive/id/draft-bormann-cbor-time-tag-04.html= #name-keys-3-6-9-12-15-18 >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > _______________________________________________ > art mailing list > art@ietf.org > https://www.ietf.org/mailman/listinfo/art