[Sidrops] once again, with feeling ...
Stephen Kent <stkent@verizon.net> Fri, 08 May 2020 14:38 UTC
Return-Path: <stkent@verizon.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9923A0B1C for <sidrops@ietfa.amsl.com>; Fri, 8 May 2020 07:38:49 -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_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 O3mL37W9PNQM for <sidrops@ietfa.amsl.com>; Fri, 8 May 2020 07:38:47 -0700 (PDT)
Received: from sonic313-13.consmr.mail.bf2.yahoo.com (sonic313-13.consmr.mail.bf2.yahoo.com [74.6.133.123]) (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 A750E3A0B1B for <sidrops@ietf.org>; Fri, 8 May 2020 07:38:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1588948725; bh=huLbNFptYu47oWzejk7egVj/1pZA6bohOKmAPbqP9J4=; h=To:From:Subject:Date:References:From:Subject; b=pfANhyiDWee7rQUFYvOWuq7+mdhWODTHvgI6G2Ee8HeUL0Rh2RwoFzccjRRjkLLRq5heNE0wFrz6FieFzXnhBCOsSbdKkcC3KVmjnwKT3doaasZaKFmPsx1pZTA/V+2uhqVRFmgXFEVkWn+IzqIEbaZlvescr9DK063AaDFsa7UJAuDdfBR6QRU1G9omxEZIdECOJwwQRAEu3nAbgL0OOY11hTCmAYJDLfH5zpnOiN1uhErYWfo7O+L67NyD3P2dpD7JrByC0ackt3riJT6YCRgqZyDkn7jE+45dUTzp3lPDqGjnceKG+4JBfnjXSUOCKHsMB359bwEU7xR/+nj1oA==
X-YMail-OSG: iOMxyfIVM1mTUAWAwfwwT.zvXla6o7YrXAMcotJ59WkL_l2VIzN0xt.zNd7qcfi gn9kdwv_FJ8wn8eYiSqO533cPM0zmqZZFkN4jsDYk_BmCx3VtpgajFEhMKcQTwA.uB5nhpl6rIbq OXQS9cXHtwmXY7ZvGbgOMh.ZUtZEMbgdFS_oxNoQjXSFPWZ1rF2qWvNFTX_IkZI2LdCIUQO1r2SF vW1ONpuxDCb217xnLv4vFzxExGJ48FgZmJdHvYtBEa62S14JfAF6aJLns_EWb6NKHi5WHYN3y8BG wYFlEitCCfvzhajHkMWejZFJUg9QFlw2SDGABbagmCeZFj5zUhRgsoLNxzwXJYEVeFV2AG7iufzn rv82gPrFOHSsgzEIsVZBQwFUv.6nDIWh_7QuRcHiy21rmp8keotRTY57W.bOvJ4wLvgEtkGnWcEn S5mhH_s5Fw8wq06mmMjdh8GNWsCrZkLBfa9y2VDzF_iqpWFQScCS5ICIOfbtRkwHNeNx_oPsaY9T KygPuovW1CbYLCyIQr76VOVCEZbt1FMOpVFB9L5V7E3XgbBYFDG9rX6WUJ_B_gDKPpP7DmoLHgU. vzD1wSEqiPb9aQXoltEjTUdQr9BBuEYFH6_VDDlqL61iYwAF6WjnTraO_go8N1k8w.PGzIKKU6fp 4MoYN4ZgLNuEwJBoh_wp_gXF6DPaAe_UKkmFWCAL7H7UIAVornRSnkPIenSXLzCuvzl.r6cfoRUz rgEOxXPVyGiAWkV.uexmbQLPCtSwmO80URcPz2Bvb_lsEIT34CUYMaN9yduS6WblABi4fObx_Qsp XkhWJSn8WTkqbY5vhEDqJG_5vxENK2Vye1odaL1O7wv0SErPCpIu5ST9xxG7KyoGi25HQ1bVTjmJ q3dsfytRexi1moXZbSqpTpUqJvgoFXy6WumPG_b7oy5qaHelQLA2fcSpvbQzxPzWbZ_G5Z4kjYvj EJ5O8GvxC26ixbW_fU2NYGNL_dgu_cCfXF75pUQu.6lWSRXbeDHK5IAzVajY_UOg4CGFOTSvycCR 3nYrKroDm5fXr6KvKjYzUUzD..lQfZJ5BtkDWHKDre1iwoBcE985S3mgsWmK.3FXLmLsnWCzQVhi ZT5_0t8pb4Nlz1I12O0tHjm3xPr7v2No1zMvqu9eyufmgWFVdCEtE1jjEW5SuMPNsd2CX.iuHdzw SR0RTzixg6_jWnlMUsrKgqfuO4_G7hQxRkEY0o3q3NeVul7acWvQwEUn3Do65K1SIt41FTrF9bup ziuvZ3CYHqzooA7604ZA20HztkhEs7Xc3fE2mU1.Y8SbejB_zE9vpofPh7zy055yJHYkiyQTLPAt KSF1r58oBRiyl0aPETEeuZ7G44hhQht8aWUgp375M5y9T3T_Tzwqa_4E814MLsLzGDloAf4xN4Qz Htk.qRQJwQ4k5wQ6ALPxHaKI7
Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.bf2.yahoo.com with HTTP; Fri, 8 May 2020 14:38:45 +0000
Received: by smtp404.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4ea07566cd5ec84872f2edfe3f2e74bd; Fri, 08 May 2020 14:38:42 +0000 (UTC)
To: "sidrops@ietf.org" <sidrops@ietf.org>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <75d43357-c378-c9f9-3610-84840fca8255@verizon.net>
Date: Fri, 08 May 2020 10:38:41 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------9F5EDA4898811B7F4B18B094"
Content-Language: en-US
References: <75d43357-c378-c9f9-3610-84840fca8255.ref@verizon.net>
X-Mailer: WebService/1.1.15902 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/s1Qi3QhG0u7RJWXoSenRf8B8_sE>
Subject: [Sidrops] once again, with feeling ...
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 May 2020 14:38:50 -0000
I made some more revisions, adding a paragraph to the overview, and a section explaining what I meant by termination of manifest processing. have a good weekend, Steve ----- 6.Relying Party Use of Manifests 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). Manifests are designed to allow an RP to detect manipulation of repository data and/or errors by a CA or repository manager. Unless _all_ of the files enumerated in a manifest can be obtained by an RP (either from a publication point or from a local cache), an RP MUST ignore the data associated with the publication point. This stringent response is needed to prevent an RP from misinterpreting data associated with a publication point, and thus possibly treating invalid routes as valid, or vice versa. The processing described below is designed to cause all RPs with access to the same local cache and RPKI repository data to achieve the same results with regard to validation of RPKI data. However, in operation, different RPs will access repositories at different times, and some RPs may experience local cache failures, so there is no guarantee that all RPs will achieve the same results with regard to validation of RPKI data Note that there is a “chicken and egg” relationship between the manifest and the CRL for a given CA instance. If the EE certificate for the current manifest is revoked, i.e., it appears in the current CRL, then the CA or publication point manager has made a serious error. In this case all signed objects associated with the CA instance MUST be ignored. Similarly, if the CRL is not listed on a valid, current manifest, all signed objects associated with the CA instance MUST be ignored, because the CRL is considered missing. The primary locator for the CRL issued by a CA is the URI contained in the CRLDP contained in the CA’s certificate. An RP MUST use this URI to retrieve the CRL and use that CRL to determine if the EE certificate in the manifest is revoked. The manifest provides an RP with a means to verify that the CRL at the indication location is current. 6.1. Manifest Processing Overview For a given publication point, an RP MUST perform a series of tests to determine which signed object files at the publication point are acceptable. The tests described below are to be performed using the manifest identified by the id-ad-rpkiManifest URI extracted from a CA certificate’s SIA. The files referenced by the manifest MUST be be located at the publication point specified by the id-ad-caRepository URI from the (same) certificate’s SIA. If the manifest and files it references do not reside at the same publication point, an RP MUST *???* ** A manifest SHOULD contain exactly one CRL (.crl) file and it MUST be at the location specified in the CRLDP in the CA certificate. If more than one .crl file appears in the manifest, only file names matching the CRL specified by the CRLDP will be processed. If more than one .crl entry appears in the manifest, and matches the CRLDP, the first one encountered MUST be used. Any other .crl files MUST be ignored and a warning MUST be issued. Note that, during CA key rollover [RFC6489], signed objects for two or more different CA instances will appear at the same publication point. Manifest processing is to be performed separately for each CA instance, guided by the SIA id-ad-rpkiManifest URI in each CA certificate. Note also that the processing described here will be performed using locally cached files if an RP does not detect newer versions of the files in the RPKI repository system. 6.2 Acquiring a Manifest for a CA Acquire the manifest identified by the SIA id-ad-rpkiManifest URI in the CA certificate. If an RP cannot retrieve a manifest using this URI, or if the manifest is not valid (Section 4.4), an RP SHOULD examine the most recent, cached manifest matching this URI. If that manifest is current (Section 4.4) proceed to 6.3. If the publication point does not contain a valid manifest, and the cached manifest is not current, proceed to 6.7. 6.3 Detecting Stale and or Prematurely-issued Manifests Check that the current time (translated to UTC) is between thisUpdate and nextUpdate. If the current time lies within this interval, proceed to 6.4. If the current time is earlier than thisUpdate, the CA has made an error. If the RP cache contains a current manifest, use that manifest instead and issue a warning. If an RP has no access to a current manifest, processing stops and a warning MUST be issued. If the current time is later than nextUpdate, then the manifest is stale. If the RP cache contains a current manifest, use that manifest instead and issue a warning. If no current manifest is available, proceed to 6.7. 6.4 Acquiring Files Referenced by a Manifest Acquire all files enumerated in the manifest (fileList) from the publication point. This includes the CRL, each object containing an EE certificate issued by the C, and all subordinate CA and EE certificates. If there are files listed in the manifest that cannot be retrieved from the publication point, or if they fail the validity tests specified in [RFC6488], the RP SHOULD examine its cache to determine if these files are available locally. If _all_ of the missing/invalid files are available from the RP’s cache, i.e., each file name matches the list extracted from the manifest, the RP SHOULD use the cached files to replace those missing from the publication point, and proceed to 6.5. However, if _any_ of the missing/invalid files cannot be replaced in this fashion, then proceed to 6.7. 6.5 Matching File Names and Hashes Verify that the hash value of every file listed in the manifest matches the value obtained by hashing the file acquired from the publication point or local cache. If the computed hash value of a file listed on the manifest does not match the hash value contained in the manifest, then an RP SHOULD examine its local cache to determine if the same file is available. The RP SHOULD use cached files to replace any (damaged) downloaded files, so long as the hash of the cached file matches the hash from the manifest. If _any_ of the files with hash mismatches cannot be replaced in this fashion, proceed to 6.7. Otherwise proceed to 6.6. 6.6 Out of Scope Manifest Entries If a current manifest contains entries for objects that are not within the scope of the manifest (Section 2), then the out-of-scope entries MUST be disregarded. 6.7 Termination of Processing If an RP cannot acquire a current, valid manifest, or acquire current, valid instances of all of the objects enumerated in a current valid manifest, then processing of the signed objects associated with the CA has failed. The RP MUST issue a warning indicating the reason(s) for termination of processing with regard to this CA. Termination or processing means that all of the ROAs and subordinate certificates (CA and EE) MUST be considered invalid. This implies that the RP MUST not try to acquire and validate _subordinate_ signed objects, until the next interval when the RP is scheduled to process data for this part of the RPKI repository system.
- [Sidrops] once again, with feeling ... Stephen Kent
- Re: [Sidrops] once again, with feeling ... Tim Bruijnzeels
- Re: [Sidrops] once again, with feeling ... Stephen Kent