From nobody Tue Jun 1 04:55:20 2021 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B003A14BC; Tue, 1 Jun 2021 04:55:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.30.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <162254850940.21511.7705866904603946159@ietfa.amsl.com> Date: Tue, 01 Jun 2021 04:55:09 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2021 11:55:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : Manifests for the Resource Public Key Infrastructure (RPKI) Authors : Rob Austein Geoff Huston Stephen Kent Matt Lepinski Filename : draft-ietf-sidrops-6486bis-04.txt Pages : 17 Date : 2021-06-01 Abstract: This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-6486bis-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-6486bis-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jun 1 06:36:32 2021 Return-Path: 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 63C363A1879 for ; Tue, 1 Jun 2021 06:36:23 -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, 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] 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 AtTKzC0xmfSK for ; Tue, 1 Jun 2021 06:36:21 -0700 (PDT) Received: from sonic304-9.consmr.mail.bf2.yahoo.com (sonic304-9.consmr.mail.bf2.yahoo.com [74.6.128.32]) (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 EAEF73A1861 for ; Tue, 1 Jun 2021 06:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1622554579; bh=pdAegheOtErItZYlDTdHxnhmrFLaAG8TQp7AX83lOwg=; h=To:From:Subject:Date:References:From:Subject:Reply-To; b=tNW3s8hk0c5JUkVXO3fduPqRfWbrGyvOz/FUrP8EyM+uuxqo3+Kfr5Mkf5uq3a4EHY/7IY753SI9OeI/RzV5eBDgrQHwnBFcBWZdKiTG1JHNWZDaehG9LTV5k5E7s89OaTwIiHeBTmNFE4sNItxTOKacldL87XfHvoGlEdKVkT/aWoA5rhSOz3nVh/gbFw0PmT8Ds5fTHqQnnxuZXhQwl9G5Y79lSyVzvB0q5r76CuJ0ej4AyB+TX/Q5V2Du9E7+9aPDQqoxh3sj8B3XVIy/sbSEmvkvKOmmnCtWlwMz6Gb5S3L60jwEyXC24PPvixrYC1h+/sdcE5KZiu7BmR1vDQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622554579; bh=tTk22pL7PMhlbg1rHBU0NS4JDBtEj8ukN19IwN7AVov=; h=X-Sonic-MF:To:From:Subject:Date:From:Subject; b=I0mG5SOM3Dz1f1xgGYusGZoJuflKmoiRG5b0i9Gl6YjAidUd6iOIAzxYBMvOyDxFBzGesztm+w9Vx8NWgwqF53lSIHFE+TKlTx1B+N+JN37apAp3Z9v+hsx8ZhivvrOgqPdfhBJg7ie5mgTykiHrGVkWG5BYe8lBLPQDGXS22EFahhgqHdJaJikvAZThO0llBNw2PmLMPpE818rtovS6I4PHnC3MLNJCruDloVR8SZ3Wy/RA5oHRqtw922QWsgWj0cbfavuDDfl5p1ExPAO56bLSskBVsRVFRhBF1WqgSGVL0LdttFrTlG6MmbWDcVYFYbjxbChLaKBDoDeedZkMmg== X-YMail-OSG: xwLPa6EVM1l95fzwjgFGFGWwzPZLMamJnWljYICSait285Ak7Arge31BujRx1WJ 1iKB3f_qjC7kA2KQ_LtTC3hyxSXCEwQgLDm_P36rIYFVJiW5ywCIAqQsY8woE.duO5AiAxouSTgB R3u32okZsw3lIQcTeYXO3ZW93e47v5BZ4_h1phI8YXmen_3aKdjU743ih99NwyL_Ot4mmUZpbdNZ MhhuMRX2931TdREeJCidg2xNllkv_QEUb4AwevK5sQkYfmRpH9TrCKSA9Lg0OhsmG91_7UqtTMza uteULCBDYHX_SAwJUPMAkPZ81i7bPJ7zA9qWsHAYJSmz.sIszJXn2jnLx0OWrJDHiL51FMGnDjJJ 2UHY8.cJWiJgHFBH3K3u.O8O4BNkRns2J8IAFdapKDeyhaVTdabB2zDdkKABbF1j_Ozt_zyaYrx9 DXdvbPxwwoXtCIsfv5GVhnoMdcdO2tvQ4z_A7s6du1pcwwde7AyPNYf_f0sq4f3KjOpBbj86gAVm S2SziqCnsnt1ylT77iKbWyvkf0cEeiVrq7mUF0ilGb2WWuhWTvqfpsEVRrKe7PLh_vR1pdl2Kjpt rXivuOuPgYnCfVZS26Jo8W8HdzPTLKT96coCSrRE.pnhW8UVSeOlW8Hol8C.JS_5EhVgV6NcC2st _0sP6m0A5.fZeYTtiHJFlbN2E6bq91U8YfThIAFM20OPrwBWkEuDplKs2WmZE4P8yMvgnsGis9ie ohYvLt0tdaVBZsC8jD3u6XXV0._vIGt5wF169_CpS8C7W6TpzeW4tdBbqVFZfEDNxlk3MRhJnlcK wlp.DSntpJ77jrUkSjM7KWs.oNkRN0TYD4sOHXitXzDQ39cdpvpOh_KR.kiKrzOVKsdW4pE8UXbt ysO3Cf4OiMc5TpnGviIKY88Udg5w34OBfwk.YIm7asd7tsh9O9erId6Oggy99bnlXehcN5XwUEW_ NHM8.b44lci179xW9_erm59qhsLbWfCihDcRvK5fvFxOpJkYI9cxYma7v5J_0LJZLtpUpA.y6V2g wllAFncrOu.vHN5VwlTuxOtkwZmO5oeZ4sXQoSiVIZsb71rDHrbHGwO9CImH_7DmtnkYEoQ4Yg3M pVmTyhFOiPgTME.seg.zXqHDH4A0V3EMNSsuaEXjFFCjZ32.YVUufCTmQDbSFY4a0cGD9oRtlG1y kBIi.3iukzCNxeS_NN9EgqReVwxsES8HP3M4sboK9DIIYNZpA0GVRaViOvzBv1tb3EGX6ob.P.Nh fzNHxfUxBNTq00eon0F4kV6kEt9lQW72pqpdkse.AeBXsysV8y5Pof.5pvN7NNuDlOaigNcvDEJU waqZzKajKmXHsg27yhm1NLtPyDBfi8DJhHup51Z90fmqJDppfyo8QD7E6lmlZ_TT_egIs7t0NU5u YlL620dNAuUJX0r0phiC.sCAvxnq_HrGHQZ9z4kdWUioRQ2VAWfJ7YltiS0qu8n7_F7aitD28J3T jP6hpRahcN4b3wS7Eii_W09IGj7.ppkJQe3mOkteo6v411LZo6zO0vj2oYDizSbS8lN5BQCIu5P2 KMYEQ0X0zm3_S6QCAqsMnkW47Q9lpXmHX0c25RPNqd96JidDdmY63yTfEamp.Yqy_WrEiqyJJgff 6m9am_mMNStUTkGLZycZkeJpVbkifznfslth9smN3cwlEZS86OuAZQAgbmwq5KsWYjTiNqIesIFo blVud_r9zvtlgYp1g5GLnXAYGFYQXTzNMhQ_v7d_KBeKOXtzy_mDvUMihccI5zimQ_aRZR2rmgPw WovAeS8wlcG9frcW987UyEhNsYNGXLsqu4L5KhsAzsknWsEpeBupWaI3UheHxdvd6qgko.of1ZIA gNBA5objiLwm_Koo5SApD47MvCp9SvO0m1itPgKlfz8PCOiVIR.cuGnPJiAP1AQqyQSocKUA6N4C pTvJYJEHAQCSjzk3BaIY1IiW4Rwx_zxttgKCkeJC_YYuyW5Lk.BGUXaLm0YBUYXaDXCnFiZTwzCR SMF3St8DQ_tC6xdK_f8fIdfBcK9OsrlckixqUxBcvmhCXg6gzXob3wLMq_X4sh3X5kqQv4r0Lsfo izavuHqFGoJ_Cht3bFBCaPoNg6rXmWU6yWTEbi._ptvUxXQUOtd3eSVVbo6irMv_IjTk4kDt3xns jY_Jgb2m7sedkQ6PK8HrSCZYaaXJXity8rKbleZWYZwQLg_CcO2T0a6d3ER8JO70GA.RSEMxbN.4 C7Zk.b1EWhsHa3x_MiBesRa50YdMG.OtzTgZT5dHVn05PswVBJ615nnj_37rwpggCsgVCGrhzzH1 FyN5F01nqck5VRut15AQMxjG.hmQZ7vIOW7I_AOCNn8dmseCm0tyJq98O7kH9kJ_OpIBE_624qI8 wqUxd5OQ- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Tue, 1 Jun 2021 13:36:19 +0000 Received: by kubenode514.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1f0c6fca05c7412894707ad286342bc7; Tue, 01 Jun 2021 13:36:16 +0000 (UTC) To: sidrops@ietf.org From: Stephen Kent Message-ID: <4576a83c-4118-9e4e-aec1-e8e9b0a1a069@verizon.net> Date: Tue, 1 Jun 2021 09:36:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------14BC6978C2EAD2820F39C284" Content-Language: en-US References: <4576a83c-4118-9e4e-aec1-e8e9b0a1a069.ref@verizon.net> X-Mailer: WebService/1.1.18368 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: [Sidrops] draft-ietf-sidrops-6486bis-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2021 13:36:31 -0000 This is a multi-part message in MIME format. --------------14BC6978C2EAD2820F39C284 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit I revised the text in Section 6 to reflect the suggestion Ties de Kock made in an off-list exchange in late December of last year. Although our esteemed chairs said that someone else would assume responsibility for this I-D early this year, that has not happened. Moreover, there has been no more on-list discussion of this topic, so I elected to complete the agreed-upon changes and publish an update before the old version expired. Steve --------------14BC6978C2EAD2820F39C284 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

I revised the text in Section 6 to reflect the suggestion Ties de Kock made in an off-list exchange in late December of last year. Although our esteemed chairs said that someone else would assume responsibility for this I-D early this year, that has not happened. Moreover, there has been no more on-list discussion of this topic, so I elected to complete the agreed-upon changes and publish an update before the old version expired.

Steve

--------------14BC6978C2EAD2820F39C284-- From nobody Tue Jun 1 08:25:41 2021 Return-Path: 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 379FA3A1C53 for ; Tue, 1 Jun 2021 08:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_SBL=0.5, URIBL_SBL_A=0.1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.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 aB1MHx91h2Tk for ; Tue, 1 Jun 2021 08:25:27 -0700 (PDT) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 0654A3A1C4C for ; Tue, 1 Jun 2021 08:25:25 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id h24so18407797ejy.2 for ; Tue, 01 Jun 2021 08:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=o7IwiuzrJ4zPZB+9G26fkrJ+CSaTiBvu280jgxNLSEE=; b=PymnQc6i2AudAVJvMEzrChL6iG76vqifLQxzhTkU3lthB85rALkNW9y4XAFb9SAw1q uMF2T81BANSa23ZHYd6zyJPtYjcwihQUmPNy0oK88v2XiYpg8Q5bFjNgTZBza7bVCDsN XXRhiIp3PUeY53Z45mcRNA+ucoNZjbebVdlg4= 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:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=o7IwiuzrJ4zPZB+9G26fkrJ+CSaTiBvu280jgxNLSEE=; b=UD8HSOToVH/pjimygN2mMZeWyqcx4E5UJGRv/GK4yM+xrFlTljC83LsRuujrEmNXey opS+EaBqAnmWwc8e4Snf5eT+Kk7D+rMOa/eRs3/N09t9hNnDMrxeogcGF4xt6dFZPwLp kdrRcbcIeP4sINI7oICopPCQSVjZGAhyp/A+Ai8HZ5Nh49Lw/nc62EfMOmMLth91IFTQ ZvRU6hjT8n0jqeQMxWgBuY8yNoes8OIrFrcXvqeouoqfHGYausukkyOLFmDA44r73Xy3 lypZbL/bhnj6MmlvolO0mON6s0bRfg7iCpxNpVBfvvQ1m/kPq3prAU1jjvZZiqQxw+qd kZ3Q== X-Gm-Message-State: AOAM532Gj7N432Vvl+0p5sj8BT1SzGq6uS8/NZ7iVcx04s82eLybqvfP 1JJCrYHTLrZtgNZ19L5fSCBUOQ== X-Google-Smtp-Source: ABdhPJyYadFlhG1LacqDRtdZ4FTRuHKtP7vVoM1p8yipqB4rWRYvMHJDEdP0r+6BeOckJNUUFbjJHg== X-Received: by 2002:a17:906:26db:: with SMTP id u27mr30322622ejc.532.1622561122941; Tue, 01 Jun 2021 08:25:22 -0700 (PDT) Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id d24sm3142493edp.7.2021.06.01.08.25.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Jun 2021 08:25:20 -0700 (PDT) Date: Tue, 1 Jun 2021 17:25:19 +0200 From: Job Snijders To: Stephen Kent Cc: sidrops@ietf.org Message-ID: References: <4576a83c-4118-9e4e-aec1-e8e9b0a1a069.ref@verizon.net> <4576a83c-4118-9e4e-aec1-e8e9b0a1a069@verizon.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4576a83c-4118-9e4e-aec1-e8e9b0a1a069@verizon.net> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-6486bis-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2021 15:25:40 -0000 Dear all, On Tue, Jun 01, 2021 at 09:36:15AM -0400, Stephen Kent wrote: > I revised the text in Section 6 to reflect the suggestion Ties de Kock made > in an off-list exchange in late December of last year. Although our esteemed > chairs said that someone else would assume responsibility for this I-D early > this year, that has not happened. Moreover, there has been no more on-list > discussion of this topic, so I elected to complete the agreed-upon changes > and publish an update before the old version expired. welcome back and thank you for your efforts! I re-read the document and was wondering whether it is useful to retain the section 5 text about 'one-time-use' vs 'sequential-use' EE certificates. Perhaps the text describing the procedure would be become simpler if this (for RP undetectable?) difference is not highlighted. OLD: """ In the case of a "one-time-use" EE certificate, the validity times of the EE certificate MUST exactly match the thisUpdate and nextUpdate times of the manifest. In the case of a "sequential-use" EE certificate, the validity times of the EE certificate MUST encompass the time interval from thisUpdate to nextUpdate. """ NEW: """ The validity times of the EE certificate MUST encompass the time interval from thisUpdate to nextUpdate. """ ------------------------------------------------------------------- Section 5.2 - could perhaps benefit from some tighting up. OLD: """ A new manifest MUST be issued and published on or before the nextUpdate time. """ NEW: """ A new manifest MUST be issued and published before the nextUpdate time. """ I'm suggesting this edit because we should encourage operators to make before break and not do things 'at the last moment'. ------------------------------------------------------------------- In section 5.2, """Repository operators SHOULD implement some form of""" could be upgraded to a "MUST"? Repository Operators should be encouraged to consciously avoid potential for race conditions or failed fetches. ------------------------------------------------------------------- The paragraph describing "chicken and egg" (to me) seems confusing. I don't see a 'circular dependency'. The Manifest's EE certificate MUST contain the 'X509v3 CRL Distribution Points' extension which tells us where the CRL is, and ADDITIONALLY (in a later stage) the RP confirms whether the digest calculated over the obtained CRL matches the hash listed in the Manifest eContent. But whether the hashes match or not, or whether the eContent even lists a FileAndHash entry for a .crl file at all... is a moot point if the EE certificate has been revoked and its serial appears on a signed CRL... right? Kind regards, Job From nobody Fri Jun 4 12:02:14 2021 Return-Path: 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 5C1193A1E5F for ; Fri, 4 Jun 2021 12:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 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_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 PrlmtPtA11rB for ; Fri, 4 Jun 2021 12:02:01 -0700 (PDT) Received: from sonic303-3.consmr.mail.bf2.yahoo.com (sonic303-3.consmr.mail.bf2.yahoo.com [74.6.131.42]) (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 17EDB3A1E13 for ; Fri, 4 Jun 2021 12:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1622833300; bh=WPPYiIAj3Q05REAKsQWzVWVWgQMTX9MfdqrX9Hx2m9E=; h=From:Subject:To:References:Date:In-Reply-To:From:Subject:Reply-To; b=tNS+G2Sm2j93uFZgkUVkGr4a4NIx+jr8A9s31lht3fVQC34ldy0NfJZzUzgnDqcnpA076CewhIozR+HCKTVaXBHboBXOcDV5sRkoEtA551SjdGt2fMCVpKu1qxFm000a1KV+saiJ4jUwqBcZjebu16eK+ouclsaphPI2cAAcYgCe4SKu8r5z6ecMnFKEXDaXCecKUl0wU3ClvZFyMfVpYixuZ5r+4xGaBtf9FoP9WWpfVZKyFzm/Z0ogT1NVA/wFSqQHTOgiMzGne7uOb5VLrUUOJpW3TStEDIPGGj7rKan4mCQ8kp3GsWYtaUdjVuCGRjP7GRAYGpOdhJ3UiqjjaQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1622833300; bh=WIhSOxRUXlggxJYysFnNvT9ne7bbenwGwqe+WR6mnm/=; h=X-Sonic-MF:From:Subject:To:Date:From:Subject; b=ub7Um6QaWQbkCz82omaF6Nd36DnJJZdWiDrlY13xA60/QJFpnPJnye2lmvHdBhKuDygEVa65TN1tGUbPz4DbNl4aq4uMxg/Zh31LiHzhjcm5k20y+/bXxrsG4RsFceE03oM9wEjZpZwTQDLh2LJ6JGcWjsHBqfCkUBB68ud0fcUlfbCPPqmOxE+5hWFyTkncJCU7vxVL6YDNka68LPK8K9vkYhqpiULi34vrGzfKIKeclsxA7U3GM0Hui7E5RUfR7jZKHPAaNhGhakFUy4I0q0BaxI7oOpaEuCQJYSKHQlmYeQLVCjBXOUQgfdjtFex7pwPwEiWTEx909SzwqcoAbA== X-YMail-OSG: 8mVPJLMVM1k3Nb9KNXLQB6mIa8j9kVrbjz6RWYVaKT0wC3lRVw5SIJghmgnceVW 9fbvPN5jieIPDEAiIdcC_xob6AiAgF35nhgBNadgRaa46IYp8hUxVZqEn.88A5haatDTtRONn_fa tbp3QSIynA1w1dICZCqnrSLnVC3lqoWhlBUcmr6t3ggp9WjbICwW0MXjpD4vwqsz3wM2JauvYEt. 1MPFSsqxlVbv27lS51xzZxR_.rObq3z2AzB0YGq.x7wCFJgH8YUwx29RtfTEb.m64HzL2qJlxMIC SzeJvI2s32Q.6Osiou69CvKDLd6VYf5eQAL2SSsf3FoQstCuqY5hS4iM6dNpWKYo0FujQOzhBWjS AkpYL9frv1E7Rll0rOJ.fiKxWELOR6yFoXpx5W11KvrWBXcljhaVSA3SgxL14CZr_BFYQzotD9HR TLAMnAmyLm24_pEWJeIADw1MAzYISQYINyI48w6pspItIy2cKSueg8OHq8hIlL58eyJOntr2aPpu HRahxjsDI8USQf5HTfL3mN9OI.Fx.GKuYpFTEE3wfhqP.2NnIa8SoXXbOhQq0YBIKKlHsHi8b6ae TmsRhGYutbhfTefgAllWpiaIAPQ3hMxrF7uZQohCJz3pG4Xr7O9VkYWxIEwyxM3jFbnnlShaM_3R m5VX4WW75YCz.WCkI8pQwM3qvPdRLouhI1tN2h06WHAgXYfLUKTSEhYd46mdmmHEhIR49icFULAk cBspcdTzO_2tAaHhxLdRbraxSU4UUuz_pnaTeTE3_F0VFaHzEXVyIFQ80a1Cyx1JiXkiOQ24tgId dXjdLeumO7o6Tg1hJzUdwKgQDjak.VvI5zX_UH5.P1Se1_p.uLy.TLuq09iOpWMy.q6TX3JQNcHD u0HYua7iDzVeFrdCdKBGTFY5Ks.5wkwXYTeohZiC0271VGbg9k3E4j2A1Kd8LJJltXCq.mVse86L Wcc90aX.m5jyOBUexV4sw.FoZ_oxndIe1lkGlDvlsXEo7N0HKqVbTTAQG.81TiQFYh_w7gQWQe9. UJjgxFQygufiyXBLb8AU57ADfD6UI21keioae9mDUWtOrWOWEEBKOvIqR6YclnwbKHDVzJ9f4cEI BroQKIIX0pdlPchQZF0MKyKzUwsLW9nfcfuUs4B14YpmBA5fGH_HXIT2rk3JywAmOlEIdjuw6ORS 9haLh9aexsUtAp7yz8RdRwTK1QpvF_N1vW7NjUvfnIdH5534huL2kzHEBtvUgz6cxKINheLbn8P4 9H27VxiMydNQ1eo3kWoG0WNgC1bZW0KsiD3Vt_KpwjmS59O8vSdbbLG7MjEDYepF7FwU28rBKS0E OLGZnAJzcXihPtqng.CSzaOQar3Gma5XoV4ocmt8wRQRnWZ8Vzr39vEHA9sAj66EyddpMz3iZb0f h1c7QQp_EhV9UuiLuqhBLu3ynRhzh6O6lmYsYswiozQ1oOe8pZafb2BPNeyVtj6APvtwzGbSdDmn mCju.qnSxYMWpIXFUK53ut.nMzzijFQnOQF0PWeuscK4CRFX_oGcxA.9vi3BSvuLxOJ09Y1CczJD GczkgPGF6XI.UVc6l6fFqYMl7IZ.fu0jQoBl9Z58EZSAIfwws7ws2BuxQgEe1IREXxUqZYiYKJCv 7a.O2D5ei1pxCuFRVt36zWc7Rszr2Sxzk2SLAgFAWpV88XvN8vypTLCRkEx0MQKN5PU1ZlDCD17H _Byl7EnElJj0GZ6hiC.qVRxNqZUdLpfv6TtomSkAjwmdk4ZzlE0nMgrzGzCCPGhT6_PTwnKVPGKv 9nV7W2bLOCmFmQ_MZ7r.kXyQVFZFBeEewmn.xlQ8wZdOd6Ttl5v4ArGhyvkX41OT.OObNBeAaciy EW8Riy_QcN8eRSf.8dYkzSnqGEtEwCeupd08QirmD7okAjZtxB7_rFPWi5kwLsE_kqN.jxiYeRG5 2zwVd6TO208WA1IIokMrvoCVlOySVLcCp.9CZsQjhmL9la43gGseio8ICfyGXz56Uf.VT1wSOWl7 q_W6r48awYdzZFVu6mm1Rv0V91pkRNoSgsgYYxUPXgg0If2R06yyFrhyzFxlod82IqBCp4qGPyQ2 ATkL2LXzysArpm3eH61hhzxtjHu.A7QVDGIOqRDeroNxI5PWrP_GMxCdNp9CciZg8Uju5jrZftr7 Y4MRWtjNAHX0MdC80sZ4dSu.0v47uGTpi2WaRJHS5lZsEcBcjWDdEDq3WXjj20y.gJ6y7I7YuZif Uh41qhHLVBCWQWC8jAzHfrBqqcsKYjre.6T8poq9gH4eoS9C7a8VA2h1JS.ugn_qnuF4v1FiVucF .T22GYvYrYzhS4P5hxKhFom43U15xVJcWu_4QkrtKWq_uBkTngeg6Ob.lC.CsAoECYaHrnwtBlE2 OknR7mUQdhG6l_3tgsKiGLr7BrEWOaO5F8mvzD2JdAMEkJJTZLUwsMsvT8MsjFg-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Fri, 4 Jun 2021 19:01:40 +0000 Received: by kubenode547.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID d332116f6ae227a93da4e681c613beb3; Fri, 04 Jun 2021 19:01:37 +0000 (UTC) From: Stephen Kent To: sidrops@ietf.org References: <4576a83c-4118-9e4e-aec1-e8e9b0a1a069.ref@verizon.net> <4576a83c-4118-9e4e-aec1-e8e9b0a1a069@verizon.net> Message-ID: Date: Fri, 4 Jun 2021 15:01:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.18368 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-6486bis-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jun 2021 19:02:11 -0000 Job, > welcome back and thank you for your efforts! > I re-read the document and was wondering whether it is useful to retain > the section 5 text about 'one-time-use' vs 'sequential-use' EE > certificates. Perhaps the text describing the procedure would be become > simpler if this (for RP undetectable?) difference is not highlighted. > > OLD: """ > In the case of a "one-time-use" EE certificate, the validity > times of the EE certificate MUST exactly match the thisUpdate and > nextUpdate times of the manifest. > > In the case of a "sequential-use" EE certificate, the validity > times of the EE certificate MUST encompass the time interval from > thisUpdate to nextUpdate. > """ > > NEW: """ > The validity times of the EE certificate MUST encompass the time > interval from thisUpdate to nextUpdate. > """ The term "one-time-use" EE certs is introduced in RFC 6487 (section 3) and that section includes a reference to 6486. Note that there are are several other references to one-time-use certs in manifests in Sections 3 & 4, and the 4.2.1 mention cites the same requirement on the validity period. Also note that the validity interval requirements for these certs constitute directions to CAs. The text in 4.2.1 provides rationale for this requirement, i.e., to avoid needless growth of CRLs. Since the text you cited in 5.1 is providing direction to CAs, I don't see a need to change it based on any RP considerations; the text does not impose a requirement on RPs to verify this. If you feel that's not clear, I could add text to note that. > ------------------------------------------------------------------- > > Section 5.2 - could perhaps benefit from some tighting up. > > OLD: """ > A new manifest MUST be issued and published on or before the nextUpdate time. > """ > > NEW: """ > A new manifest MUST be issued and published before the nextUpdate time. > """ > > I'm suggesting this edit because we should encourage operators to make > before break and not do things 'at the last moment'. I agree that make before break is the right strategy, and I am happy to make this change. But, since the nextUpdate field expresses times down to the second, I doubt if the change is meaningful :-). > ------------------------------------------------------------------- > > In section 5.2, """Repository operators SHOULD implement some form of""" > could be upgraded to a "MUST"? Repository Operators should be encouraged > to consciously avoid potential for race conditions or failed fetches. I'm happy to change the SHOULD to a MUST, if nobody objects. > ------------------------------------------------------------------- > > The paragraph describing "chicken and egg" (to me) seems confusing. I > don't see a 'circular dependency'. > > The Manifest's EE certificate MUST contain the 'X509v3 CRL Distribution > Points' extension which tells us where the CRL is, and ADDITIONALLY (in > a later stage) the RP confirms whether the digest calculated over the > obtained CRL matches the hash listed in the Manifest eContent. > > But whether the hashes match or not, or whether the eContent even lists > a FileAndHash entry for a .crl file at all... is a moot point if the EE > certificate has been revoked and its serial appears on a signed CRL... > right? When an RP fetches the contents of a pub point, it should find a manifest and a set of files, one of which is a CRL. The processing steps in section 6.1 describe the order of checks to be performed on the manifest, and on the files fetched from the pub point. It does not say when the CRL listed in the manifest is checked to verify that the EE cert for the manifest is not revoked. So, it seems possible that an RP might verify the signature on the manifest, using the embedded EE cert, fetch the listed files, check the hashes of the files, and then process the CRL that is listed in the manifest. If, at that point the CRL is found to be current and valid, but the manifest EE cert is listed as revoked, the CA has made a serious error. I just wanted to explicitly address this case. Steve From nobody Sun Jun 6 23:42:48 2021 Return-Path: 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 6E3313A393E for ; Sun, 6 Jun 2021 23:42:46 -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, RCVD_IN_DNSWL_BLOCKED=0.001, 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=ripe.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 TcEXzx8BYqcz for ; Sun, 6 Jun 2021 23:42:42 -0700 (PDT) Received: from molamola.ripe.net (molamola.ripe.net [IPv6:2001:67c:2e8:11::c100:1371]) (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 E55473A3941 for ; Sun, 6 Jun 2021 23:42:41 -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=BQPfzJy9b4v/3fTMBPVLRMo7RAz+P7cbH9Y51ivGXJQ=; b=MyhQ2eGzl8nKdNYirXfWkpBM z7tqdFIB0ejQvmX5zyQch09QzqlahZJTMlgS8/4kJAQtbn6sVhpHez77HY1ZnOuib7fMtc607NUfm VfvUW4GiG+Ts2vR40SwK4gMgsAl8tsk6CX2bM1eZ4OJc2cBQIcWUMpvk9BNQ4MIzbYfx7inT+6LbZ onYdNNLcu9Pgewo7bxDH+TER6QPAfuRSIqmKlBNVBKC2nXffnfKVeRjdRBhEhQdHlWlgoWg42Imue xbVgWqIUx4D/R6Kl9V6xmeNE6jIcRdv+rHZWBuj3DYGhay0iwsc4ZGtSIPsJgg9zT98UH5xzs0num tBGQ+SQRzw==; Received: from bufobufo.ripe.net ([2001:67c:2e8:23::c100:170d]:44664) by molamola.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lq8y5-000BtD-SH; Mon, 07 Jun 2021 08:42:37 +0200 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.94.2) (envelope-from ) id 1lq8y5-00022x-PE; Mon, 07 Jun 2021 08:42:37 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Ties de Kock In-Reply-To: Date: Mon, 7 Jun 2021 08:42:37 +0200 Cc: SIDR Operations WG Content-Transfer-Encoding: quoted-printable Message-Id: <4CF2027E-4E21-4347-B1B9-C6237354DBC5@ripe.net> References: <4576a83c-4118-9e4e-aec1-e8e9b0a1a069.ref@verizon.net> <4576a83c-4118-9e4e-aec1-e8e9b0a1a069@verizon.net> To: Stephen Kent X-Mailer: Apple Mail (2.3654.100.0.2.22) X-ACL-Warn: Delaying message X-RIPE-Signature: 059faafd1cc22ebb05e1592c815fe1e15cfd8a51acb0bd2177ba56c67f474734 Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-6486bis-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2021 06:42:47 -0000 Hi Stephen, > On 4 Jun 2021, at 21:01, Stephen Kent = wrote: >=20 > Job, >=20 >> welcome back and thank you for your efforts! >> I re-read the document and was wondering whether it is useful to = retain >> the section 5 text about 'one-time-use' vs 'sequential-use' EE >> certificates. Perhaps the text describing the procedure would be = become >> simpler if this (for RP undetectable?) difference is not highlighted. >>=20 >> OLD: """ >> In the case of a "one-time-use" EE certificate, the validity >> times of the EE certificate MUST exactly match the thisUpdate and >> nextUpdate times of the manifest. >>=20 >> In the case of a "sequential-use" EE certificate, the validity >> times of the EE certificate MUST encompass the time interval from >> thisUpdate to nextUpdate. >> """ >>=20 >> NEW: """ >> The validity times of the EE certificate MUST encompass the time >> interval from thisUpdate to nextUpdate. >> """ >=20 > The term "one-time-use" EE certs is introduced in RFC 6487 (section 3) = and that section includes a reference to 6486. Note that there are are = several other references to one-time-use certs in manifests in Sections = 3 & 4, and the 4.2.1 mention cites the same requirement on the validity = period. Also note that the validity interval requirements for these = certs constitute directions to CAs. The text in 4.2.1 provides rationale = for this requirement, i.e., to avoid needless growth of CRLs. Since the = text you cited in 5.1 is providing direction to CAs, I don't see a need = to change it based on any RP considerations; the text does not impose a = requirement on RPs to verify this. If you feel that's not clear, I could = add text to note that. First a nit: The reference to a substitution attack in 4.2.1 no longer = current. I think that it would be good to capture the rationale (substitution = attacks and prevent diverging behaviour between implementations) for rejecting stale manifests in the document - it would help a future reader who does not = have the context of the discussion around 6486bis. While the requirement Job mentioned is undetectable (?) for RPs, I think = some guidance on what directions to CAs should be checked by RPs would be = helpful, since checking these requirements may lead to a situation where we do = not reach the end goal of all RPs with the same cache and RPKI repository data = having the same set of validated repository files. Specifically (from 5.1.2): ... This EE certificate MUST have an SIA extension access description field with an accessMethod OID value of id-ad-signedobject, where the associated accessLocation references the publication point of the manifest as an object URL. This EE certificate MUST describe its Internet Number Resources (INRs) using the "inherit" attribute, rather than explicit description of a resource set (see [RFC3779]). ... The second requirement was part of the BBN conformance cases (792=20 MFTIPv4NotInherit, 793 MFTIPv6NotInherit, 794 MFTASNotInherit). I would expect all RPs to check the first requirement. I also know that = most RP implementations do not check the second one - leading to divergence if = these differences were present in real repositories. Indicating what to do with these directions to CAs would prevent = divergence. I do not have a strong preference, but if forced to pick a side because we = want converged behaviour, I would err on the side of checking it over being = tolerant of sloppy CAs. Kind regards, Ties >> ------------------------------------------------------------------- >>=20 >> Section 5.2 - could perhaps benefit from some tighting up. >>=20 >> OLD: """ >> A new manifest MUST be issued and published on or before the = nextUpdate time. >> """ >>=20 >> NEW: """ >> A new manifest MUST be issued and published before the nextUpdate = time. >> """ >>=20 >> I'm suggesting this edit because we should encourage operators to = make >> before break and not do things 'at the last moment'. >=20 >=20 > I agree that make before break is the right strategy, and I am happy = to make this change. But, since the nextUpdate field expresses times = down to the second, I doubt if the change is meaningful :-). >=20 >> ------------------------------------------------------------------- >>=20 >> In section 5.2, """Repository operators SHOULD implement some form = of""" >> could be upgraded to a "MUST"? Repository Operators should be = encouraged >> to consciously avoid potential for race conditions or failed fetches. > I'm happy to change the SHOULD to a MUST, if nobody objects. >> ------------------------------------------------------------------- >>=20 >> The paragraph describing "chicken and egg" (to me) seems confusing. I >> don't see a 'circular dependency'. >>=20 >> The Manifest's EE certificate MUST contain the 'X509v3 CRL = Distribution >> Points' extension which tells us where the CRL is, and ADDITIONALLY = (in >> a later stage) the RP confirms whether the digest calculated over the >> obtained CRL matches the hash listed in the Manifest eContent. >>=20 >> But whether the hashes match or not, or whether the eContent even = lists >> a FileAndHash entry for a .crl file at all... is a moot point if the = EE >> certificate has been revoked and its serial appears on a signed = CRL... >> right? >=20 > When an RP fetches the contents of a pub point, it should find a = manifest and a set of files, one of which is a CRL. The processing steps = in section 6.1 describe the order of checks to be performed on the = manifest, and on the files fetched from the pub point. It does not say = when the CRL listed in the manifest is checked to verify that the EE = cert for the manifest is not revoked. So, it seems possible that an RP = might verify the signature on the manifest, using the embedded EE cert, = fetch the listed files, check the hashes of the files, and then process = the CRL that is listed in the manifest. If, at that point the CRL is = found to be current and valid, but the manifest EE cert is listed as = revoked, the CA has made a serious error. I just wanted to explicitly = address this case. >=20 > Steve >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Jun 10 01:36:33 2021 Return-Path: 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 B070A3A3A2A for ; Thu, 10 Jun 2021 01:36:32 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ripe.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 39wLlRDicGBC for ; Thu, 10 Jun 2021 01:36:28 -0700 (PDT) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 0110A3A3A28 for ; Thu, 10 Jun 2021 01:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ripe.net; s=s1-ripe-net; h=To:Date:Message-Id:Subject:Mime-Version:Content-Type:From:CC ; bh=Ywph9is+DlwDcalGSDaxUyUHmN+HHqPdwDQyzDIxcV8=; b=LRT13eepGe3AsXQI49XXa7+Y O+7t39tppGzdce+VbCt/rGGeE0LgetDI/Zk/s+1tNA/fGfTkoXuQ2qUuKfWNOJ9/HFkS40YoYkGpO Sgd+4c81xwAXhCzMYduLv7CVQXwqCgGI7B/TAe7GRGP1ha4ovsH+nYomkmZyD+Dbe+Vp6d9FOTwvq dflpO9PdaP5JC9vejAjkQ2lI96GgvgAyHTmikgGBrDCS3nHUZ0ShaG5hiH4ZKioUnPbdGB3WkGgKu udxkgoaYeYZpkxj5JfYNy9djHXz//jekeZ5spBr1P1999gJ+tX5E9q0E+8n+HYt/ScZVw4ZJk1Nwt MiscENANNg==; Received: from allealle.ripe.net ([2001:67c:2e8:23::c100:170c]:43104) by mahimahi.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lrGAr-000CC1-5r for sidrops@ietf.org; Thu, 10 Jun 2021 10:36:25 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:1200::ce1]) by allealle.ripe.net with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lrGAr-0000iG-3I for sidrops@ietf.org; Thu, 10 Jun 2021 10:36:25 +0200 From: Nathalie Trenaman Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Reply-To: sidrops-chairs Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: Date: Thu, 10 Jun 2021 10:36:24 +0200 To: SIDR Operations WG X-Mailer: Apple Mail (2.3654.60.0.2.21) X-ACL-Warn: Delaying message X-RIPE-Signature: b23882c8c47abee4cf35af21618ca92a6c0e661dfbd2152f380da2ceb0830030 Archived-At: Subject: [Sidrops] IETF111 -- Online -- Call for Agenda Items X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2021 08:36:33 -0000 Hi folks, =20 SIDROPS will meet online at IETF-111 (26-30 July 2021) . Please forward = any SIDROPS agenda items you may have to Keyur, Chris and me.=20 We'll have a 90 minute slot, so don=E2=80=99t be shy :) =20 Regards, Chris, Keyur and Nathalie= From nobody Thu Jun 10 13:11:29 2021 Return-Path: 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 447353A17DD for ; Thu, 10 Jun 2021 13:11:27 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=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 mafqbNgVU2fz for ; Thu, 10 Jun 2021 13:11:22 -0700 (PDT) Received: from sonic313-14.consmr.mail.bf2.yahoo.com (sonic313-14.consmr.mail.bf2.yahoo.com [74.6.133.124]) (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 346313A17DC for ; Thu, 10 Jun 2021 13:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1623355880; bh=g0kAs8aZ5X6QYEqVwg5aUWk8qK/rWDiSvAL8JCTf02I=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject:Reply-To; b=hKeU3lIiq+xSRYkX7rbq50P9H1NssgR0LarI1YubaQdQLvaSrEuZGfKqDLtKHlsaG5ogpWbWWPUW+z5eS/UJPXdBhMCvkFhkKLEr91OTUmaDnuYmuTJBSccAbEKiB5LGab40YdxsDG7dYtFZvh/6yu6V98s/yKozRAaoyNWKpLEIUKHXzCgz4hme+2/LEYlCsDSAEN/jFZovGwoRzq0md/ezHh4h+fJhgrngHTn7NdGFNQL0Uf5HaLSdPD/xHAMtaV0mLIbfESDw/9uQOgEGjGbPLsCEDydzKMDGJOTCxEUFTjeZQt0tN7Va451/DNniOIwlGefxU0Oa1xw4TtlU/g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623355880; bh=whiI8GiKLjO4r6uY72xcy08zb42j5+EMHu338HSpP7X=; h=X-Sonic-MF:Subject:To:From:Date:From:Subject; b=JDZnte1njBdUFS+oWy70J6fD8+6OxpnFHSsu1OCl7ruZHHyLfaK4/RjrB3fIrSA+gZVeNoxRIeGT2r2vYaHi2DGX1vnD5ntzRFcpc3Eu0Y/B5YNvk3/r+eDCPl+9GQac5m3232SkVypRwlJZqWU2wEq5IVnfiok3iZpY3+dhE1TiIAtgHF2p/RNor8U2HT5bgub7VPx/hJUXYbUSjBkFp2iacggLYz/Cxj1A86l0UiYKJFFmp7lZA1LIa0ElJ/fzKKnaKqKPt1dJWRP3I5I7iLUEotlHrUACTmSIuOF8oUEy0nOc55yRSMI/dmlZyf8yLLdAAeiI8Wezotk+lTPXaQ== X-YMail-OSG: 8uRJFmgVM1nIdXALjoXSbNSvvTkuHPUxkQWOYqVKmju2rTuCRCE1PYV5Qe248o7 cIBI_D2jonIIvVMlPCsHRstlOMjxAfUaJalAl0VDAuAkeSHx2gzhOheBbFqXVH.PQKRa0pzqsRlg ypbR9rSBuzox_TKYF.BRSjoHxaTQsN6P45ur1xcZ3.8zA.rFl30Ywdz1W6lSLbEB_j0K1XPbuIJL YmMxRkZccbVfhjAytnXvIBt0mlv0GLkpiKVF4wm82_8AFZo7fj1JgDEncvuTAT1_G6huYXGpXTwJ .q1hQ3v.07mlQynjCbqm8kiMwasBcNJ_t_7CXVHfUtHmCQAprbwPPj6waMo1xJKfuz9sTwxsSVDk 51db2kytZ8ag0hsom5RKW_w80UfihEfq46ivwVkYAhan8Wzb7nylbB.eURqHrWmAF5mADvma8fP1 vhRTHv9M1IQxzWA38mrV2ZyxBzYqlvjDWJwahmu2iK_3p7tGoJ6hHPTY41gn3Yi.yc0KoIearNxx io1Te3f1jul_BGL5HnddiyQ156b4tEEfjTvRMhuTlp1eu7RfF1knU86b2FMw1UkVPqighz2ANQGC 3ipanVrxwetsDW9AxNUEjFbNk2n_etpAqJyDpaoAP55TCsNy42hmDgP2jltnlIMY0KAwcT8HLP1I Z315yxKzsD5y3HJsd3VUqBw9Xs.L3NMHPfYNPnmQLvYlPSVbwPXaXwzmW4qCOg_jlpan7s.EN2xU SAD6EAG3ENsn8LJqYdPpKP2HZQ.jarLCxNiKT6_qj8thC197C5Zy3QVaY8YFZ_0xwZz8s.3lLKuC LFzAGlHzNxcnjLafRV2QWwAJd6jnV4CXJPDCiE7_HVM6hxlS99BSHyB6Iq0rjFWmXNT1M9I4yujB .qDw2kRr7N0f4M2ihDjgfzge7gc.JFn0Dm_zlWZgkYLz_t6SMUJTKZ2L3TNshUeGP3iJswPg2zDM ETqFp0ZP4z0m2Qfu40RYsFxVPBe5ZQsYlt1Y_LqOlSCmmmtlCwKovDpQzUR9Uo4c2GiR_zIWrq9W Ry_.3kWl.WjGlLG98.83t4Bsz.k5B3DVlQ3okKmz93W_JRAvNIj34SXj9gPupM4fLNQaXpGXO4Wv OS9RZaUzB8zI2c72p18b182dGxaSA6AK2xSJ.odOCy4Emc_dO8K6Q1MeHZOwHMfqORkfj22tYFEd iKitEYumbM90emdBSiAyMoK2MNzWsCCvfr1S5.4PbPQyY.srY8mCfO4dIbEwH6LWM2_lOeUdeYnl HeqMJNZREu9dCn2l29IaCpL07BWrXErsAX273frVB54XhDrK29S0H6V4vCZt44SHFp30kX9cMqe_ qwmPTv6QuL7TWwfcN0DXpDws6To.xaWHdcxbk3b37XKuifBHawuVNCt7DVitrY9kRdT3xaBo0r.W tBN8Fq3L1z_FnfL81A30KkRZxtpNoZunr0ROm34i.IgTkRnQRgQVX9edkzGQ8VWgOnI5.K6k9lY4 oMYoD_hS8WxZezrTKUwcUZYu8gBQ2_ZhVZLF2vFF7AspZqJ5clhZ.qU9ff7qqibvyvsuVP4i39yP 7GaykXqMMI_i5rgBNeW1nKLLgsmI9ykkd.WJCvzFkeg_6M_8n6RDFoUr0hh0tgpWmFTwD0C4Pv5S QMumr6j29_mxPvL2icGRIynMgYScZVi7ZOz_C2AW5XDXPIPstPrvN9pTP3xoU.On8SWg8g4Wuzlr ii0glo7JWTm8zJ1sZkmDhcYN_M0aJpdcuqfKyd2qNceQV5Sb0kJkXwdJYvfIFNQ6LJ4iSr.zFA.q hMQotRLLmv9DSAObDYb7Q__yT3HSG6U38RPc21FY88LU_h3WL7lhOK2mp7KQu_s2dIWV02aKKSgt g64my3lcBx8FiRxQIxsw50pHqsizjlZC7K2dABxIiG1wfRueJgGYajjnQK1RXTxaucokitWuezuj 3468puqhUy_v.gajAWlM2bzkE7X41.DQJjhMxFVSCKSJiVtHeJPomZIgFnbhSUIRbuWGyHVqHvMp 3GRZ3XecEpmKbTa3JDQbfrLMbimpCYNwewfousCTH03lpqRL_.Ueqb36xqKC6HDgIBqQvkw8vu7W 5vkDtR3aBG.7_u_8IkvSom3BAFKJZ14L.y_fzMo11uMGn_k15NDiT0WqQTLEtUlfWfa5AMLsYs80 0zl95MrVygs5dotKquxVC_RSBB1JEyc0_sKiHflt62ykO5B8X_EyEvmw6fsaAE1FVbvag44ektXp 2RXiKctgrHxogHg8Zd5rgRZXcvHozivcdUfSeP9k3ceCC5Y_qZlng0imXWCKeN6DPzW29SPf6.pS 1XOg3b2JF41lFGHN_HJc0Xq54EMGgn.Zlx6B4hOCby1BX3j_AZlkb90WlVbgJqVJvdDul7kgm8gu fJHDOPiZOu4Oa_.1PGZ4OHT5LMc2pnQzg0LT8sr3BGC1n5ifTr6bkN.SwVJoxnDraSFwy8J1Rfhx y2i4HLfw8kpWmgSOwAqKQ X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Thu, 10 Jun 2021 20:11:20 +0000 Received: by kubenode522.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c056c3f7ae640838e021874a3416469d; Thu, 10 Jun 2021 20:11:19 +0000 (UTC) To: Ties de Kock Cc: SIDR Operations WG References: <4576a83c-4118-9e4e-aec1-e8e9b0a1a069.ref@verizon.net> <4576a83c-4118-9e4e-aec1-e8e9b0a1a069@verizon.net> <4CF2027E-4E21-4347-B1B9-C6237354DBC5@ripe.net> From: Stephen Kent Message-ID: Date: Thu, 10 Jun 2021 16:11:18 -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: <4CF2027E-4E21-4347-B1B9-C6237354DBC5@ripe.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Mailer: WebService/1.1.18368 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-6486bis-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jun 2021 20:11:27 -0000 Ties, > Hi Stephen, > >> On 4 Jun 2021, at 21:01, Stephen Kent wrote: >> >> Job, >> >>> welcome back and thank you for your efforts! >>> I re-read the document and was wondering whether it is useful to retain >>> the section 5 text about 'one-time-use' vs 'sequential-use' EE >>> certificates. Perhaps the text describing the procedure would be become >>> simpler if this (for RP undetectable?) difference is not highlighted. >>> >>> OLD: """ >>> In the case of a "one-time-use" EE certificate, the validity >>> times of the EE certificate MUST exactly match the thisUpdate and >>> nextUpdate times of the manifest. >>> >>> In the case of a "sequential-use" EE certificate, the validity >>> times of the EE certificate MUST encompass the time interval from >>> thisUpdate to nextUpdate. >>> """ >>> >>> NEW: """ >>> The validity times of the EE certificate MUST encompass the time >>> interval from thisUpdate to nextUpdate. >>> """ >> The term "one-time-use" EE certs is introduced in RFC 6487 (section 3) and that section includes a reference to 6486. Note that there are are several other references to one-time-use certs in manifests in Sections 3 & 4, and the 4.2.1 mention cites the same requirement on the validity period. Also note that the validity interval requirements for these certs constitute directions to CAs. The text in 4.2.1 provides rationale for this requirement, i.e., to avoid needless growth of CRLs. Since the text you cited in 5.1 is providing direction to CAs, I don't see a need to change it based on any RP considerations; the text does not impose a requirement on RPs to verify this. If you feel that's not clear, I could add text to note that. > First a nit: The reference to a substitution attack in 4.2.1 no longer current. > I think that it would be good to capture the rationale (substitution attacks and > prevent diverging behaviour between implementations) for rejecting stale > manifests in the document - it would help a future reader who does not have the > context of the discussion around 6486bis. I have removed the forward pointer to 6.4 from the text in 4.2.1 The document already notes that manifests are intended to allow an RP to detect removal or substitution of stale version of objects (see the intro), so I don;t this needs to be repeated in 4.2.1. > While the requirement Job mentioned is undetectable (?) for RPs, I think some > guidance on what directions to CAs should be checked by RPs would be helpful, > since checking these requirements may lead to a situation where we do not reach > the end goal of all RPs with the same cache and RPKI repository data having the > same set of validated repository files. Good point. I have annotated the steps in 5.1 to note ones where an RP is required to check that the CA has produced the manifest as directed, and to note where this is not the case. A new version will be posted soon. Steve From nobody Fri Jun 11 06:36:58 2021 Return-Path: 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 3B5483A37C9 for ; Fri, 11 Jun 2021 06:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 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_LOW=-0.7, 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=nlnetlabs.nl 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 o5OA20b76ZgZ for ; Fri, 11 Jun 2021 06:36:50 -0700 (PDT) Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.218]) (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 2B6DC3A37DB for ; Fri, 11 Jun 2021 06:36:44 -0700 (PDT) Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 8C0D96062D; Fri, 11 Jun 2021 13:36:41 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1623418600; bh=Zcub47pLdJATWslGAoONnaisPdu2smBSZGv6gzZd/Eo=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=C+qjfrz6MihZHeqiM+zg7WsLgym/4HiT2KSV9NKN84GBseCvb6ytmntY+EtVZndBA OEl67ZYnfx2cEs1aGfMPR3rwQJF3aZXToz8xKlrfMhZxnw8FSIXqLqYZGS/NysLtBd EHeOj4Ek068yvCKngDBH+c/H+9yLQMk2nMu2YwRGJrOG9xEAUfM9nj+3gHXl/xwDE7 4Blsdshc6urFnqCaKhPPNE4QY0I17Te1Gp7cg3uoxy/Wk/7Xc+up+HtmNBnsyq7Vsk fEMac7ETTyblRiFlQY5a+XUhPadyKkmozJwTCBCzK0ABi9eZimoFikO15K4o/EJi6t N7c8uJmLjKx/A== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Tim Bruijnzeels In-Reply-To: <4576a83c-4118-9e4e-aec1-e8e9b0a1a069@verizon.net> Date: Fri, 11 Jun 2021 15:36:38 +0200 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1EF06618-5BF8-46CE-A25C-37D98867EADF@nlnetlabs.nl> References: <4576a83c-4118-9e4e-aec1-e8e9b0a1a069.ref@verizon.net> <4576a83c-4118-9e4e-aec1-e8e9b0a1a069@verizon.net> To: Stephen Kent Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-6486bis-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jun 2021 13:36:57 -0000 Dear Steve, Thank you for taking this effort! I have some comments / questions I would like to bring up. - Section 2 Manifest Scope This section may benefit from a reference to RFC 6481. In particular, it = may not be clear to the reader now that there MUST be only one CRL = issued under a CA (certificate). Perhaps replace: =20 o the most recent CRL issued by this CA, and With: o the single, most recent, CRL issued by this CA [RFC 6481], and - Section 3 Manifest Signing Job talked a bit about this as well. =46rom my point of view, I believe = that all CA implementations use single-use EE certificates for = manifests. I don't see a use-case for multi-use in this context. This is not a showstopper to me, but I think that we have an opportunity = to say the single use EE certificates MUST be used, and if we have just = one option then this will make the document easier to parse and reason = about. E.g. section 4.2.1 can be simplified. - Section 5 Manifest Generation There is no text here that says that the single use EE certificate for = the previous manifest (if single-use applies) should be revoked. = Although later it is implied that a manifest can be revoked. Is this = intentional? Currently my CA implementation revokes old manifests. It is trying to be = thorough. That said, I think there is little point in doing this. The reason is = that if an RP would find the new CRL, but still have the old manifest = because of some timing issue - then it would find that the CRL hash does = not match what is said on the manifest. It would be a failed fetch as = described in section 6. Revoking the current manifest on its current CRL = is possible, but somewhat hard to achieve with single-use EEs (assuming = random serials are used) as well as obviously ill-advised. One could therefore argue that rather than revoking previous manifest, = the 'thisUpdate' or possibly 'manifestNumber' should be leading in = selecting an eligible manifest - should an RP have multiple validly = signed and current manifests for the same CA somehow. Not revoking = previous manifests would help to avoid the "chicken and egg" issue = raised in section 6. It is not clear to me that this would really be = less safe. But look, really, rather than trying to pick an argument over this, I = raise this because I would like to see explicit text in the document = that says what's expected here :) - Section 6 I believe we have had discussions as a WG and concluded that any current = RPKI object (such as ROAs) which are NOT on a manifest can be considered = out-of-scope and de-facto invalid by RP software. Notable exception to = this would be objects which are never intended to be published inside = the regular RPKI such as RSC and RTA objects in future.=20 If I misunderstood please let me know. But otherwise might I suggest = updating the first sentence: Current: =20 Each RP must determine which signed objects it will use for validating assertions about INRs and their use (e.g., which ROAs to use in the construction of route filters). ... Suggest: Each RP MUST use the current manifest of a CA and add each listed file to the set of signed objects it will use for validating = assertions about INRs and their use (e.g., which ROAs to use in the construction of route filters). Any files not listed on the manifest MUST NOT be used for validation, unless the profile of its RPKI object type explicitly states otherwise. ... Tim > On 1 Jun 2021, at 15:36, Stephen Kent = wrote: >=20 > I revised the text in Section 6 to reflect the suggestion Ties de Kock = made in an off-list exchange in late December of last year. Although our = esteemed chairs said that someone else would assume responsibility for = this I-D early this year, that has not happened. Moreover, there has = been no more on-list discussion of this topic, so I elected to complete = the agreed-upon changes and publish an update before the old version = expired. >=20 > Steve >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Jun 14 06:54:05 2021 Return-Path: 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 C09093A253C for ; Mon, 14 Jun 2021 06:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, NICE_REPLY_A=-0.001, 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 SIl7LkSGqDMM for ; Mon, 14 Jun 2021 06:54:00 -0700 (PDT) Received: from sonic316-11.consmr.mail.bf2.yahoo.com (sonic316-11.consmr.mail.bf2.yahoo.com [74.6.130.121]) (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 BDFE83A253E for ; Mon, 14 Jun 2021 06:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1623678838; bh=Quy8n74eztJSNSm+CMW54RflZkVGa7B5Wg6GoTGTnqw=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject:Reply-To; b=WteQWhhJw1F2Cb1hHCixHG2hUj+GlWRXWGvKhv7nsAOulLRBJRoc6T1+qhZ5RX+Do3lHSYjTYbHiTfNe7k5FjwBY3VjNKuW4heHWU6ayEX7fo/Nwg4KQ5uSrwcBkgc3ardUTZF41+tWxKOOKycqFGonXt5hgADzjY4EtfJrqvR8bSkQdhGSWOqg3ZMEooyetNtwAyHgHr1/q9CDXOdaWCxwPvmk+e9apKIpgaVWSafXAOo6QFkndHcnRLjLfGdJ3A7W4xyBOJk8zj9wSH29UyDFX9RZ3cyom/JizBedp1TQ+VrR8yVP2+qx/j0jBAyol/jTlQM81FejB49TubF+j2A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623678838; bh=7k84+/fTC+o0/235I59ftTj7UWAckpHYJGRlJuPs6Z5=; h=X-Sonic-MF:From:Subject:To:Date:From:Subject; b=Ua53t7RD+zWzG1aKUJ8ypJYJ1h7ZdYuNOm3/ub/+gMGSWatRO0/aq6sdJUkcFFby6JOJKbd88+r24uQ5wC9di9GbNKUSiEC+LpBwtC1DqGS00NHCALUwZwassRY/OV+L91a7fuCyrkHaOW0kYR2qeTRy5B0zr8wzrcU4lZ8tlc+BnMdL7lPQYYt6JtGZAUHVB6dMjTc3f/c0ceINcp/EfwUZwdlnMBxIq2HMi41iQYxnJoyZnMlsI2JzBgN6I5EWqU/b89IvA+of27bENgVCWS0W7prJqn0Gx+K54rnokkpzQNpaTTvbh7fNRuHrgUZzH9bqO4zWDXZIbKcX2/J5VQ== X-YMail-OSG: M.lZrksVM1lqHSGRnXUw32lUDZan5Lg_bOV1B2pe_hWXYj0VLO6aCcJGvh3AG46 GBt99y1iV28OxXjX0O.JMxig7_HIFbI9jyxIe06j13hZY4_PlU2EwUYNVOmZMOKSXw7mgC61DRYJ XRP5F0spz6RucIz7RqUjNAUi3skdnn0QrENdM6kxIEqk_FDXc8tSSyQiPoZRHJa8OCj4ktfqG9DY LlcLHi9q364jXQpB1s8JfQ8_7FHZOrPFqxL0U6aSoHrkmmV3e71gqc6I47JAfYhmPlIE5cAm6mMq MWyCfBV56VLufWTPRtWoIHvYuGpNq3bsEw_SkTRttY6CA1hEE3mw_dF0YtwoxYvUWYx8rg0jWDN8 MrfrAnW36dp6nwQJbK3Zgrpz8aQTd_dKduvMWFugp9_GNBFZ_avGGs1DfCJ_7ex4iyICX1DsWQRZ Evj3jjgChekJP29EAmnyyNfX7.EKTFoY7OFQnndTJPzrUrHnCKzYKIhnPFAOApDh7oD08QhvlZS6 2H6re_ayFrJdK.6FZW2.aNjl_SXcqHBLxRVzF7OnLXOtMUSWWROTaABFyY_rIlVlZPPa7y4ChDBR GqNxWLvoJ3_f32ymYI47avhoq5z9Qq6v_9BDa9E2q7nXG5sUO6lgpiL8vHb6UcYP0GictdlmYTeP eqFKljowkTysOuHQjmIOLva6P6jqW44OhmBcGbL7dh2gcdHDBFdcKr3UhIWbVt5nmoCg7uOeGTB7 VgBKwJc5cHP0BUCjs47hIjSxSZVb1_QpiBzAgDVEvL2rmvYa8VhbWHT.OsPzXYg1AsSbja5jmSeR jFK2lk5V31x8QbmrJ7qTyB5rINoclp0nI3cDWAAgRtglaqbSXwoXaZLnjRR1fRkQUiJI_8PwB3L9 zUQz3FP9aFPBVhZaPubhYqUbxN8NhEOfRMHF9MSbpfB6CWck1Y2TxsjuqInGXZDkz1QbMHOE2ks. 8kaAWiaWW5g0D0EbnfoDMs.U.inx_HwdnfTMKrbR0LqsSetWK217xfpXdoS7yC8WINe3XOXaPn4l PTfAjNiNzLCjmDN6EOo0i1f7Z_4kum7qcePE9m0jsZ.8sqLkqKrQJv2oSOKSjNK6m9hC6k13C224 Hc5aJhnd9TG94PwF86SjDBb9wXUgnYHnx.4RpXTObFw80Mn4mBe4bf5.fLz8uRG99ddNUhHtKFAm 4PErkItLaZNRZYbTqh56K1gZy2FeX7BEuGsEtK5xQY.Q1OxpAZZJ7RmQ_NFUQ2D2dL.0Cdxm4Zma sl8q4em9rbTXNXm9p_qGQDjh_q5R_oPT7Y03KX349SN1aXloDBPKXqQCYf2KMZowCMyOrJPNC8mF QY7GP1huJox4siGoVNZqdeSRt_8aFIapIs87xOz.Lc2SwIbMiuIUxRymc2m2bcuv4CPdCStuf0Ez ikS5wunRW4aqBDVRTdScNezqzFTBGPJEzazGTFiuNrE26gPPjaRe9OBBCmP7oqHrk7DvTj69gazo tgW5qoPMiJGu9IPXiVsZb.FlzhOlUVNFeoyyvqUaVQsrurNoCxqJXxeVqnu7QDYt3ijoGSX4B6ef x.L0kBWZ0GHgHXidYplK3lPE8wLsWo_gkmjIVKK_AhfRzEc6yqxc.KaJk6BIowgvH1NppBZU9V8L 99tSAo35IasEMPwPj_dxvXDQQnen.nhs_L1m7k9qP94Vk1bYCgLFp5MmleP1d7mWnZcAFR1gfh4. d6NJhxZ_UQMF0fRcd9jq6r4XZbKPBimzsg2D8SvOrKp4r28upJvreanmFZDTchf3y39OCWJwXALI QxY_o5PXAZpwXkexq1u5M5rAc3IG_C_JLmlDsfibcyUgxOu511WUtVyea..vNkE1tc3kptaQY74A XskdxgMzht3FlZCrK4cI21MpAfF_s3XoXFGLthNQetTKxAZJVwmQng27AsicVKxPXPRs0sEu5udS AzZrqSoOZ693fe4uUj1JE9Ro1K1msCfzL6.u6Qn.ueu96DwhsYi6au_icnGFGnV1DtXrY_w_AdfE c.Z4LMXvva_0o6EjYuR7tXXxUlGHAb5N4tT2GdP4P7Z8EKCxqXPP.Nnvq0E1Xpgz3tJWqb4c.NzY 82CG2zH9Da4tkdaK9eIBPx4ayI8mVeYED2OFynwNH4C7c3zvOg81k0lENv53dNRB7VGtz_1sfxWV 5bN54yNfeK1MpDKfFDNwPhKDh2l5.4GuWDjOGYVS1XbsanaZIA8hVOe_ki_mmwCdve.dI9XOpfYf 3npnLntb2hrkLsE54Gy.nzX5th8n2HD6Cxw73Tzbm460ADq45mYNV5OIy9B_krsBgZSL3Q5OUneP qdMQYi_xpJgSeYLPtVaMigvk8eGohIId.BZX0.sMCWisXkAvidoYE27H.uPgg.L_7BQLgTxpyXOp KIAN3Fu.pW2ii0SBxqR0UE85IIwwjfrayIMJs0uvQubVZ03N2qSfSQeQmM8yGvczxbzqGjLvK X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.bf2.yahoo.com with HTTP; Mon, 14 Jun 2021 13:53:58 +0000 Received: by kubenode512.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e347f3359a9fc0c9391e94ccf5df3c98; Mon, 14 Jun 2021 13:53:54 +0000 (UTC) From: Stephen Kent To: Tim Bruijnzeels Cc: sidrops@ietf.org References: <4576a83c-4118-9e4e-aec1-e8e9b0a1a069.ref@verizon.net> <4576a83c-4118-9e4e-aec1-e8e9b0a1a069@verizon.net> <1EF06618-5BF8-46CE-A25C-37D98867EADF@nlnetlabs.nl> Message-ID: <9dcd34e6-3b07-c8fc-99b3-df9365cb19f1@verizon.net> Date: Mon, 14 Jun 2021 09:53:54 -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: <1EF06618-5BF8-46CE-A25C-37D98867EADF@nlnetlabs.nl> Content-Type: multipart/alternative; boundary="------------AF1F42DAD678B61E5EFC2AA0" Content-Language: en-US X-Mailer: WebService/1.1.18368 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-6486bis-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 13:54:04 -0000 This is a multi-part message in MIME format. --------------AF1F42DAD678B61E5EFC2AA0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Tim, > Thank you for taking this effort! > > I have some comments / questions I would like to bring up. > > > - Section 2 Manifest Scope > > This section may benefit from a reference to RFC 6481. In particular, it may not be clear to the reader now that there MUST be only one CRL issued under a CA (certificate). Perhaps replace: > > o the most recent CRL issued by this CA, and > > With: > > o the single, most recent, CRL issued by this CA [RFC 6481], and done. > - Section 3 Manifest Signing > > Job talked a bit about this as well. From my point of view, I believe that all CA implementations use single-use EE certificates for manifests. I don't see a use-case for multi-use in this context. > > This is not a showstopper to me, but I think that we have an opportunity to say the single use EE certificates MUST be used, and if we have just one option then this will make the document easier to parse and reason about. E.g. section 4.2.1 can be simplified. I agree this change would make the doc simpler, but I need to hear from other CAs to confirm that NOBODY issues multi-use EE certs in manifest before making this change. > - Section 5 Manifest Generation > > There is no text here that says that the single use EE certificate for the previous manifest (if single-use applies) should be revoked. Although later it is implied that a manifest can be revoked. Is this intentional? Recall that 4.2.1 calls for the manifest EE cert (if single use) to have a validity period that matches that of the manifest, to avoid the need to revoke that cert when a new manifest is issued. So, unless a new manifest is issued before the old one expires, it is intentional that the cert for the old manifest not be revoked. > Currently my CA implementation revokes old manifests. It is trying to be thorough. does it do this in all cases? since you indicate that you are employing single-use EE certs here, that behavior runs counter to 4.2.1, unless the new manifest is issued before the old one expires. Also, do you remove the revoked EE cert from the CRL as soon as it expires, which should usually be before the next manifest is issued. > ... > > One could therefore argue that rather than revoking previous manifest, the 'thisUpdate' or possibly 'manifestNumber' should be leading in selecting an eligible manifest - should an RP have multiple validly signed and current manifests for the same CA somehow. Not revoking previous manifests would help to avoid the "chicken and egg" issue raised in section 6. It is not clear to me that this would really be less safe. > > But look, really, rather than trying to pick an argument over this, I raise this because I would like to see explicit text in the document that says what's expected here :) as I said, unless a CA issues a new manifest before the next scheduled issue time, this ought not be an issue. > - Section 6 > > I believe we have had discussions as a WG and concluded that any current RPKI object (such as ROAs) which are NOT on a manifest can be considered out-of-scope and de-facto invalid by RP software. Notable exception to this would be objects which are never intended to be published inside the regular RPKI such as RSC and RTA objects in future. The notion of manifest scope is defined in Section 2. It says that "... all published signed objects that are verifiable using EEcertificates [RFC6487] issued by this CA." are in scope. So, based on that text, it would seem that the RSC and RTA objects are in scope. Also, the RTA ID indicates that these objects may appear on a manifest, so I find the proposed, revised text confusing. > > If I misunderstood please let me know. But otherwise might I suggest updating the first sentence: > > Current: > > Each RP must determine which signed objects it will use for > validating assertions about INRs and their use (e.g., which ROAs to > use in the construction of route filters). ... > > Suggest: > > Each RP MUST use the current manifest of a CA and add each listed > file to the set of signed objects it will use for validating assertions > about INRs and their use (e.g., which ROAs to use in the construction > of route filters). Any files not listed on the manifest MUST NOT be > used for validation, unless the profile of its RPKI object type > explicitly states otherwise. ... Steve --------------AF1F42DAD678B61E5EFC2AA0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Tim,

