Re: [Sidrops] WG Last Call for draft-ietf-sidrops-cms-signing-time-04

Russ Housley <housley@vigilsec.com> Fri, 09 February 2024 16:10 UTC

Return-Path: <housley@vigilsec.com>
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 BB986C15107F for <sidrops@ietfa.amsl.com>; Fri, 9 Feb 2024 08:10:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucLrlB5WP16C for <sidrops@ietfa.amsl.com>; Fri, 9 Feb 2024 08:10:48 -0800 (PST)
Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2BD8C14CE40 for <sidrops@ietf.org>; Fri, 9 Feb 2024 08:10:47 -0800 (PST)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 4B11F17ADA1; Fri, 9 Feb 2024 11:10:47 -0500 (EST)
Received: from smtpclient.apple (unknown [96.241.2.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 3ABEE17AE08; Fri, 9 Feb 2024 11:10:47 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <84542197-7A9F-4AD2-93AF-3E2BAD707F70@ripe.net>
Date: Fri, 09 Feb 2024 11:10:37 -0500
Cc: IETF SIDRops <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FA823605-F5CD-4CBE-A736-6D4F96C4CF79@vigilsec.com>
References: <C61AE8CA-3692-43E0-ACE4-8BB0DEDB6D8B@vigilsec.com> <5467008B-80CC-4E5F-828F-B30EF76DAC88@vigilsec.com> <84542197-7A9F-4AD2-93AF-3E2BAD707F70@ripe.net>
To: Tim Bruijnzeels <tbruijnzeels@ripe.net>, Job Snijders <job@fastly.com>
X-Mailer: Apple Mail (2.3731.700.6)
X-Scanned-By: mailmunge 3.11 on 66.39.134.11
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/V11ZT5Ovrk1NDjPIskYY9zbP0HQ>
Subject: Re: [Sidrops] WG Last Call for draft-ietf-sidrops-cms-signing-time-04
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.39
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 Feb 2024 16:10:51 -0000

>> Title: On the use of the CMS signing-time attribute in RPKI Signed Objects
>> 
>> Authors: J. Snijders and T. Harrison
>> 
>> Datatracker: https://datatracker.ietf.org/doc/draft-ietf-sidrops-cms-signing-time/
>> 
>> Should the SIDRops WG ask the IESG to publish this document as a Standards-Track RFC?  Please respond to this WG Last Call by 5 February 2024.
> 
> I support publication.
> 
> However, I am not sure… but the informative references to "I-D.ietf-sidrops-prefer-rrdp” and "I-D.timbru-sidrops-publication-server-bcp” could pose a dependency problem?
> 
> I need to talk to my co-authors about the first and see if we can agree on a next step. I asked the chairs for a working group adoption call for the second. In any case, neither document is expected to be ready for last call soon.
> 
> So, my question then is whether it’s okay to keep references to specific document versions as work in progress, or that this (cms-signing-time) should wait (not preferred), or that the references should be removed?

I see no concerns with [I-D.ietf-sidrops-prefer-rrdp].

However,  [I-D.timbru-sidrops-publication-server-bcp] is in the same sentence as a SHOULD statement.  Some IETF Last Call reviewers might expect a normative reference.  I think this can be avoided as follows:

   To avoid needless re-transfers of unchanged files in consecutive
   rsync synchronizations, [I-D.timbru-sidrops-publication-server-bcp]
   recommends the use of so-called 'deterministic' (normalized)
   timestamps for files. When the content of a file is unchanged,
   Publishers SHOULD ensure that the last modification
   timestamp of the file remains unchanged as well.

Russ