[Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)

Stephen Kent <stkent@verizon.net> Fri, 08 May 2020 15:36 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 17DFE3A0BDC for <sidrops@ietfa.amsl.com>; Fri, 8 May 2020 08:36:51 -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 1sa8eBVtRxSL for <sidrops@ietfa.amsl.com>; Fri, 8 May 2020 08:36:48 -0700 (PDT)
Received: from sonic315-13.consmr.mail.bf2.yahoo.com (sonic315-13.consmr.mail.bf2.yahoo.com [74.6.134.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 D7F293A0C3E for <sidrops@ietf.org>; Fri, 8 May 2020 08:36:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1588952186; bh=N2diQ0iZpcgE7cpny4RVYvU/Qe240EWn7I/PEFZMnUE=; h=To:From:Subject:Date:References:From:Subject; b=fnmSahI0pYYVKq55KVkFsU/nJ/Kw3UEok3RFJsmLFmogJ98pUVmVXPT2XUTWI/PJ7Uv3rkfvY7rYJ5QDbSVeL6c/RO8RcT/rt1tM4DfIEi6IxuSgnnygXyjxqfi3zO6nwbehy9wYheeTDiSjjvPNXfvTzWc2zagLt3AIyD1vI1rqWV4bmKlHhIfIA23U5FpDlJdiIXwG253hREssRlUgGUzYvgrZdAKaukV+GbYd4cnIPAipmT1nQg05Bqs6IzWxFgmT79JDiKIJfUwHqhN3fhTpsM1FVWZPdHXDvqbZnZ/Vb+/chzbDBXIjZt4m8JyilhxuGw4PknYfbQFIQIY+ew==
X-YMail-OSG: 6nLK_3EVM1nZW0ZW9S1.MlE9gQ6AydDRH9EBos4_Ca.9ZFOI0QG0MfSpGOGhURR l_tOKgLPgY3bWn6sMOK0cFsTlpimpQJSJyezhEA0BdVxcSIuq50jfDq5Uh1mFvj4q5EDxZ70.M8b mp5q3ky9yPqCz2m4ifIpfraD0dTnU66IktiyrHqlbfv3.BQM4iGlaNduwPT_6V.BS.T7umulyaVq 8Dx8eHo2uiu8sDTVlfwGndc.z8rwWomzpW3x5zF5DBbcWkmr_i1fC.b8RqolSjdSX80qAJvhufVk SLx_x5Ge9YT8YdXusok_k7J61TxAgaLl6HyQJ5SDbkIkoc.WYy_.e1ERvCgYbmE79_Q8h340ufLt R2ae73EwPXv_kEsNES2G4P7lIyEYdpKc5ikyE9TEUcUvYseILL1LG7s7RXFvcst18_d29hLvq841 D25IYKRkIYExrpZJUefi0hjuYPpv0WZ0XJv0e1aUkbaFQ8UvYsPqHJlAx_guE238lc5_8ij46ihx RKku3uMwFSMzEPK3cV4weI5qqw70AV0j7M8I4mzoR9kmbwmtIcZsUnhZg4O_QguaoLN1fX9EHhTK .sEyR6pbqMrat6gu3OyFBlCKQujHDhzo30OQdDUJuaCsavNWElJIYaidGNmY6ZjgAuySh1WoegRp 8XwzHbYkgIOc4f2Ubf3g_cAe0FLs1uRIcNf4ymI695VsK25AOC9vN.HKTrBZpjC8VrkLjMKqrpO7 YQKoKpc9g4nU1cRMEF_UPaEKg05.0CzKtwWPqW.ALKZA6uQvNiP3GAye5_B42WZtWMtd4eAMZlWf gzTFtJ9V4npwFjbG.Kee1rjDWcfjJNR8yzlIy81.7wzoQop2FfkmN.vEYEgU5K0lrTEVrtB8UMpc 6fYy2W62FLIO53By650R.oJJDiM80vkqSizraZwyVu2mCVLVV1LX2Tz14v.5MPQO3uN1J1.eOffS k2T9fxGsN5D8znlZXuIK2YY2qL8DGuEM75JixW7fI78OZ9T88HiR39nDw5DqRUY9sc2XXvipZNfZ DsX_WygZmbyps7xAPcBNZ6r0_tt.PrxJ3XibkSV36eTxNyPSq41LnkKJFvXVRAvNe2aZY_He7emu 17T68ttoKVTXQ3A4RYjufoGsajqBqHWlSLYYwlwaQ_SqVlj8wUlcQcJnDnXQT_l6YInI.hf7wUqW K7DCg.vCvwD.Y52l3LMCuSgelxcDDgu4PzM3E.cYIT2taiUl7iP3vTySoTg5B8EAKQPXwLGeDkLm N9CvBJ6HaNnb8A1naq_cNo1VEv9Rpf26s.rBtzRpZh2E9rhs1KnbrMVzcqmjdE2RWr8smwWgemtX 61SgyJ1dz7KBA83R.J54n0SB.w17KGF3DB_QLe8rx8eHzfklPNz4vTSVGW5io3nHQqR_TJx5i3zv ZzviLkzsrvt0ViclmkNvlR5bO
Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Fri, 8 May 2020 15:36:26 +0000
Received: by smtp409.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 4e9a89c6d75e4bfaabdf55619e9f1d1d; Fri, 08 May 2020 15:26:22 +0000 (UTC)
To: "sidrops@ietf.org" <sidrops@ietf.org>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <be9450ba-fe9c-465f-98a2-919772b3b32a@verizon.net>
Date: Fri, 8 May 2020 11:26:22 -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="------------59CB60713A5E16EBECBC2572"
Content-Language: en-US
References: <be9450ba-fe9c-465f-98a2-919772b3b32a.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/04s5QYa_BdVNrfC6TH4Axr7izqs>
Subject: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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 15:36:57 -0000

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.

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. _All_ of 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 the 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 manifest’s EE 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.