Re: [Sidrops] mft/ee validity time window alignment issue - Re: I-D Action: draft-ietf-sidrops-6486bis-05.txt

Stephen Kent <stkent@verizon.net> Fri, 09 July 2021 18:29 UTC

Return-Path: <stkent@verizon.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B666C3A2A6F for <sidrops@ietfa.amsl.com>; Fri, 9 Jul 2021 11:29:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.439
X-Spam-Level:
X-Spam-Status: No, score=-2.439 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.338, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.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 AdcBC8hXgqd6 for <sidrops@ietfa.amsl.com>; Fri, 9 Jul 2021 11:28:58 -0700 (PDT)
Received: from sonic315-20.consmr.mail.ne1.yahoo.com (sonic315-20.consmr.mail.ne1.yahoo.com [66.163.190.146]) (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 3D0DA3A2A6D for <sidrops@ietf.org>; Fri, 9 Jul 2021 11:28:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1625855336; bh=xrgBPRYJA+7n44YTSRx1yJz8fD/vNbOmPq8JYup9XFM=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject:Reply-To; b=mwk03ZMf0UEtRaPm/AQmYI7RCQA4Vj3JUTMSi+zlpXh9ira0Wmf5T5lP3ncIfmbrKVLWNY1epZMvIGCCwV9xal+bCF4AsY0g3jWnolWuAM9+qhzjP6cPo0iNxPJVrriU4WCVgKGgvhEYy3QWvZAN5aOeMZ+ey3KIl6Tj8FpARCtBLV6HM0KMGjvomcR3OQ7/L5GpBjURN8zK7pi6KfiBpW9GD4Of02uzeMnS9iptx0zTS4j7ui2S2qL/Z1A9/Kqct3Qf4Nhw2bAWrdqKlh+whhRpjJad73HE9ynkq8/FhOSfiY3DFJjUlA5gb1mrQ+txu/YtAMiWSkpQSjFk+LufMQ==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1625855336; bh=gsaIeNp3lG0zESreaO8+Hp3njiNDPF3+PlsnkTi2DAO=; h=X-Sonic-MF:Subject:To:From:Date:From:Subject; b=r4HiynQ+My+COfku3x+e8DSt57AOuB7g/RuJbgEy5Mj2wECsVCQG2Q9gqSdLxhmglUK2UR3qWdmllLoJlzjLZZppNpZ+ENYDZTmOONSPhX/Pe8DKSEs1WeSkeA77ragmEr9JKy3yahL3USpY0ttNWlEo4SJ2N7/iSXEWlHHWl2O8r79O3pcHZAOVmYgT91AdtkANtVSb/OxgWczLj1zze26IZ9yAzCgMfIZNEHj67a4G/5at9+5IFVSqQG3zjcRvWOGCO7Ny4Mk1uKDL8YZBgQppzC69Dl8RS1dMHosQOwNNPAuuK24tbpaOagC/I4ZGwUopycYVUa5rfb6Vs7WY9A==
X-YMail-OSG: X8wM1NgVM1mV1M7Aq16iG7BuJ142jVDimyZVF69NPu9PiKT.pJh9aTVIUtc2jD8 TwcLYuxLa.q.Qh8bclICwx4bN4opJv6RPnr0jR5DuHF5BLB9Zkm02iyyn0aJqG0h0PZhj16ijb.t G8XG45bRicffxaCzqHvQjUVmZlsetT4iUeiiTz9aUQsUfkJxBqv9mnGoxt363fqxrhsorp_uooAp kEiDooVuYVeWcrEMg.Li_7YZ1TMPK6HWiAUcOfnLlGuSL1Z7yBMuIWFEdLChJG4N9aOX.d.tpsws XMgfAKevMKc9jMkFhpPW_9Ep9pFnyN8Gu.4ixW7AGwJTVwQDsCI.GnJEjghz1L0QrGYJWhg_21oz 11vhZlFlM_3GTicCKrAuS6IiHhc_hUITXsAiiIAzkKH0EWQz3FUsalOLy0TBYbA26dfdaDZfaapG cLX3R8I6o3OzM96KNoJLEfEwS4RNA4zojV5CTq5QoKDHaW8GZQw8aHljqu9nYtXz7eAh3PNxluN2 7oP0HHCML7PRMMnhXkD1N0zpRun_9B36x3BOtkEUIsutvpUdzQNgUG6QHi4hW8_ED2oF4WW30rkp PUOmwaa.ICbu7ZTUkQBKqzcQUH1wj4OtISiFg2MzIKRyAb.ZmT.ocgVVBgAi2jlRTYRGSm9_xYGC g04vxH1D97lZ.Z1cZhAd2IlQtU9KhVdK63mAWi.sMKEg5TLFt2NMiqrfqVwTIssMq2E4jtdAzwvq s4b4ZeIiqaNMQlc7he.3qKb2v72k2tHLVZ9ssKLCWhipklYV69gZp7z.NK864j1KXdMakimi2zL_ vhy_Jn5NQydLnIIcmTQqaRkgb_sVvUd.9YbzGt.YN5WuEf6YIzRp5tOtJet2eRdmYUeYZo2u.WdG H7JwEIJVObNk1cQMPdveOGYV9ZOkuBGJquaCpAvgo0uDHFo5ew9B9TGGr2PLjhqTMs4wneuLY9M1 brZHUHHKugbIfrd4EFkkkWwaxai_iTbaA_CTI0YTlMC8I2YFFfXZji7xg6_9IUZxwF6Xo4kbhteX mwaH35HMpfK9FbiQpxgggIDvX_UM41lbgX5nIs2PAZ33_s7jEYr5RMxm34Yh_kCqJz6fJBkgVpFm 8PPPKJk9uassbVXdbJKRtAX6jT8xscelW9I5jGedNRzgJ.BgDSZ8JKZQZ7.aE0MTWYp7MXIR1ZZL hDg3ZJbHfSpwJ4l13wPeQxQ2DnNU1lQWAP6TsQ4h2nADXyYdttDUNXtRE83VSIcIZB1psl.xdtkN yH88q5.5uJONf31WQiWXZqEHzERD1jJH8TzUmZd3d6m97bRYQvEmYMKpYeQQefMzdiVGFM0GGAHh aw7IOR_u6bGGfRINt6FL79XN_Ro.eqJiDpqIAym.F.mJKidLXUZGq8BrfVpNiwMDlwWOVG8IRipL zdrpxK0pTkz3Ppi8rQCNg47mgVWSFdmklbmotYKa8x_oVnyYKGkPbqH3IvyKueuvXENEqCE5KFdF ntiryt4cthBqe.VAW9jrUeQIczBQVswomA0109yzGmmOMR0wIyGU8m4IL9RqZ80RI1ehRNViYSra SSW2_tAbO.O0d4fIS_8U1gan8U4X8yz1LcWPdiDo2tGLdQ_UuFbMQz1DzGWuhuBlgIN8uCUPUCgg FFK0RgKVoXr86KSUNCV0y61jQHGUiSOwTgoaqU3QHi3VoGES8Ih6gUq72AnlBFXjukD9uzTXQdRX jn0an29vrLD8yW1SqYGLweLKxvqFg08YADwFinmD4ITRr5HKcbGhrXQM7S7x0WcisxOOhgAC5IMP vxXLArdPek4fqhwKfL2i93C7.b4t9UHTekUR4T_ldGTXMfpGFjl92AvDS8Wmrwb3Ii6h.fq6y5Ij 8_kw0aQpBZhmfLmeOeOLYVTM5ilXeAVs7uIOs1xNfR2LuusMQDo9Ea5MTO0bI1iSw.1fQt7y5sQr o57W698zyd8I47FZaly_QtXUywBBmqMIDE6_TMDafjNaLxbWSv_9PNBIb4gw36ZRkmfsdTlpeXmF yoHSDjgzSnIJDOKYqpQxKlBseFyUEq7usBb7niY0ylkmQd3ETSFU46ebFME344Augs2GuSWzdO_A Pjo4.Td.Tj1UwwaoVwIulrzPnT0lxhL9m1OuNM5Nro2SFOrmGvhGKD9Kq6K3D15Ois.3cU0uWXqJ Vyt0WfElsmH1l38qV0HrBaafVqy_6_VPkWRZJLEXxnPpFl_59b31vkCjYbDiBpfEcCbo4hOjmcE7 E.Gaek1N4.nrSuH1O6I8CQ_Cl0d9qr8l64iTmrsBgdH9B.0Mc2CoZa1HQk1PigeNUK6BLuQqKij4 xj3H2_9HrqBlG7cvtAfLsIn9_8wWysAfrBP71tKi0nGhwOZeTtLcryOm4soxBKbzGHig4l80hY_Q TWoqRtBaG7QQlt3mgG_.sNvSjpf0Igz7E_2CgSMpOCJg.hELzzt.YlFzGjMHhIU6FTZpvLnG95E0 o5t5.
X-Sonic-MF: <stkent@verizon.net>
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.ne1.yahoo.com with HTTP; Fri, 9 Jul 2021 18:28:56 +0000
Received: by kubenode578.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 50e4130d85085fb55afad339db823ad5; Fri, 09 Jul 2021 18:28:51 +0000 (UTC)
To: sidrops@ietf.org
References: <162574988984.26098.17271669200254285008@ietfa.amsl.com> <YOc/X/fqp5RepPQD@snel> <3077EE58-C035-4A0D-91C7-AB44B33025D1@nlnetlabs.nl>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <564f0d8f-942e-e4e6-b97c-563564f235fe@verizon.net>
Date: Fri, 09 Jul 2021 14:28:50 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <3077EE58-C035-4A0D-91C7-AB44B33025D1@nlnetlabs.nl>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.18469 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/b7iiNLk73Nwd7Nq9MJ6RgXqREB8>
Subject: Re: [Sidrops] mft/ee validity time window alignment issue - Re: I-D Action: draft-ietf-sidrops-6486bis-05.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Jul 2021 18:29:01 -0000

Tim,
> ...
>> It appears there are quite some CAs out there where 'nextUpdate' and
>> 'notAfter' are not equivalent, I estimate it would reduce the global VRP
>> count from ~ 263,175 down to ~ 209,931.
> Indeed, I mentioned that Krill is doing it wrong (or well following earlier discussions but let's not dwell).
>
> The fix is in the 0.9.1-dev branch but will take time to be deployed. There may also be other CA implementations which are affected by this. Though generally speaking hosted CA services could re-issue all their objects without the need for users of the service to upgrade.
Good point.
>> I suspect the best we can do is demand that the EE certificate validity
>> window fully encompasses the Manifest validity window described in the
>> eContent, and merely recommend to align the two...
>
> It may be appropriate to differentiate between what a CA MUST or SHOULD do and what an RP MUST reject.

I agree in principle, but we have lots of experience in the IETF (not 
just in SIDROPS) that when a client of a protocol fails to enforce a 
constraint that a peer should have followed, we are endorsing 
non-compliance.

>
> What I am after is that I think:
> - a CA SHOULD (not MUST) have a validity period that coincides with the interval from thisUpdate to nextUpdate

First, I think you intended to write " - A CA SHOULD issue an EE cert 
for use with a manifest that ..." We ought to use the term SHOULD 
instead of MUST when we can describe circumstances that reasonably 
preclude adhering to the more stringent constraint. What circumstances 
would we cite as reasonable for a CA to not align these times?

> - an RP MUST reject a manifest if:
>      - thisUpdate is after now
>      - nextUpdate is before now
this is already stated in Section 6.3
>      - EE not-before is after now
>      - EE not-after is before now
The two checks immediately are required for any RP in any PKI, 
consistent with RFC 5280. We can reiterate this, but I don't want to 
restate all of the other checks an RP is expected to perform on a cert.
> One other note. NTP not being as perfect as we would like, I would advise backdating the 'thisUpdate' and not before a tiny bit, say 5 minutes.


I can modify the text to refer to this as a spec for version 1 (vs. 0) 
manifests, if folks want to adopt this approach to aid transition to 
more stringent CA and RP requirements.

Steve