Thank you for taking this effort!

I have some comments / questions I would like to bring up.


- Section 2 Manifest Scope

This section may benefit from a reference to RFC 6481. In particular, it may not be clear to the reader now that there MUST be only one CRL issued under a CA (certificate). Perhaps replace:
 
   o  the most recent CRL issued by this CA, and

With:

   o  the single, most recent, CRL issued by this CA [RFC 6481], and


done.

- Section 3 Manifest Signing

Job talked a bit about this as well. From my point of view, I believe that all CA implementations use single-use EE certificates for manifests. I don't see a use-case for multi-use in this context.

This is not a showstopper to me, but I think that we have an opportunity to say the single use EE certificates MUST be used, and if we have just one option then this will make the document easier to parse and reason about. E.g. section 4.2.1 can be simplified.


I agree this change would make the doc simpler, but I need to hear from other CAs to confirm that NOBODY issues multi-use EE certs in manifest before making this change.

- Section 5 Manifest Generation

There is no text here that says that the single use EE certificate for the previous manifest (if single-use applies) should be revoked. Although later it is implied that a manifest can be revoked. Is this intentional?

Recall that 4.2.1 calls for the manifest EE cert (if single use) to have a validity period that matches that of the manifest, to avoid the need to revoke that cert when a new manifest is issued. So, unless a new manifest is issued before the old one expires, it is intentional that the cert for the old manifest not be revoked.

