Re: [Sidrops] I-D Action: draft-ietf-sidrops-cms-signing-time-03.txt

Job Snijders <job@fastly.com> Fri, 19 January 2024 14:24 UTC

Return-Path: <job@fastly.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 E720CC151701 for <sidrops@ietfa.amsl.com>; Fri, 19 Jan 2024 06:24:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com
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 3LYhd-PARn7a for <sidrops@ietfa.amsl.com>; Fri, 19 Jan 2024 06:24:03 -0800 (PST)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 3A594C1516EB for <sidrops@ietf.org>; Fri, 19 Jan 2024 06:24:03 -0800 (PST)
Received: by mail-ed1-x52d.google.com with SMTP id 4fb4d7f45d1cf-559f92bf7b6so1549914a12.0 for <sidrops@ietf.org>; Fri, 19 Jan 2024 06:24:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; t=1705674241; x=1706279041; darn=ietf.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=thupMp3b/fYSrnPL3+qnglSCXyEY47CwdFtF6DwnEB4=; b=DPt3M+VhSDFOpt+TeeI28CeiK8aZLno1O7ivpHGz373XPRCK+liRUXmPu5drLHKRiF 2mH8YXJIhxlD6CAStpJB1GDtjk/B4Iv/AJhIyJuo0p3V3/mN2Ehtf8be/xPXuHmYCPpK MSkSOP50mSddmcvPcciQDp3SL9SS+baKOnaHI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705674241; x=1706279041; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=thupMp3b/fYSrnPL3+qnglSCXyEY47CwdFtF6DwnEB4=; b=FV5cusCcaTTRXgVbFkU4ThBqd28gBWkAvlvh5uru/kYc7drxSxr65tW9UvJA0UTgJn IlvrdMvKmgsoWlP/KoLEbHz0oek7mRL80Ycg7blYd7UNKSeFe2gvYV6Lk9n1fmSGpFWC EKoBSUg2i9bg6mEb7AhVvSznBRKHNPVR/+emLg7w/9FEfLNAVgthV48Eyjxqy8KUzoQ6 p9fOI7pxLshfoe7mt7FtTXbO5S+3Y+pMNtTIcWZDGPzU7acf5iXtfqHR+W/41/ktaBhk Py4b2RmPVYm96Aa4SfyiPUbEBS38cL82jQonZTZFcZAUnQg3k7L5R5gBpWX2uRZ9S2Pi aBnw==
X-Gm-Message-State: AOJu0Ywe3LAGz9rtty1qvClE0MiJqi4WzsF+BvZ8/hGMNcDWh/NRlo61 2yHZ+9EBqcNYS07pO+vte8HcA69EPAN/1enzHSMQPEw//UA0aT7UGu2Ih/ry/fapgNrHmGb9yC4 e
X-Google-Smtp-Source: AGHT+IG9C7cy1nyNaX+VHGdG+0EsG02kmblenzJ9l8cYeY9sBfkxjcOYeA6nZhCGDQuWO/mDsyhcZw==
X-Received: by 2002:a05:6402:128e:b0:559:b3b5:6e16 with SMTP id w14-20020a056402128e00b00559b3b56e16mr1283932edv.34.1705674241499; Fri, 19 Jan 2024 06:24:01 -0800 (PST)
Received: from snel ([2a10:3781:276:3:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id s24-20020aa7cb18000000b00558e38d4c6asm9175271edt.93.2024.01.19.06.24.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jan 2024 06:24:01 -0800 (PST)
Date: Fri, 19 Jan 2024 15:23:59 +0100
From: Job Snijders <job@fastly.com>
To: Ties de Kock <tdekock@ripe.net>
Cc: sidrops@ietf.org
Message-ID: <ZaqF_7W-EMiYljxd@snel>
References: <170561454824.54895.360140302624981870@ietfa.amsl.com> <ZamgKc5PTJPDcISD@snel> <C10EC4E3-9A59-4BBA-B5DC-DB4680AD0B0D@ripe.net> <ZapR2qVBAu7lECFB@snel> <7547BE09-8FF6-40F4-BC6E-388BAEFE6CD6@ripe.net> <ZapoTxRlSvSSVqk_@snel> <5AF9DD6B-A4F0-4C20-9E0E-62144D013D44@ripe.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5AF9DD6B-A4F0-4C20-9E0E-62144D013D44@ripe.net>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/7vw2Pc5w9ESiZM-DGGsQkmrSPJ4>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-cms-signing-time-03.txt
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, 19 Jan 2024 14:24:07 -0000

On Fri, Jan 19, 2024 at 02:19:57PM +0100, Ties de Kock wrote:
> > Aren't all bets off when implementations are noncompliant? :-)
> > 
> > I think I agree with the gist of what you're saying, but I'm not
> > entirely sure what to add that's not already covered by existing
> > literature.
> 
> Let’s add the local improvement somewhere in the doc, maybe security
> considerations? “the status quo is that most implementations are not compliant
> with RFC 6019, this causes signing time to be ambiguous when interoperating
> between implementations"

How about this?

https://github.com/job/draft-sidrops-cms-signing-time/commit/9f43dfa84f7293dc547d46154f0f5296fd5533fe

-----------------------------------------
5.  Security Considerations

   No requirement is imposed concerning the correctness of the signing
   time attribute.  It does not provide reliable information on the time
   the signature was produced and it bears no relevance for seamless
   switchover between RRDP and rsync.

   While the Security Considerations in [RFC6019] mandate that the
   signing-time and binary-signing-time attributes, if both present,
   MUST provide the same date and time; a potential for ambiguity is
   removed by restricting the RPKI Signed Object profile to have only
   one field to store the purported signing time.
-----------------------------------------

Kind regards,

Job