IETF Logo Mail Archive

Re: [Sidrops] [internet-drafts@ietf.org: New Version Notification for draft-spaghetti-sidrops-cms-signing-time-00.txt]

Ties de Kock <tdekock@ripe.net> Wed, 07 June 2023 14:07 UTC

Return-Path: <tdekock@ripe.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 36CF9C14F726 for <sidrops@ietfa.amsl.com>; Wed, 7 Jun 2023 07:07:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.net
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 vVBpRADwLbCr for <sidrops@ietfa.amsl.com>; Wed, 7 Jun 2023 07:07:37 -0700 (PDT)
Received: from mail-mx-2.ripe.net (mail-mx-2.ripe.net [IPv6:2001:67c:2e8:11::c100:1312]) (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 42BCCC151547 for <sidrops@ietf.org>; Wed, 7 Jun 2023 07:07:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Message-Id:Cc:Date:From:Subject:Mime-Version:Content-Type ; bh=1CmBkYJ3rWDYGB0/D+rKm6NEq8fYTXDXKNfKKsRTdiM=; b=HJ2e2J7sZVCg1d4OjNHgRg/a Vm2+H43T7mTzJBjj4VJuK/f+hKIxpkAQKm8bL/83zI7sKZOOM3EASpPs/aK4g+424cqyHR+ZcaC5Y sjL1m8CcA61ULqZgVp+U1vbpKSE2hzkAYwATJ24oKtrl4ZO84XEpq+NWc2GMcFe8qZQDLBgw6VH+A 5mqUalUDP2QUxmXVQZF27V32uo0ZULh2rj7Wdeg4NMdQfLUHPlZR7DYLuesMA2Ok6rd0OfTz2Qv6+ qlScIFaDHjrm/9EyDQtXgSlVxw/h3S0o8xp+M1VxmU3B2oI9HaT8I9V4eGB16e+3emEv23UsE2aXm MPtRSbyhdw==;
Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:41814) by mail-mx-2.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <tdekock@ripe.net>) id 1q6toz-0073lZ-2C; Wed, 07 Jun 2023 14:07:33 +0000
Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=smtpclient.apple) by bufobufo.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <tdekock@ripe.net>) id 1q6toz-0007N9-1s; Wed, 07 Jun 2023 14:07:33 +0000
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: Ties de Kock <tdekock@ripe.net>
In-Reply-To: <ZH/Q+ea0HO542GV3@snel>
Date: Wed, 07 Jun 2023 16:07:22 +0200
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <710534A0-B529-4609-9845-96BCB9139381@ripe.net>
References: <ZH/Q+ea0HO542GV3@snel>
To: Job Snijders <job=40fastly.com@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3731.600.7)
X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e1b1d323cb457d231aa543e70a2838a642
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/awV4fuTZ20XHY6ReDn0dWDOpUdo>
Subject: Re: [Sidrops] [internet-drafts@ietf.org: New Version Notification for draft-spaghetti-sidrops-cms-signing-time-00.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: Wed, 07 Jun 2023 14:07:41 -0000

Hi Job,

> On 7 Jun 2023, at 02:36, Job Snijders <job=40fastly.com@dmarc.ietf.org> wrote:
> 
> Dear group,
> 
> The below internet-draft provides a reference for the concept outlined
> in https://mailarchive.ietf.org/arch/msg/sidrops/I4-3BPR-r0vd6CguWxV-cLs3fyY/
> 
> This internet-draft describes a use-case for the CMS signing-time
> attribute. From my perspective this internet-draft is complementary to
> Tim & Ties' draft-timbru-sidrops-publication-server-bcp-00 document.
> 
> The main takeaways are:
> 
> - set the file's mod-time to the CMS signing-time on publisher and RP side
> - CMS signing-time becomes mandatory for Signed Objects
> - CMS binary-signing-time no longer is allowed
> - 100% backwards compatibility with all CA operations in the field

I assume that you also want to change this MUST in RFC6488 2.1.6.4.3 (and
the similar statement in 2.1.6.4.4):

   The signing-time attribute MAY be present.  Note that the presence or
   absence of the signing-time attribute MUST NOT affect the validity of
   the signed object (as specified in Section 3).  The attrType OID for
   the signing-time attribute is 1.2.840.113549.1.9.5.


To me this process feels like a search for a use case for signing time.
In the intermediate period, tools writing consistent time need to fallback to
not before. This makes not before a more elegant (as in, simple & neat) solution.

If you propose alternate behaviour for the transition, could you elaborate on it?

I do not think backdating is an argument against using not before. In your
proposal, backdating MUST also be applied to not before.

In practice, we have observed one of the faster RP implementations (rpki-prover)
reject objects because due to minimal clockskew where validation started _the
second before_ they were valid (RP ran on a machine using multiple stratum 1
NTP appliances as time server).

If a CA publishes fast, it must backdate to mitigate this issue if it wants to
be resilient to minimal clock skew.

Kind regards,
Ties

> 
> Contributions to this internet-draft are most welcome via
> https://github.com/job/draft-sidrops-cms-signing-time
> 
> Kind regards,
> 
> Job
> 
> ----- Forwarded message from internet-drafts@ietf.org -----
> 
> Date: Tue, 06 Jun 2023 17:26:40 -0700
> From: internet-drafts@ietf.org
> To: Job Snijders <job@fastly.com>, Tom Harrison <tomh@apnic.net>
> Subject: New Version Notification for
> 	draft-spaghetti-sidrops-cms-signing-time-00.txt
> 
> 
> A new version of I-D, draft-spaghetti-sidrops-cms-signing-time-00.txt
> has been successfully submitted by Job Snijders and posted to the
> IETF repository.
> 
> Name:		draft-spaghetti-sidrops-cms-signing-time
> Revision:	00
> Title:		On the use of the CMS signing-time attribute in RPKI Signed Objects
> Document date:	2023-06-06
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/archive/id/draft-spaghetti-sidrops-cms-signing-time-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-spaghetti-sidrops-cms-signing-time/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-spaghetti-sidrops-cms-signing-time
> 
> 
> Abstract:
>   RFC 6488 standardized a template for specifying Signed Objects that
>   can be validated using the RPKI.  Since the publication of that
>   document, a new additional protocol for distribution of RPKI
>   repositories was developed (RFC 8182), and new insights arose how to
>   query and combine the different distribution mechanisms.  This
>   document describes how Publishers and Relying Parties can use the CMS
>   signing-time attribute for seamless transitions from RRDP to RSYNC.
>   Additionally, this document updates RFC 6488 by mandating the
>   presence of the CMS signing-time attribute and disallowing the
>   binary-signing-time attribute.
> 
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> ----- End forwarded message -----
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops

v2.23.0 | Report a Bug | By Email