[Sidrops] revised section 6, take 2

Stephen Kent <stkent@verizon.net> Thu, 07 May 2020 17:57 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 3E7033A0866 for <sidrops@ietfa.amsl.com>; Thu, 7 May 2020 10:57: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 r5-ihKYKMFpi for <sidrops@ietfa.amsl.com>; Thu, 7 May 2020 10:57:47 -0700 (PDT)
Received: from sonic302-3.consmr.mail.bf2.yahoo.com (sonic302-3.consmr.mail.bf2.yahoo.com [74.6.135.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 BC9AC3A0826 for <sidrops@ietf.org>; Thu, 7 May 2020 10:57:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1588874265; bh=YuxVvvlm3VyYX5a00AIwfNKCcm0BF8GoFkR2MtXYY7U=; h=To:From:Subject:Date:References:From:Subject; b=GmrxqxdCWAW8bxS9PaqWBqZ6etMVxU+mdZE7qwJZUhuDViU3QCVOhqqFIWG7IxYlvcZQBBbAgxAvIpJ6TPtXycCbfL/ysahprZ/FIq64HKX8M5qhePJEGmpZG8EVBeGmKlTOoHIXvsqwdnkRvN/8f/Um9kbLgnPbDFWj0rqmlTlRiN9/ZASQnI3oslyZQXeLb9cBnsAcOoz5CiW6dKXSODd9EkBEBlvHW5xijnQYj0UAfxXh4oOt4REPu9T9MugSJc+PYJ2NX/Cp0qec5pNY9/KxLPuP9C7G4W4EQYZJC/lhR2AcnBzw0oHezvClT9WDUcsXSoS4toDAHmsAQCHdcg==
X-YMail-OSG: o7PBcA0VM1l.wQpg.c2OxW2wtSaPsBRUMnUfgISrfwW1UX6mFrfJf.ZpXkyTgZf J3KwvbnKKvn4OPnCeRojQ0WZMDRo5eYonixtOh5QJpTC2_6YktnkrBD_uIDe2Uh67B1xkQNvBuko sIn19alp7ntTQ2DVFulA3FF5iDJiFOM1VFAB8hmX5r2cv2dzrNk.it12Ltt5fP8MATeT209VIOXq gO3Yon847eqPO9sjwFdt831y4jhq1n4ArzqlIj.VdOBhmNta1GUIHczGilOrJz_r_t3DVsaUBnuJ DJktBrPNAwCoevvjUl.6z7OIXekxwnRL2z2ZSPF0depsAniRcCRJp_J_clgKxEpxZgp7ObO8Yee0 PUm2PaiNDuKSJBEibQhUQ4vaPWASmM6e.gfjYUo4KbtN0rTG5TU0fU5QGOB0CmbO0jFEgkGn40Uy MJmrxF5mQEfd8utOdcWi1DyC.TscRD9Dl3k_FCPJ3k5bZhOGtL_yJBuCYRDz4gkZY79fafeC.Fe9 dn4cfET85iBHFXOu1tFNs5YiFSAjZEmWijFeE_RWNStynaW7wMA6mZhGHtQ3D0EUYfsUW0br3YHN rywnEixde2cjI1f31nkxZ.zMCbT6c3Ox7BMZa2Po.U78Ca5RUgjaLMKrZsiY.4dDpaDorohvE7T9 m1ypv5bRKOdS6hPxNGOyEJJPFdTP8sCcgPuChwbbMs0TPLJFKUqhZTUPi1_CEK6FQSNIpbF7nkVF qGj8hLvzy3dkj5BjhfJKsAjR5eP70dIRtPH9tFRz33yG6x2OwfRYJgSbAbV8uYwN182EQrOW86Q. a9FUY4SUbP829IPl4QHEMKY2YOj4lzZlWQnDHBK8ge426yYaCc9O_QSJgnrcQ9AFOGMmQorreMkn IKPMFYyp7jNHybrc2qr754Fn7HzUlgIJBmNEtyboVLBRBfybTZrQRKUl2HoV8FAozaMLx8ddhXXA 1KvdjFOWsdC0Pf75xPfpnS16RxMWvKkdIZACT93.Mp.ewSieQYFbUx9VXijzaPP.vXRypGTRg5i_ 7cpLJ2xG3byT16Hb0UXdQpUhGHA0dIb0Q4n0zpbKhE2ojSRmvUURyHpMBXeDGL1Lj40zUDffI3p_ JLF8uy4yCPrAJBAV3LGu4ncgqaLHRnspUoCRapISz4tSjpq6wisjD7th4reL_NIeeMvMD6_hUSu9 if5lALf8hHLwngttroOv5sTRuY3HtfP1kzlf1HkZv7LmJW5byr8hPFmGJkQdkM.8Vu6xRT6FUZiE hQZuPfXaE0.QuSCcY_MbqMK44_TasUPzFkRoWovMPTRhdRXfAkj845vsnBzAiXfaxpz5zhDO8651 lxiw5jaAOJuaEr096D9JUDMSqXT0okwvC826MxqC6.eS4AYHh6yXSxmkLgR7K00Ih6wN0zcntZyo WiA--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Thu, 7 May 2020 17:57:45 +0000
Received: by smtp403.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID da1142e519ef353b1b96db1895bb1b24; Thu, 07 May 2020 17:57:40 +0000 (UTC)
To: "sidrops@ietf.org" <sidrops@ietf.org>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <bd1b0611-bbd1-5216-51e9-b10880a34dc4@verizon.net>
Date: Thu, 07 May 2020 13:57:40 -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="------------17FE96969D2EF143C150FCBA"
Content-Language: en-US
References: <bd1b0611-bbd1-5216-51e9-b10880a34dc4.ref@verizon.net>
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/TyvSegYgXlwz3eZUnWzRWinkT1M>
Subject: [Sidrops] revised section 6, take 2
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: Thu, 07 May 2020 17:57:50 -0000

I revised the text at the beginning of Section 6 to omit the notion of 
"local policy". I restructured and renumbered the processing steps to be 
more comprehensive and to focus on replacing missing or damaged files 
from an RP's local cache, where this is sfaely possible. I also noted 
that the CRLDP is the authoritative pointer to the CRL for a CA, and it 
is to be used to locate that CRL. The manifest is used to ensure that 
the RP is seeing the most recent CRL. If duplicate .crl file entries 
appear in the manifest, only the one matching the CRLDP is to be used.

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.

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 filesMUST 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,

processing for this publication point stops and a warning MUST be issued.


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, processing stops and a warning MUST 
be issued.


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 processing

stops and a warning MUST be issued.


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, then processing stops and a warning

MUST be issued. 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.