Currently my CA implementation revokes old manifests. It is trying to be thorough.

does it do this in all cases? since you indicate that you are employing single-use EE certs here, that behavior runs counter to 4.2.1, unless the new manifest is issued before the old one expires. Also, do you remove the revoked EE cert from the CRL as soon as it expires, which should usually be before the next manifest is issued.

...

One could therefore argue that rather than revoking previous manifest, the 'thisUpdate' or possibly 'manifestNumber' should be leading in selecting an eligible manifest - should an RP have multiple validly signed and current manifests for the same CA somehow. Not revoking previous manifests would help to avoid the "chicken and egg" issue raised in section 6. It is not clear to me that this would really be less safe.

But look, really, rather than trying to pick an argument over this, I raise this because I would like to see explicit text in the document that says what's expected here :)

as I said, unless a CA issues a new manifest before the next scheduled issue time, this ought not be an issue.


- Section 6

I believe we have had discussions as a WG and concluded that any current RPKI object (such as ROAs) which are NOT on a manifest can be considered out-of-scope and de-facto invalid by RP software. Notable exception to this would be objects which are never intended to be published inside the regular RPKI such as RSC and RTA objects in future.

The notion of manifest scope is defined in Section 2. It says that " ... all published signed objects that are verifiable using EE certificates [RFC6487] issued by this CA." are in scope. So, based on that text, it would seem that the RSC and RTA objects are in scope. Also, the RTA ID indicates that these objects may appear on a manifest, so I find the proposed, revised text confusing. 


If I misunderstood please let me know. But otherwise might I suggest updating the first sentence:

Current:
 
   Each RP must determine which signed objects it will use for
   validating assertions about INRs and their use (e.g., which ROAs to
   use in the construction of route filters). ...

Suggest:

   Each RP MUST use the current manifest of a CA and add each listed
   file to the set of signed objects it will use for validating assertions
   about INRs and their use (e.g., which ROAs to use in the construction
   of route filters). Any files not listed on the manifest MUST NOT be
   used for validation, unless the profile of its RPKI object type
   explicitly states otherwise. ...
Steve
--------------AF1F42DAD678B61E5EFC2AA0-- From nobody Mon Jun 14 08:06:24 2021 Return-Path: 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 91FE73A276B for ; Mon, 14 Jun 2021 08:06:22 -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 (2048-bit key) header.d=nlnetlabs.nl 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 oZB5TXIBJFs7 for ; Mon, 14 Jun 2021 08:06:16 -0700 (PDT) Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.218]) (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 A0E843A2765 for ; Mon, 14 Jun 2021 08:06:16 -0700 (PDT) Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 6D1086004F; Mon, 14 Jun 2021 15:06:13 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1623683172; bh=gtqnKB1gr4gFfmPBkZg10jjq4VajwLW/3ttyr8nPamw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=KdXbeXY9FqLz9MgIIX0aPtZmuLRTfrKNyaY869CRQ3SFAeT3HvF542/6heiLueTXQ JgmbFiV1GodGCQq5a0ySp97dw3fFyo3n24cB8jp2RvYE1KmGLh/SgzoxVuy/P6JcEI 7fAM50UwNRC10qmm71ZFbKzI3mITPrO8aJyK9ECHuTC17Qbabf+NqzfNYCJofqiZf6 3sDxHT1P0kLmCx20bZoC3oHa+F9PpAZ1iKW9NnDvDVbeqJ/FGMZldA1o55D1orLX8V 1GQuVHMa9/zio5uhderzezEiqpy4YzGJDV38Erz/NSHvxnDgm/yPHud22PhvCHUCOG HE9iUNTm3w0xg== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Tim Bruijnzeels In-Reply-To: <9dcd34e6-3b07-c8fc-99b3-df9365cb19f1@verizon.net> Date: Mon, 14 Jun 2021 17:06:10 +0200 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <44CDF8B7-B099-499F-94A5-914238FAFA51@nlnetlabs.nl> References: <4576a83c-4118-9e4e-aec1-e8e9b0a1a069.ref@verizon.net> <4576a83c-4118-9e4e-aec1-e8e9b0a1a069@verizon.net> <1EF06618-5BF8-46CE-A25C-37D98867EADF@nlnetlabs.nl> <9dcd34e6-3b07-c8fc-99b3-df9365cb19f1@verizon.net> To: Stephen Kent Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-6486bis-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 15:06:23 -0000 Dear Steve, WG, > On 14 Jun 2021, at 15:53, Stephen Kent = wrote: >=20 > Tim, >=20 >> Thank you for taking this effort! >>=20 >> I have some comments / questions I would like to bring up. >>=20 >>=20 >> - Section 2 Manifest Scope >>=20 >> This section may benefit from a reference to RFC 6481. In particular, = it may not be clear to the reader now that there MUST be only one CRL = issued under a CA (certificate). Perhaps replace: >> =20 >> o the most recent CRL issued by this CA, and >>=20 >> With: >>=20 >> o the single, most recent, CRL issued by this CA [RFC 6481], and >>=20 >=20 >=20 > done. >=20 >> - Section 3 Manifest Signing >>=20 >> Job talked a bit about this as well. =46rom my point of view, I = believe that all CA implementations use single-use EE certificates for = manifests. I don't see a use-case for multi-use in this context. >>=20 >> This is not a showstopper to me, but I think that we have an = opportunity to say the single use EE certificates MUST be used, and if = we have just one option then this will make the document easier to parse = and reason about. E.g. section 4.2.1 can be simplified. >>=20 >=20 >=20 > I agree this change would make the doc simpler, but I need to hear = from other CAs to confirm that NOBODY issues multi-use EE certs in = manifest before making this change. >=20 >> - Section 5 Manifest Generation >>=20 >> There is no text here that says that the single use EE certificate = for the previous manifest (if single-use applies) should be revoked. = Although later it is implied that a manifest can be revoked. Is this = intentional? >>=20 > Recall that 4.2.1 calls for the manifest EE cert (if single use) to = have a validity period that matches that of the manifest, to avoid the = need to revoke that cert when a new manifest is issued. So, unless a new = manifest is issued before the old one expires, it is intentional that = the cert for the old manifest not be revoked. >=20 >> Currently my CA implementation revokes old manifests. It is trying to = be thorough. > does it do this in all cases? since you indicate that you are = employing single-use EE certs here, that behavior runs counter to 4.2.1, = unless the new manifest is issued before the old one expires. Also, do = you remove the revoked EE cert from the CRL as soon as it expires, which = should usually be before the next manifest is issued. Krill defaults to 24 hours for the next update time on CRLs and = Manifests. The not-after time on the manifest EE currently still = defaults to 7 days following discussions we had about this in sidr many = years ago. I am quite happy to change this match the next update time = instead as this document now instructs. But in any case a new Manifest and CRL are issued by default 8 hours = before they would go stale. I don't dare to leave this much longer, I = think a CA operator needs this window to be able to deal with unforeseen = outages. When a manifest is replaced the previous EE cert is revoked - and its = not-after (expire) time is remembered. When that time has passed the = entry is removed. All these values are configurable. I don't know for sure how other CA = implementations do this. It would be good to hear from them. Based on = memory at least the RIPE NCC managed CA uses a similar strategy. >> ... >>=20 >> One could therefore argue that rather than revoking previous = manifest, the 'thisUpdate' or possibly 'manifestNumber' should be = leading in selecting an eligible manifest - should an RP have multiple = validly signed and current manifests for the same CA somehow. Not = revoking previous manifests would help to avoid the "chicken and egg" = issue raised in section 6. It is not clear to me that this would really = be less safe. >>=20 >> But look, really, rather than trying to pick an argument over this, I = raise this because I would like to see explicit text in the document = that says what's expected here :) >>=20 > as I said, unless a CA issues a new manifest before the next scheduled = issue time, this ought not be an issue. As above, I don't dare to leave this to the last moment. Furthermore, there could be other changes like a change in ROAs that = require a new manifest to be issued. Which reminds me.. I am not sure now if or where this is required, but = in order to keep things simple to reason about I always issue a new = manifest and CRL together. It's not that the CRLs get huge, because revocations for expired EE = certificates get removed as well. But, then again, I still think these = manifest EE revocations are most likely not needed at all because with = this -bis because RPs would only accept a new CRL with a changed hash, = when they have already seen the replacement manifest. >=20 >=20 >=20 >> - Section 6 >>=20 >> I believe we have had discussions as a WG and concluded that any = current RPKI object (such as ROAs) which are NOT on a manifest can be = considered out-of-scope and de-facto invalid by RP software. Notable = exception to this would be objects which are never intended to be = published inside the regular RPKI such as RSC and RTA objects in future.=20= >>=20 > The notion of manifest scope is defined in Section 2. It says that " = ... all published signed objects that are verifiable using EE = certificates [RFC6487] issued by this CA." are in scope. So, based on = that text, it would seem that the RSC and RTA objects are in scope. = Also, the RTA ID indicates that these objects may appear on a manifest, = so I find the proposed, revised text confusing.=20 I am not vested in the text I proposed. I believe that for normal top-down validation RPs need not consider any = objects not found on manifests. This seems to align with what you are = saying. But what I am after is the following. RTA as proposed supports the idea = of out-of-band exchanges of RTA objects, where those objects may NOT = appear in RPKI. I believe RSC supports this option as well (but I need = to re-read). So, in short, they may or may not appear on manifests. So, = I would prefer that RPs can still do ad-hoc validation of RTA objects = which they received out-of-band. Typically the RTA EE certificate would = refer to a CRL and parent CA certificate which can be found in the RPKI = (and manifests). Open to other text and discussion. Tim >=20 >> If I misunderstood please let me know. But otherwise might I suggest = updating the first sentence: >>=20 >> Current: >> =20 >> Each RP must determine which signed objects it will use for >> validating assertions about INRs and their use (e.g., which ROAs = to >> use in the construction of route filters). ... >>=20 >> Suggest: >>=20 >> Each RP MUST use the current manifest of a CA and add each listed >> file to the set of signed objects it will use for validating = assertions >> about INRs and their use (e.g., which ROAs to use in the = construction >> of route filters). Any files not listed on the manifest MUST NOT = be >> used for validation, unless the profile of its RPKI object type >> explicitly states otherwise. ... >>=20 > Steve > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Mon Jun 14 08:18:11 2021 Return-Path: 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 E00803A27C5 for ; Mon, 14 Jun 2021 08:18:09 -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, 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 (1024-bit key) header.d=fastly.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 gwSgYL3UVaMi for ; Mon, 14 Jun 2021 08:18:05 -0700 (PDT) Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) (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 5BAC43A27C3 for ; Mon, 14 Jun 2021 08:18:05 -0700 (PDT) Received: by mail-ej1-x633.google.com with SMTP id l1so17228174ejb.6 for ; Mon, 14 Jun 2021 08:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=bfnG5yatiK0A5/ZZ0jiVjtuJZU7YOsMFOGu7jPx733k=; b=hP75X59gyaeQKOEmAaZX2lu1i+igMxj/NR7tzBpb8MfVS9i6PgNumfGYjPgUsPows6 M8YViO/gDqUl0aZ7eg6Xm1vBW56zgTs2Cn9qTyu/KRgBCSflL8T6A+kH+oiV32m+dT2D ULzv9vl8X2r8SC2Pr1QRRWu8NwqxdFOa3u1BA= 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:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=bfnG5yatiK0A5/ZZ0jiVjtuJZU7YOsMFOGu7jPx733k=; b=o3vSTSgb8Wq2aImxQh0cJ/O3VN6Gy51bXHoaWp6rMGSrLt4MgPkplNAaQewkKIg9f5 6iLt5GHemAjIPyT0E6aWXGKF3qgooUztvLHLnerRO3RVK5AwIWnsD6Hqy7OW7xVJ9oU9 nXDvrej/h7Bk9tU/XsRKe4p/IamTv4E0XGLoWfmbN0b4d7y/OxZJAXrFG2/XEldk425L sAYLdmQQjAJp83k1PFTR0tQNbfpregbjBzQud5H0nfwIDfd37u8zPDN3oJRRbHcqQbkI rIijnYk2Ss6vobc/B/XJhnyyD9JysJ1lxh6ArjZ2WLLdqm0L5nUbZ1ppmMzjs/S9Ec24 E8vA== X-Gm-Message-State: AOAM531ZAbO+XspfRI+YExqAUMpaMoXnxQFIwBhQAsveTv5cgHKU7Y9W p+bXXcOskCOeJE1UCkJViSFZ4w== X-Google-Smtp-Source: ABdhPJzJk4ZsWVhTmTXTkZxH+OtSk2h4VSotfvMxN2sYOTak21cel0IR5mzZVBh/47oy3Wzs0RIhEQ== X-Received: by 2002:a17:907:2057:: with SMTP id pg23mr15575165ejb.113.1623683882202; Mon, 14 Jun 2021 08:18:02 -0700 (PDT) Received: from snel (mieli.sobornost.net. [45.138.228.4]) by smtp.gmail.com with ESMTPSA id f6sm7465317eja.108.2021.06.14.08.18.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Jun 2021 08:18:01 -0700 (PDT) Date: Mon, 14 Jun 2021 17:17:30 +0200 From: Job Snijders To: Tim Bruijnzeels Cc: Stephen Kent , sidrops@ietf.org Message-ID: References: <4576a83c-4118-9e4e-aec1-e8e9b0a1a069.ref@verizon.net> <4576a83c-4118-9e4e-aec1-e8e9b0a1a069@verizon.net> <1EF06618-5BF8-46CE-A25C-37D98867EADF@nlnetlabs.nl> <9dcd34e6-3b07-c8fc-99b3-df9365cb19f1@verizon.net> <44CDF8B7-B099-499F-94A5-914238FAFA51@nlnetlabs.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44CDF8B7-B099-499F-94A5-914238FAFA51@nlnetlabs.nl> X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-6486bis-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 15:18:10 -0000 On Mon, Jun 14, 2021 at 05:06:10PM +0200, Tim Bruijnzeels wrote: > I believe that for normal top-down validation RPs need not consider > any objects not found on manifests. This seems to align with what you > are saying. > > But what I am after is the following. RTA as proposed supports the > idea of out-of-band exchanges of RTA objects, where those objects may > NOT appear in RPKI. I believe RSC supports this option as well (but I > need to re-read). So, in short, they may or may not appear on > manifests. So, I would prefer that RPs can still do ad-hoc validation > of RTA objects which they received out-of-band. Typically the RTA EE > certificate would refer to a CRL and parent CA certificate which can > be found in the RPKI (and manifests). > > Open to other text and discussion. RSC is always distributed 'out-of-band', thus they MUST NOT appear on a Manifest, please see: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rsc-04#section-2 As a consequence, RSC objects do not have a 'Subject Information Access' extension. The RSC's AIA and CRLDP point to objects in the global RPKI. A (currently valid under RIPE TA) example RSC file can be found here: https://mailarchive.ietf.org/arch/msg/sidrops/TbCem3eu_PW8BRyBl48oqh1La74/ Kind regards, Job From nobody Mon Jun 14 16:58:01 2021 Return-Path: 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 A464E3A1439 for ; Mon, 14 Jun 2021 16:58:00 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 hpEOuCR9HBB3 for ; Mon, 14 Jun 2021 16:57:56 -0700 (PDT) Received: from sonic304-10.consmr.mail.bf2.yahoo.com (sonic304-10.consmr.mail.bf2.yahoo.com [74.6.128.33]) (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 952DC3A143D for ; Mon, 14 Jun 2021 16:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1623715075; bh=oWgBE404GdVt+mFcYLQMQmEjnZDA03fqYK9snf2iUFM=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject:Reply-To; b=mwODe5iBBewwfVrKKUKBG1VOxSVaU7F7ouOqlzWiVPduM/GQT0yTZskzmc6YJcvrfyvhnLdcj6QCOqjxNe+l0qCaTp2dRk8XpPWVi+wH3wTo9cxCgXYhHjWMU9q5aHmPm028xVNf3BkLIaH5zxW6L3GfuVQZfQHONSQrC4qjdTHDj754eGWXoKXv2y+7eMuO+Hq21mlDbqyPIUBOMLNPSorFWblCFThihRg6UU0/6namfDQlAD3wHGI7lTtRMd0SvV7f4DOHq0Az2hE43bKjMoVu/ulJ0Hk9aXguuxLHVCpO5B27Bxp28ROTx+JzQqxje/8ElBns6ufcHV7DaCpD+g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1623715075; bh=+x0iezh+p59nyG37bjH/BdrLA7uUB4Pq4Ae6HU8MLvF=; h=X-Sonic-MF:From:Subject:To:Date:From:Subject; b=YkYRVcrdZmJxrtRx6o0ppSZRg6nmXM29OONBvajLQPvND8R0mC7qRRykT7Gu2tMc8Jq3jXo7CNxtGv87SDNg+Fr/vlLjSXLQW5SDXo7QVaKMDYGCbEltYCv2vl/Hve0GzauPH8fGmAenqAnoGIEJpTaV6FbN7+4GqfH/ooN+vle2t36hcCJdjll9AMDJn1SQKNSUBoDYzuJvSFcLG50NGde9KYespfrVoO1pblrmsZNbxVVpAwLpVV0+N3Sj0wlWG4s1fCFBVvi0Uu8QdJjjLKPWPKSG0fSnBtzCqsucS/E6y0L8wVIypzjwRui+ZmvwVFHEdUqVLQ5rTcm5zKMf4Q== X-YMail-OSG: 5MxN9JQVM1nm.rKtqtqZuXP7ZtsCPivsGuVpdkQ_tWQIwPFaSvuet4kunK2YPaU XrfkNwCT1Xlh4noh6ES5q5jGiH3MPnSYs4nWkrrTRODKqnU84j0p3lE13DGhCoGpivDh7oYdTNqO VrXd4qXOzhBjXI76GwUVhDI0QDzaex_x0EKBxTBjaWtO2thf8XfjPL9tzRNgxqU8290Q5z2dV8Rm h.l8Zgu2ZvUHNVMhqzQA6qwOLkUBjYLW8GPJJcmQtZ0W9NHNLTqhuXyoO_0UQQgiHHDogMx5Lfxu IyOoClQxWMcYyUObXTJT8mUzLA4lShsytZeYWYkYz6q3KYPDIU6c04aYux5k78nWkGeRetFp_uGh P42I2qvmWb.KytjiXMqpUAlAol0Y0PthMhaM_mVQq0qN5Nnc78Nqs2HFBqfeJeGezuEAfj49yF9y WDQ4DgAG7jVDyO1UKaXYkSYYTr4qGLKnC40wpKjOZi9ag_sQctUgtARnywV9hhaGWza6P4.pcCuI 1duPJFgPTLqvQHTVsuDpeQ8.wtNtXSWLEn5koj8PlNAEBbD.SWK292qDDY7FiD0kE1ivdjQDL1KR Ti9LjCfud9t6vI7vyaiX7G7F0xNIjMdeEQoASkPez7lPHB1O.bV7egg_pDCc3dsocHWewLG0q7MQ Nq6BXkKl3m5okJy.Z79AlxXHBAxgkJeG2S_ejKKbPFQi31EgbuQyUCDUR4dpTt8M2MQvQG_u.Mim qvpqFbSKd5u26Xeb7rU73Rq5UNQhoQM9UjF5zRlvF6R8jXgaAJxNq7ksMBqINl6X_RORiT._UrXO qNQpsjsoaZZau7b_iQ6M9pmVFiV91KDTqfH1rV9xx.7ysFy.YqRRsRUZDuPoVTpj7nwcndGrM9NJ vkvD.RKavqDjUwa8hqpNHKF71W2uwCfuyzXuM7voXm0NHMeGTiZu.fArK4lxnZzrxJZM3eIujQOy i2wCeivwPvbP9hRvH_UsfSa7PLcRwWyKeJXOoffj5fnHxP0xc0mdiHo9bDXfsO0IXvBaW6pyFPKt DPU16YXvDiazdvAdHft_FYaRjBNJZH9t4Q54BQbhE7hHlhfGv3YtR1zfjkOS5Rgp7akKGp_2RbFt lWvncY.hK_XVpGFKnHnKZojKzOB1aIMYIJk0ghGJ5.Mv6crFJX6_830aoCq2XfYxoPk0c4Qe0LmF g_HzXlddgFHUoj5puVLgduzw2kRpA5yN0opJoKFnKG7cFo6LIFRNbQbqzBbobywhMKi59fUZ2Ejp YYUigKS0b6s7hlbWVYw05FZ62t.insjEUVQUH2ueo2i3YWHKCJUm1FwFUGtCbBa7fELOcVyFA6Lq X24pWWtZd.c_2NU6rvAAIgCmRePyZRLdgknJunlTYnlrisH6Evzzd0WsPmN9CX1tUcXmNVgXuoVM R9FwH5uzyDO_3rlXI2F.dj.G2XR3gBmy2PHZolODeif9isXt9XD.UmrjnqkEwTSkWTEInyZck2Yx rDgSFJfKk1HZ1tJFP3mY2gOAVZzro2hYgIjSt3WtD7c_0IPFOIDG4_KxCwF9TFfhHFTrsjZGxNUO EOgh2ERYI43T90Yw.ZfHtOIhfUeeRjLav36vkLHS_BeEQgYYs7uGgVr8XRhV84_Z5M0hgNsSi2uO in7671eQj4u74etXFo3T8bpGKfrQrAPO9lWA.7eemC9ma1mOcNt0pxzTbtLC5ERrL2M9G6kLSWHA djGTUPyehpq1Wq5Cg92Cn7.itOEQkZGg5kNTNt4kLB.3L9NYxeu0yr_ZdOginLUGaFKAXJNfhIWr jvA4lKQYKikq0mEluJHl8A30rsZpEUWF1vskiIzSfI_OIT6Ao5pEt6pOC.OzPeW2inCeCgbtRHJF Pan4CTNjhMubpHp_VlDfjzKIZsxX1gggAm0TceGQhS9etswSsL1wb_6hIXANjFmei1GufKSfwEid vzLRJuEoUydVOz9rz7yA0L311vMH.4QHNRPCAPyxFi5Kj.KflhY_g7x0AkqM1AQ8N0GYs_kZFWtk vosKYVLd0XHhwN8Q6xAY7UYdQ_vEUHZanb_44kVmRdAgHvAbhnlYVbZEhDu0w60VOioMbVz4iRUZ 39F.dUYta2K9X2bD8cvtnOttrNtSWIXSKqsrXp82ANaDGDyndo_Fd53yG3YJUT4QuU0PKSe125w2 PIVstkm.j4s38SA3TPaleXtHzdmqjZ6WSIqIrC1g7713dFWTxUP77Hey9dqOJaMtwHwCF.tgY9ku oj.Hn_r.2WTVJVgTkiw9vkh2TlN0ZnV6J1DjQFrdNHy51vgaTYYkPqCXdtm5IcaLG43U1O6ne4Q1 WpXnwQUs_DQYcGHesfwsugYcG1CRkQ7uBszeOhwb3Da3hjUAh7yzEq6Yd6aBkdOeG_cII8HM6osh Xa2PHD_Hdjk34HLAOJedF9eHe9aKKSlkscGdpllggubAMXhnA6b1JEcKlnNGfr6zNmO8ExNA- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Mon, 14 Jun 2021 23:57:55 +0000 Received: by kubenode516.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1cc354b82348c3e43e79a0f48de35c6a; Mon, 14 Jun 2021 23:57:52 +0000 (UTC) From: Stephen Kent To: Tim Bruijnzeels Cc: sidrops@ietf.org References: <4576a83c-4118-9e4e-aec1-e8e9b0a1a069.ref@verizon.net> <4576a83c-4118-9e4e-aec1-e8e9b0a1a069@verizon.net> <1EF06618-5BF8-46CE-A25C-37D98867EADF@nlnetlabs.nl> <9dcd34e6-3b07-c8fc-99b3-df9365cb19f1@verizon.net> <44CDF8B7-B099-499F-94A5-914238FAFA51@nlnetlabs.nl> Message-ID: <914036da-a5d0-060b-b5f3-2693d204c1e2@verizon.net> Date: Mon, 14 Jun 2021 19:57:51 -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: <44CDF8B7-B099-499F-94A5-914238FAFA51@nlnetlabs.nl> Content-Type: multipart/alternative; boundary="------------A1C4BD3FE532CE59079C28BB" 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: Subject: Re: [Sidrops] draft-ietf-sidrops-6486bis-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2021 23:58:01 -0000 This is a multi-part message in MIME format. --------------A1C4BD3FE532CE59079C28BB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Tim, > Krill defaults to 24 hours for the next update time on CRLs and > Manifests. The not-after time on the manifest EE currently still > defaults to 7 days following discussions we had about this in sidr > many years ago. I am quite happy to change this match the next update > time instead as this document now instructs. So, to be clear, a new CRL and manifest are issued every 24 hours, but the manifest EE cert has a 7-day lifespan, right? Since you say that the manifest EE cert is a one-time use, this clearly contradicts the text in the manifest spec. Please do change the validity interval. > But in any case a new Manifest and CRL are issued by default 8 hours before they would go stale. I don't dare to leave this much longer, I think a CA operator needs this window to be able to deal with unforeseen outages. > > When a manifest is replaced the previous EE cert is revoked - and its not-after (expire) time is remembered. When that time has passed the entry is removed. > > All these values are configurable. I don't know for sure how other CA implementations do this. It would be good to hear from them. Based on memory at least the RIPE NCC managed CA uses a similar strategy. It would seem that each old manifest cert lives on a CRL for about 6 days, so there might be 5 or 6 of them on the CRL at any time, needlessly. That's not awful, but it's not pretty either. >>> ... >>> >>> One could therefore argue that rather than revoking previous manifest, the 'thisUpdate' or possibly 'manifestNumber' should be leading in selecting an eligible manifest - should an RP have multiple validly signed and current manifests for the same CA somehow. Not revoking previous manifests would help to avoid the "chicken and egg" issue raised in section 6. It is not clear to me that this would really be less safe. >>> >>> But look, really, rather than trying to pick an argument over this, I raise this because I would like to see explicit text in the document that says what's expected here :) >>> >> as I said, unless a CA issues a new manifest before the next scheduled issue time, this ought not be an issue. > As above, I don't dare to leave this to the last moment. > > Furthermore, there could be other changes like a change in ROAs that require a new manifest to be issued. I am curious- do you track how often a new manifest needs to be issued because a ROA has changed? It would be useful to know if manifests are being reissued frequently only because a timer dictates it, not because any object covered by the manifest has actually changed. > Which reminds me.. I am not sure now if or where this is required, but in order to keep things simple to reason about I always issue a new manifest and CRL together. I don't think any text requires that a new CRL MUST be issued with every new manifest, although the opposite is obviously true if the old manifest EE cert is revoked. If a new manifest is issued 8 hours before the old one expires, and if there are no changes in the objects covered by the manifest, other than a new CRL, and if that CRL is also unchanged in terms of the revoked certs being listed, then there seems to be a lot of churn for no obvious reason. > It's not that the CRLs get huge, because revocations for expired EE certificates get removed as well. But, then again, I still think these manifest EE revocations are most likely not needed at all because with this -bis because RPs would only accept a new CRL with a changed hash, when they have already seen the replacement manifest. > >> ... > I am not vested in the text I proposed. > > I believe that for normal top-down validation RPs need not consider any objects not found on manifests. This seems to align with what you are saying. cert path validation is always top-down, as per 5280 and its predecessors. > But what I am after is the following. RTA as proposed supports the idea of out-of-band exchanges of RTA objects, where those objects may NOT appear in RPKI. I believe RSC supports this option as well (but I need to re-read). So, in short, they may or may not appear on manifests. So, I would prefer that RPs can still do ad-hoc validation of RTA objects which they received out-of-band. Typically the RTA EE certificate would refer to a CRL and parent CA certificate which can be found in the RPKI (and manifests). Well, we've been reminded by Job that RSC doesn't assume distribution via the RPKI, so ... I propose the following text to begin Section 6: Each RP MUST use the current manifest of a CA to control addition of listed files to the set of signed objects the RP employs for validating basic RPKI objects: certificates, ROAs, and CRLs. Any files not listed on the manifest MUST NOT be used for validation of these objects. However, files not listed on a manifest MAY be employed to validate other signed objects, if the profile of the object type explicitly states that such behavior is allowed. Note that relying on files not listed in a manifest may allow an attacker to effect substitution attacks against such objects. Steve --------------A1C4BD3FE532CE59079C28BB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Tim,
Krill defaults to 24 hours for the next update time on CRLs and Manifests. The not-after time on the manifest EE currently still defaults to 7 days following discussions we had about this in sidr many years ago. I am quite happy to change this match the next update time instead as this document now instructs.

So, to be clear, a new CRL and manifest are issued every 24 hours, but the manifest EE cert has a 7-day lifespan, right? Since you say that the manifest EE cert is a one-time use, this clearly contradicts the text in the manifest spec. Please do change the validity interval.

But in any case a new Manifest and CRL are issued by default 8 hours before they would go stale. I don't dare to leave this much longer, I think a CA operator needs this window to be able to deal with unforeseen outages.

When a manifest is replaced the previous EE cert is revoked - and its not-after (expire) time is remembered. When that time has passed the entry is removed.

All these values are configurable. I don't know for sure how other CA implementations do this. It would be good to hear from them. Based on memory at least the RIPE NCC managed CA uses a similar strategy.

It would seem that each old manifest cert lives on a CRL for about 6 days, so there might be 5 or 6 of them on the CRL at any time, needlessly. That's not awful, but it's not pretty either.


...

One could therefore argue that rather than revoking previous manifest, the 'thisUpdate' or possibly 'manifestNumber' should be leading in selecting an eligible manifest - should an RP have multiple validly signed and current manifests for the same CA somehow. Not revoking previous manifests would help to avoid the "chicken and egg" issue raised in section 6. It is not clear to me that this would really be less safe.

But look, really, rather than trying to pick an argument over this, I raise this because I would like to see explicit text in the document that says what's expected here :)


as I said, unless a CA issues a new manifest before the next scheduled issue time, this ought not be an issue.

As above, I don't dare to leave this to the last moment.

Furthermore, there could be other changes like a change in ROAs that require a new manifest to be issued.

I am curious- do you track how often a new manifest needs to be issued because a ROA has changed? It would be useful to know if manifests are being reissued frequently only because a timer dictates it, not because any object covered by the manifest has actually changed.

Which reminds me.. I am not sure now if or where this is required, but in order to keep things simple to reason about I always issue a new manifest and CRL together.

I don't think any text requires that a new CRL MUST be issued with every new manifest, although the opposite is obviously true if the old manifest EE cert is revoked. If a new manifest is issued 8 hours before the old one expires, and if there are no changes in the objects covered by the manifest, other than a new CRL, and if that CRL is also unchanged in terms of the revoked certs being listed, then there seems to be a lot of churn for no obvious reason.

It's not that the CRLs get huge, because revocations for expired EE certificates get removed as well. But, then again, I still think these manifest EE revocations are most likely not needed at all because with this -bis because RPs would only accept a new CRL with a changed hash, when they have already seen the replacement manifest.
... 
I am not vested in the text I proposed.

I believe that for normal top-down validation RPs need not consider any objects not found on manifests. This seems to align with what you are saying.
cert path validation is always top-down, as per 5280 and its predecessors.
But what I am after is the following. RTA as proposed supports the idea of out-of-band exchanges of RTA objects, where those objects may NOT appear in RPKI. I believe RSC supports this option as well (but I need to re-read). So, in short, they may or may not appear on manifests. So, I would prefer that RPs can still do ad-hoc validation of RTA objects which they received out-of-band. Typically the RTA EE certificate would refer to a CRL and parent CA certificate which can be found in the RPKI (and manifests).

Well, we've been reminded by Job that RSC doesn't assume distribution via the RPKI, so ...

I propose the following text to begin Section 6:

  Each RP MUST use the current manifest of a CA to control addition of listed

  files to the set of signed objects the RP employs for validating basic RPKI

  objects: certificates, ROAs, and CRLs. Any files not

  listed on the manifest MUST NOT be used for validation of these objects.

  However, files not listed on a manifest MAY be employed to validate other

  signed objects, if the profile of the object type explicitly states that

  such behavior is allowed. Note that relying on files not listed in a

  manifest may allow an attacker to effect substitution attacks against such

  objects.

Steve


--------------A1C4BD3FE532CE59079C28BB-- From nobody Mon Jun 14 19:35:41 2021 Return-Path: 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 947EF3A1ABA for ; Mon, 14 Jun 2021 19:35:39 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 KZEqvxqLliXQ for ; Mon, 14 Jun 2021 19:35:37 -0700 (PDT) Received: from out20-74.mail.aliyun.com (out20-74.mail.aliyun.com [115.124.20.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 299D83A1AB9 for ; Mon, 14 Jun 2021 19:35:36 -0700 (PDT) X-Alimail-AntiSpam: AC=CONTINUE; BC=0.2254573|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.0375278-0.00105513-0.961417; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047194; MF=madi@rpstir.net; NM=1; PH=DS; RN=3; RT=3; SR=0; TI=SMTPD_---.KSLdn0F_1623724530; Received: from smtpclient.apple(mailfrom:madi@rpstir.net fp:SMTPD_---.KSLdn0F_1623724530) by smtp.aliyun-inc.com(10.147.41.121); Tue, 15 Jun 2021 10:35:31 +0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Di Ma In-Reply-To: <914036da-a5d0-060b-b5f3-2693d204c1e2@verizon.net> Date: Tue, 15 Jun 2021 10:35:29 +0800 Cc: Tim Bruijnzeels , sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4576a83c-4118-9e4e-aec1-e8e9b0a1a069.ref@verizon.net> <4576a83c-4118-9e4e-aec1-e8e9b0a1a069@verizon.net> <1EF06618-5BF8-46CE-A25C-37D98867EADF@nlnetlabs.nl> <9dcd34e6-3b07-c8fc-99b3-df9365cb19f1@verizon.net> <44CDF8B7-B099-499F-94A5-914238FAFA51@nlnetlabs.nl> <914036da-a5d0-060b-b5f3-2693d204c1e2@verizon.net> To: Stephen Kent X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-6486bis-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 02:35:40 -0000 Steve, >=20 > I propose the following text to begin Section 6: >=20 > Each RP MUST use the current manifest of a CA to control addition of = listed > files to the set of signed objects the RP employs for validating = basic RPKI > objects: certificates, ROAs, and CRLs. Any files not > listed on the manifest MUST NOT be used for validation of these = objects. > However, files not listed on a manifest MAY be employed to validate = other > signed objects, if the profile of the object type explicitly states = that > such behavior is allowed. Note that relying on files not listed in a > manifest may allow an attacker to effect substitution attacks = against such > objects. > Steve >=20 Does your proposal mean we have to extend RFC 3779 or RFC 6487 to = generally support an RPKI object noting itself required in MFT? Or we just need to make RSC/RTA to offer such information? I think the former will bring more tasks for IETF but may be a good way = to enhance the security of the RPKI. Di From nobody Tue Jun 15 01:04:35 2021 Return-Path: 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 6D4C93A258C for ; Tue, 15 Jun 2021 01:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 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_LOW=-0.7, 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=nlnetlabs.nl 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 AHw5NdNmHm4K for ; Tue, 15 Jun 2021 01:04:29 -0700 (PDT) Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.218]) (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 D11F73A258B for ; Tue, 15 Jun 2021 01:04:28 -0700 (PDT) Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id A56AF60042; Tue, 15 Jun 2021 08:04:24 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1623744264; bh=F1xGIeUDW67k8yC7QK6EbD7L4ksWNqhYdMp0LSnxVDg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=jtTiXVhwCnNFIm5baUqdTmcSekpG4ObMn0HHN5TlUjIQjRcidUkPSffIR0OGIF8HE n4nsudYodddV4iuZ4y3U6Fw1WXYAqOXkWvm56/hQfdo+lCQpRsNE/7UYCIqM66qqAR 816dTVChF/A50Lc47RJRkVVt+WZ2LTAWmEcWhTSgRlePt5sv+7+VU6JzbKJF02OXT9 1JD+nFtRsjwL9oTkzD3CIHP6BQ+vt/TttIc+tK5dFJDU6OioS5ofIlwZarLnwsVDhC rJBzntOWLcdaBSrGTXd4NtNf/Igb+q0dUQLNtHkUBmQv12oR8NXxyicrA5Pp5gmoJY awwvBqGSVQVfw== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Tim Bruijnzeels In-Reply-To: <914036da-a5d0-060b-b5f3-2693d204c1e2@verizon.net> Date: Tue, 15 Jun 2021 10:04:21 +0200 Cc: sidrops@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <492E346B-8B63-4048-AE07-AE46468B2281@nlnetlabs.nl> References: <4576a83c-4118-9e4e-aec1-e8e9b0a1a069.ref@verizon.net> <4576a83c-4118-9e4e-aec1-e8e9b0a1a069@verizon.net> <1EF06618-5BF8-46CE-A25C-37D98867EADF@nlnetlabs.nl> <9dcd34e6-3b07-c8fc-99b3-df9365cb19f1@verizon.net> <44CDF8B7-B099-499F-94A5-914238FAFA51@nlnetlabs.nl> <914036da-a5d0-060b-b5f3-2693d204c1e2@verizon.net> To: Stephen Kent Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-6486bis-04.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2021 08:04:35 -0000 Steve, Thank you for your response. > On 15 Jun 2021, at 01:57, Stephen Kent = wrote: >=20 > Tim, >> Krill defaults to 24 hours for the next update time on CRLs and = Manifests. The not-after time on the manifest EE currently still = defaults to 7 days following discussions we had about this in sidr many = years ago. I am quite happy to change this match the next update time = instead as this document now instructs.=20 > So, to be clear, a new CRL and manifest are issued every 24 hours, but = the manifest EE cert has a 7-day lifespan, right? Since you say that the = manifest EE cert is a one-time use, this clearly contradicts the text in = the manifest spec. Please do change the validity interval. More than happy to do so.. Fwiw this goes back to a discussion we had in sidr over 10 years ago. Of = course now I can't find the slides or email threads anymore, but I = remember presenting a question to the WG on this specific question - and = the outcome back then in my understanding was that it would good, = desired even, to have a slightly longer lifespan on the manifest EE = certs - and that 'stale' manifests and CRLs could result in warnings as = per local policy, while expired manifests would always be invalid. So, = right or wrong (probably) - this behaviour was based on what I believed = to be that outcome.. Anyway, I am more than happy to change this. I actually prefer to have = the lifespan of the EE match the next update time and have eliminate the = difference based on local policy of stale vs expired manifest that may = still be present in older deployed RP software. >=20 >> But in any case a new Manifest and CRL are issued by default 8 hours = before they would go stale. I don't dare to leave this much longer, I = think a CA operator needs this window to be able to deal with unforeseen = outages. >>=20 >> When a manifest is replaced the previous EE cert is revoked - and its = not-after (expire) time is remembered. When that time has passed the = entry is removed. >>=20 >> All these values are configurable. I don't know for sure how other CA = implementations do this. It would be good to hear from them. Based on = memory at least the RIPE NCC managed CA uses a similar strategy. >>=20 > It would seem that each old manifest cert lives on a CRL for about 6 = days, so there might be 5 or 6 of them on the CRL at any time, = needlessly. That's not awful, but it's not pretty either. I agree that the amount is not too bad. Still it is not clear to me whether I MUST, or MAY, or am RECOMMENDED to = revoke replaced manifests. Remember that you would only find the revocation if you had found a new = manifest and accepted the new CRL revoking the now irrelevant previous. = Given the choice I would rather *not* revoke them ever. >>>> ... >>>>=20 >>>> One could therefore argue that rather than revoking previous = manifest, the 'thisUpdate' or possibly 'manifestNumber' should be = leading in selecting an eligible manifest - should an RP have multiple = validly signed and current manifests for the same CA somehow. Not = revoking previous manifests would help to avoid the "chicken and egg" = issue raised in section 6. It is not clear to me that this would really = be less safe. >>>>=20 >>>> But look, really, rather than trying to pick an argument over this, = I raise this because I would like to see explicit text in the document = that says what's expected here :) >>>>=20 >>>>=20 >>> as I said, unless a CA issues a new manifest before the next = scheduled issue time, this ought not be an issue. >>>=20 >> As above, I don't dare to leave this to the last moment. >>=20 >> Furthermore, there could be other changes like a change in ROAs that = require a new manifest to be issued. >>=20 > I am curious- do you track how often a new manifest needs to be issued = because a ROA has changed? It would be useful to know if manifests are = being reissued frequently only because a timer dictates it, not because = any object covered by the manifest has actually changed. I do not track how users of our software do this. It does not call home = :) But, this can be observed by anyone looking at the RPKI with = sufficient granularity. Generally speaking any change in ROAs or delegated certificates results = in a changed manifest. I believe that most RPKI CAs try to publish such = changes within seconds to minutes. For our own prefixes this is very infrequent - we just have few prefixes = out there which don't change, unless we are running experiments. For an = RIR or NIR delegated certificates change multiple times per day. For big = operators ROAs may change much more frequently than in our case. >=20 >> Which reminds me.. I am not sure now if or where this is required, = but in order to keep things simple to reason about I always issue a new = manifest and CRL together. > I don't think any text requires that a new CRL MUST be issued with = every new manifest, although the opposite is obviously true if the old = manifest EE cert is revoked. If a new manifest is issued 8 hours before = the old one expires, and if there are no changes in the objects covered = by the manifest, other than a new CRL, and if that CRL is also unchanged = in terms of the revoked certs being listed, then there seems to be a lot = of churn for no obvious reason. One reason is that it's just easier to reason about the next update time = for publishing both. Another reason is that I am always issuing new manifests before they = would expire, because I don't want a publication point to be rejected if = I am a few minutes late because of some issue. And the old manifest is = revoked, so that means the CRL changes. Furthermore I use the same 'next update' time on CRLs and manifests. And = I want to update the CRL before it would go stale for the same reason as = updating manifests. Longer lived CRLs could only work if I used = different times for both. Note that if I do not need to revoke previous manifest this CRL is = generally small, which reduces churn as well. >=20 >> It's not that the CRLs get huge, because revocations for expired EE = certificates get removed as well. But, then again, I still think these = manifest EE revocations are most likely not needed at all because with = this -bis because RPs would only accept a new CRL with a changed hash, = when they have already seen the replacement manifest. >>=20 >>=20 >>> ...=20 >> I am not vested in the text I proposed. >>=20 >> I believe that for normal top-down validation RPs need not consider = any objects not found on manifests. This seems to align with what you = are saying. >>=20 > cert path validation is always top-down, as per 5280 and its = predecessors. >> But what I am after is the following. RTA as proposed supports the = idea of out-of-band exchanges of RTA objects, where those objects may = NOT appear in RPKI. I believe RSC supports this option as well (but I = need to re-read). So, in short, they may or may not appear on manifests. = So, I would prefer that RPs can still do ad-hoc validation of RTA = objects which they received out-of-band. Typically the RTA EE = certificate would refer to a CRL and parent CA certificate which can be = found in the RPKI (and manifests). > Well, we've been reminded by Job that RSC doesn't assume distribution = via the RPKI, so ... >=20 > I propose the following text to begin Section 6: >=20 > Each RP MUST use the current manifest of a CA to control addition of = listed > files to the set of signed objects the RP employs for validating = basic RPKI > objects: certificates, ROAs, and CRLs. Any files not > listed on the manifest MUST NOT be used for validation of these = objects. > However, files not listed on a manifest MAY be employed to validate = other > signed objects, if the profile of the object type explicitly states = that > such behavior is allowed. Note that relying on files not listed in a > manifest may allow an attacker to effect substitution attacks = against such > objects. That works for me. Similar question to revocation of replaced manifests.. If I replace a .cer or .roa file with another one that has the same = name, and a new hash, do I still need to revoke the old file as well? = Given that a hash mismatch would be seen as a 'failed fetch'. Currently I do. I can keep doing it. But I observe that the CRL and = manifest are signed under the same CA certificate so I am not convinced = that doing both (replace hash and revoke old) adds security, while it = does make the CRL longer if there is lots of churn in ROAs or delegated = CA certificates. So, given the choice I would rather revoke objects only when their name = goes out of scope, or perhaps even never - as they "MUST NOT" be used = for validation if they are not listed. Note that I see full value in the CRL for validating out-of-band RSC/RTA = objects, or any object type which may be out of scope for manifests by = design. So, I hope that it's clear why I keep going on about the CRLs in this = context. I can keep revoking things like I do today, but I would = appreciate a clarification why this is better, and I think it may be = worthwhile documenting this explicitly. Tim > Steve >=20 >=20 >=20 > _______________________________________________ > Sidrops mailing list > Sidrops@ietf.org > https://www.ietf.org/mailman/listinfo/sidrops From nobody Thu Jun 17 16:08:47 2021 Return-Path: X-Original-To: sidrops@ietf.org Delivered-To: sidrops@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0463A3245; Thu, 17 Jun 2021 16:08:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sidrops@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.32.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sidrops@ietf.org Message-ID: <162397132033.32149.10121553443259737639@ietfa.amsl.com> Date: Thu, 17 Jun 2021 16:08:40 -0700 Archived-At: Subject: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-07.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 23:08:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIDR Operations WG of the IETF. Title : RPKI Signed Object for Trust Anchor Key Authors : Carlos Martinez George G. Michaelson Tom Harrison Tim Bruijnzeels Rob Austein Filename : draft-ietf-sidrops-signed-tal-07.txt Pages : 18 Date : 2021-06-17 Abstract: A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the Resource Public Key Infrastructure (RPKI) to locate and validate a Trust Anchor (TA) Certification Authority (CA) certificate used in RPKI validation. This document defines an RPKI signed object for a Trust Anchor Key (TAK), that can be used by a TA to signal the location(s) of the accompanying CA certificate for the current key to RPs, as well as the successor key and the location(s) of its CA certificate. This object helps to support both planned and unplanned key rolls without impacting RPKI validation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-sidrops-signed-tal-07.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-signed-tal-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 18 07:25:35 2021 Return-Path: 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 7273A3A4505 for ; Fri, 18 Jun 2021 07:25:33 -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 WKzaxpnL0KMz for ; Fri, 18 Jun 2021 07:25:31 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7620F3A44E9 for ; Fri, 18 Jun 2021 07:25:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 517ED300BDA for ; Fri, 18 Jun 2021 10:25:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Kk3EGzvOLHb6 for ; Fri, 18 Jun 2021 10:25:24 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 6E818300AEB for ; Fri, 18 Jun 2021 10:25:24 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Fri, 18 Jun 2021 10:25:24 -0400 References: <162397132033.32149.10121553443259737639@ietfa.amsl.com> To: SIDR Operations WG In-Reply-To: <162397132033.32149.10121553443259737639@ietfa.amsl.com> Message-Id: <0C37A560-8FA0-477A-8B93-DD8A200C6B16@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-signed-tal-07.txt X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2021 14:25:34 -0000 The ASN.1 Module should have "END" at the end, right before . Russ > On Jun 17, 2021, at 7:08 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the SIDR Operations WG of the IETF. >=20 > Title : RPKI Signed Object for Trust Anchor Key > Authors : Carlos Martinez > George G. Michaelson > Tom Harrison > Tim Bruijnzeels > Rob Austein > Filename : draft-ietf-sidrops-signed-tal-07.txt > Pages : 18 > Date : 2021-06-17 >=20 > Abstract: > A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the > Resource Public Key Infrastructure (RPKI) to locate and validate a > Trust Anchor (TA) Certification Authority (CA) certificate used in > RPKI validation. This document defines an RPKI signed object for a > Trust Anchor Key (TAK), that can be used by a TA to signal the > location(s) of the accompanying CA certificate for the current key = to > RPs, as well as the successor key and the location(s) of its CA > certificate. This object helps to support both planned and = unplanned > key rolls without impacting RPKI validation. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal/ >=20 > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-sidrops-signed-tal-07.html >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidrops-signed-tal-07 >=20 From nobody Mon Jun 28 06:49:46 2021 Return-Path: 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 39ECF3A07A5 for ; Mon, 28 Jun 2021 06:49:44 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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 Mu6XUXNb4eQl for ; Mon, 28 Jun 2021 06:49:40 -0700 (PDT) Received: from sonic308-56.consmr.mail.ne1.yahoo.com (sonic308-56.consmr.mail.ne1.yahoo.com [66.163.187.31]) (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 911503A07A4 for ; Mon, 28 Jun 2021 06:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1624888179; bh=GFoT4GoVhgPYDnIkOVF69UoVbLllUp44+KTvOMvKyvA=; h=To:Cc:From:Subject:Date:References:From:Subject:Reply-To; b=Uy6M+MfEykG35ugK2pploMClGu0PPU89/O4OrRirQg5WJoDatBqJOuUZj1KZn/6l3ijzKWXdaczKTSMieONy3doXnm1TBOSzzeKg2WJOeImJYrWLuymXA6QhasS3oi92sj7QEBUEO7cqI63ZyrhABxAQdnIwAGPWnv8Sdhs9yfPryX1/TRRQXhwFLLNfkjZtcR48x9AtwVuQBJ+Vk+n3nagRXUAVo1FmNXzpBf3XWZHhuL2Skaj+r16OwRvmDyKuX4t/3+mDP7BCchmhKBjkj1F9l+75bHbMSpw2c4EPwARuhCxJGExPBztiA8NhCqu4CEEmsFoLT3R1kuG/TJ6eyQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1624888179; bh=hF0+A+Sr0rWrClCwDjjTxGyeUIL/zhEbh81rEtWfxud=; h=X-Sonic-MF:To:From:Subject:Date:From:Subject; b=T3GW7SqSqAS7j3yTpvg/ta3TmRX/Hyb4tdfbkUvMhJU0AhFgl3/h+Bsl8SYZI7YVsD/i5mbti1Aphe2BUeb3OnVKKKy/LHq2LbVkO9WYgGkRvG5pp4AEHF/LXLcanf3xIAt7LrOf/Ku/nRutUM/eG2z1ovyOF4zwYBsxXNsJ9jE6oQF45DPjDefZpfeevfhRg2rg2DvpnniNSZLFwHIPL+0AAmEwGJGULh5j/nj6yVKGzq8EO7H17DnUMysKZRkyWtk1Rj8Te+eHxgmReXQCIq87ZKBpeNopG/nVUluVy+H3mRBCdcDCaalFwfx/JUf1Xd69Gvz1Ztm+/B35PbD3og== X-YMail-OSG: oSzElJEVM1ld0TRsyQTqWJU4mmNjD_WUgBhSCmKxGJEDXJnY2MKBtX8OnJSmhx8 vo7jXEAKFQdwPOxfONyHG5RNt4e6RnnqOjWk5RCGnZyA9TAAWDiqCKR8cTwQwiOiHqz3P_MRbfpP jxSltUPC_by6ZeyQhEGT5Py9J2W0XfFh4IxImj63whjHPjXPJT4yHE251o_LUSZDGaUgaDh9zXrQ I6mOYyG161zPTS07C.LdY_c7r0bRlCViIrppDOQS.Fz0mEqBHk9LJzHaRiNZz3.G.IjxKtI0MmHd ec6RPmWwbzE0qd6hMil9DEE4vxHwCVIwJ4AuY1f69_iG.fzfFizDUuRNBB79yP21TYiv3srzpxGX Wh6iAohT3_gu7Xox1CZL85QkSk3F8RXemP4dDmG_AVvoyGBINy_utQB6ZqjnnjYoDRZNa5_mi21x ebFA8oMAXk5cNn7OpWZizFUMVlx_ptEXRioJR7JfhupSJRZwOUkznLHtxIc9XlzM.ADyxMMXTs2H jQu9u8pgShZN_VHCn9ZnS0XeM49G_qFDRqyJXbFwIkBEUPyOEIdOH4MmZ4nR5p4UinFeFaS1.hUv YLeR0wq658AcAxWX5z1KO1Bp3mY8bLZyVawALmGA4uRTbBiW_QTQ9xxdk_0Zb.p9R_JKc_6uGceH O7nJVcy6mMFiqUXG2m.Y60HMGzIziX_L1e.cRswneVzix4fmU4No4PbmFYrUoWzjHBlhHaDfeFdI _m.8cX0rPxWkYjaKTvmCj8Tp8bA.TVaQaxqflv6g2JD4h4NQS8Z3fXYWHzl.xhdZc12f.8rG6REH Djsd8JoxqlqhW4db2cVjDgNaK5I5peQf8xzhoBQQwR4OW.h9R2uYchNkkbktKfJqjLrhe6yKExsO qnByHSyODH3jgFAyUBeTcrAETpQP7in2phLAGHLUc1WmxE2fy0HLnCEXrWXqhyxinEq4GJdzWQUK AlDW2tioknW8HGC1Q5jRNBdKg7GU14q0cf.83afNpNRwuaDf.j8olboDxwRjM8mhp2H1Xz8ciXVr eRghG50Nij0CwZAIGli5WsZsjjqijnBT5Z9KoxkgsAFWPTM_xe1hK_HpeXFdU002WA1xK6Zp_S8F 2l.Xp5y36A589ZczNwZCmP5qDlAEiViXGTP4pcW3TYi3iJf6MFPR6qr2RnHu6c6TFjVpXPA3MHr6 fxfNVZP5WQxP46AynrLnnGTVX8rSQvue81DpkvZH2RniYP5Ejgp7zGpRrJuiCcUPhALCEUC1zXaP CBBjPgnF7P5YOp4375MFXRqcrRxVnCo6AR0lQzTdH_qo4WohMcQQq4M6DBr27rIlue7x7mLVcKJa jr_DlykxPWI7lrRVWw0Ak7SfjLEnUEDiHuBki6cC_5CP7z51htf2aHprR6aDvy5JicuDUgFMX5ra RAa2mbiI4XFiwGOiK.UNkU3oaIASz3HnyUv_2yjk6uI0UBGongvv7eCnkQilI8mfVxtI9FOxrduT 0QYaB_FLFewyxTT6RR2ZF243br0ILe7kuVeYr0x9H0Rt6g_i3QWSPnjdXQxuGcJjp8NeaBj0irBU Gv7622SJ7ExJ_fZ30lIg8gHTSPKxMy.Tt.8bRKPrCNojw20iWbvqo9_0n3iETd_poWpnWAEVNHWX SOGDVV40nz5RS1AuLQJQhYjh_qizSBUsFcmQqYgZR6uWdLJH39eDT5YqCsv.4owTYuQQDyTkadEn u6qG7r9MKOUXxOhz84n9oS8msD30hsZA3sQG08X0NuK7MBUuDWOTjGghXcCl5Y0HwjeImnrYyCOP qfOotM8ACqOqUlWaaoF3gecgHkwszmW5o_vghIo4EuM4HRXtOKN5iT0kucoVpOqhPJd6HLCA1OZ4 RYLits1nVKYeNvctdn6aRSZbieOegyDUrDgS77hElhhtjm8F3d6GlQkuRNfFdvOGK108OO5Z4ezZ jUzIEysUZ8KZi4VCP2Mj.nvBP6aY0HLSruzr9pOFqjJ8xHUfO5jhpZ_eXBwGyraEAMKY5z2YbX.b SiOs7KsAmSXwyjk7MYlurkC5Sm_FCNjurYZGGob6KE..LSKjT5EffDdXfEHXpfjrpTX7_32BskSB kIxmfuPPf0svysld84XLxD0AKTJIEsjtgyzlKE0w3n2V8.Azvb3GRgeDO3Y_DUE6dCaEkVrQ0Xwb R5LClCC5SnpcTd0hMsZdkNhjKsPwXHyzRbdx14DO3vRDoPqab0pTQWySuDLqNoEXG0AI3QLipgOC UluVwneToGvRuDlLQ.NJsMI0UqLTDX3QcSvkdyFmZyhGZG7.RudJLDM7uGQ5ILfCysB3IBv9Ih52 cIIO6Bqi3zaeyq2K.Frh8PygBaaKyCFjka4M.C2Ky5ZUSfEKgXTpkqk6EAGDOkDLje_OFFJiKi2A vanCpe44cyJepLtkBSi0DThIqe9IwDLYTh_qcI7KC4aGWf7syS9P90LOf.a6t5N9JxJx3292_44O Hlaz6Pfdl X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Mon, 28 Jun 2021 13:49:39 +0000 Received: by kubenode547.mail-prod1.omega.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 48f0fe9c7d0135a42a85ceb3ef29bf1d; Mon, 28 Jun 2021 13:49:37 +0000 (UTC) To: tim@nlnetlabs.nl Cc: "sidrops@ietf.org" From: Stephen Kent Message-ID: <8a80575d-7ac2-d3b8-8232-12819070528d@verizon.net> Date: Mon, 28 Jun 2021 09:49:36 -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 Content-Type: multipart/alternative; boundary="------------75361455AABC7A80522F68D3" Content-Language: en-US References: <8a80575d-7ac2-d3b8-8232-12819070528d.ref@verizon.net> X-Mailer: WebService/1.1.18469 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-6486bis-04.tx X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 13:49:44 -0000 This is a multi-part message in MIME format. --------------75361455AABC7A80522F68D3 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Tim, Sorry to be replying belatedly- I was away when your message arrived and I lost track of it when I merged messages received during my trip with my inbox at home. So, I think we're in agreement to synch the lifetime of the EE cert use for the manifest with the NextUpdate time for the manifest. I don;t recall the discussions you cited, but it's long ago so ... To answer your question, I plan to change the text to say that a CA SHOULD revoke an expired, superseded manifest,until thecert for that manifest expires. I know what changes trigger generation of a new manifest; the question is how often is this triggered only by a CRL being republished, with no changes. It wuld be useful if anyone closely monitoring the RKI could provide info on this topic. It's good that you use the same NextUpdate time for manifests and CRLs. Since every new CRL (even if unchanged) requires a new manifest this is very appropriate. I also appreciate the desire to issue new versions of these data items prior to the expiration  of the prior version, to minimize the likelihood that an RP might reject the contents of a pub point because of unfortunate timing. You asked if replacing a .cer of .roa file, with the same name but a new hash, requires revoking the [cert] for the replaced objects. The generic PKI answer is yes. I'd rather not complicate life for RPs by having multiple, valid, not revoked certs and/or ROAs in the system simultaneously. Steve p.s. I am still waiting to hear from more CAs about whether they always employ singe-use EE certs for manifests. If this is what everyone does, then I will change the text to mandate this behavior, to reduce the complexity of the document. --------------75361455AABC7A80522F68D3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Tim,

Sorry to be replying belatedly- I was away when your message arrived and I lost track of it when I merged messages received during my trip with my inbox at home.

So, I think we're in agreement to synch the lifetime of the EE cert use for the manifest with the NextUpdate time for the manifest. I don;t recall the discussions you cited, but it's long ago so ...

To answer your question, I plan to change the text to say that a CA SHOULD revoke an expired, superseded manifest, until the cert for that manifest expires.

I know what changes trigger generation of a new manifest; the question is how often is this triggered only by a CRL being republished, with no changes. It wuld be useful if anyone closely monitoring the RKI could provide info on this topic.

It's good that you use the same NextUpdate time for manifests and CRLs. Since every new CRL (even if unchanged) requires a new manifest this is very appropriate. I also appreciate the desire to issue new versions of these data items prior to the expiration  of the prior version, to minimize the likelihood that an RP might reject the contents of a pub point because of unfortunate timing.

You asked if replacing a .cer of .roa file, with the same name but a new hash, requires revoking the [cert] for the replaced objects. The generic PKI answer is yes. I'd rather not complicate life for RPs by having multiple, valid, not revoked certs and/or ROAs in the system simultaneously.

Steve

p.s. I am still waiting to hear from more CAs about whether they always employ singe-use EE certs for manifests. If this is what everyone does, then I will change the text to mandate this behavior, to reduce the complexity of the document.



--------------75361455AABC7A80522F68D3-- From nobody Mon Jun 28 14:29:45 2021 Return-Path: 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 B6D9E3A132E; Mon, 28 Jun 2021 14:29:42 -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 i2BwANH1VHtH; Mon, 28 Jun 2021 14:29: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 E7D3F3A1328; Mon, 28 Jun 2021 14:29:39 -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 1lxyot-0004ln-2J; Mon, 28 Jun 2021 21:29:31 +0000 Date: Mon, 28 Jun 2021 14:29:30 -0700 Message-ID: From: Randy Bush To: Stephen Kent Cc: tim@nlnetlabs.nl, "sidrops@ietf.org" In-Reply-To: <8a80575d-7ac2-d3b8-8232-12819070528d@verizon.net> References: <8a80575d-7ac2-d3b8-8232-12819070528d.ref@verizon.net> <8a80575d-7ac2-d3b8-8232-12819070528d@verizon.net> 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: [Sidrops] draft-ietf-sidrops-6486bis-04.tx X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 21:29:43 -0000 > So, I think we're in agreement to synch the lifetime of the EE cert > use for the manifest with the NextUpdate time for the manifest. I > don;t recall the discussions you cited, but it's long ago so ... sra raised this a few years back, showing actual failures do to the lack of congruence. we can dig it up if it would help. randy From nobody Tue Jun 29 02:26:11 2021 Return-Path: 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 8E5D73A2CB2 for ; Tue, 29 Jun 2021 02:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 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_LOW=-0.7, 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=nlnetlabs.nl 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 pSxKv6u8sdP4 for ; Tue, 29 Jun 2021 02:26:03 -0700 (PDT) Received: from outbound.soverin.net (outbound.soverin.net [116.202.126.228]) (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 AEC3B3A2CB3 for ; Tue, 29 Jun 2021 02:26:03 -0700 (PDT) Received: from smtp.soverin.net (unknown [10.10.3.28]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id B4CDC94A; Tue, 29 Jun 2021 09:26:00 +0000 (UTC) Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.142]) by soverin.net DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1624958759; bh=P+6d0UYPvBDQH+sGePvlG2SehTuis4xebTjaBCxM5H4=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Rc5IicT5Wvap3zWcYWt+Jk6TDDGiMSdi58dYoQ9BgeIRRrLKHirMU21Zh60+2mviZ uD/tblCxjGbZ8tAIYFFwVzrjTBNvs0ctc5tLiLP3TXQUp6HkUL9YGHEYP8OefHJJs3 vgN7nwfIzKzY7KlAxHMrg0q7sCbHdXU/z7pw/qMVnch5z9V67FxSSpR2Xr5A9QOBYy 5fmymwAUxAZsrNwU2N1B2oFqGGR6VCI+PzLayE8i4WY5IXVJjfh4Rq+Hn4XPbq5Xt6 mA+pEL7qk2/LvxfhGJDxmSy5L59CXFZVjMbTrtAFerczXIS6Fah3nN1omyvUmvqUfE rsP/TOeyxDo2w== Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Tim Bruijnzeels In-Reply-To: Date: Tue, 29 Jun 2021 11:25:56 +0200 Cc: Stephen Kent , "sidrops@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <8a80575d-7ac2-d3b8-8232-12819070528d.ref@verizon.net> <8a80575d-7ac2-d3b8-8232-12819070528d@verizon.net> To: Randy Bush Archived-At: Subject: Re: [Sidrops] draft-ietf-sidrops-6486bis-04.tx X-BeenThere: sidrops@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A list for the SIDR Operations WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 09:26:10 -0000 Hi, > On 28 Jun 2021, at 23:29, Randy Bush wrote: >=20 >> So, I think we're in agreement to synch the lifetime of the EE cert >> use for the manifest with the NextUpdate time for the manifest. I >> don;t recall the discussions you cited, but it's long ago so ... >=20 > sra raised this a few years back, showing actual failures do to the > lack of congruence. we can dig it up if it would help. First off.. again, I am perfectly fine with syncing the nextUpdate to = the single use manifest EE not after. I think that the insight today is that this this preferable and it's = what the RFC says. I have done some digging on this.. provided purely so people understand = the background of how current behaviour of CAs came to be. I believe there was earlier discussion even, but the best lead I found = is in a follow-up presentation I did at IETF 87 to change this to allow = a *longer* validity time for the EE certificates. Back then the thinking = was that CAs should have room to specify a soft limit (next update) and = hard limit (EE not after) for manifest validity. There seemed to be = agreement in the room back then (see minutes): https://www.ietf.org/proceedings/87/slides/slides-87-sidr-2.pdf https://www.ietf.org/proceedings/87/minutes/minutes-87-sidr But.. the proposed work on drafts / updates never materialized. Still, as a result of this the behaviour of the RIPE NCC CA (where I = worked at the time) was changed to use 7 days for not-after, and 24 = hours for the next update time. Krill does the same today. All that said, I think today's insight is that even stale manifests = should be rejected (not accepted with warnings), so it makes sense to = align the times. Tim