Re: [Sidrops] trying to limit RP processing variability

Stephen Kent <stkent@verizon.net> Tue, 05 May 2020 15:49 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 2ABBE3A0817 for <sidrops@ietfa.amsl.com>; Tue, 5 May 2020 08:49:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level:
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 7yaqJTxCg83M for <sidrops@ietfa.amsl.com>; Tue, 5 May 2020 08:49:15 -0700 (PDT)
Received: from sonic303-2.consmr.mail.bf2.yahoo.com (sonic303-2.consmr.mail.bf2.yahoo.com [74.6.131.41]) (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 521983A082F for <sidrops@ietf.org>; Tue, 5 May 2020 08:49:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1588693754; bh=8Lz/kdGl/0BSSVDXE1anjU3irBCZT/1ywwKWfVsnmOc=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=nSCXw+Y9IFHQ14kYkcXKGaq1MEwYBzkJ6qNpW5zcLDtcWT5pbrz87KMRXKT/749LeO4Q/UxtLOBY/kWPSTCyyUEeoil4ActeNJQHGQGnRpDcNrB/mqXXd73HOwGdHaj79w0xJ2+ImCGHX7XmeGyB5RHVSbCtZ1C1Id5/PkRu10ZdRMUuVK6ZexB7KH6q9oA2KrvY93vP1IEAaMaA1neLHf31wotIF76wLP6F+ucqHheE1oO6pRUWtSp/2FEly+ZRokaFDzqIwJwFhaOIASKBjgKoqh9JTSrOdSuLxc0qmZoFQijazZ1DgT0eNMPnRbtRCFZ1+EoZ9UDW3NIQBqH4+A==
X-YMail-OSG: sqy5Wf8VM1nuepXqPGhp5HgaGfN_B9NPU6w46EKP3DEvLMnKZaDqB5F7QwMTyIJ pNLu_uur9P0f3nQrZorB5jhbqDt8w3lXqgEKAp7eIoO9IatuKD.yroBt.0zbMmaKshuRhyksfXR8 fmQqwTuNFn9ohEntk0ropBLBj5S517Jry2r_7sUPpBq5YETgyIxNRVfkcoXuWxuBWmmMNH8SbZ9l DEHlU04zLp6KfHzVVVe5R0Rjc1UQYtezCq5Te0r3jcR6TC3s2HMB.AOkWaC7SyNuTLmMKJU0YSYy LrrITea42arxsJTU5ua0voMWqfrobkcuWyyFpl1FbzjslP3QMc_ra.41iFWyf6rtrVPqbMNEADOd NLGTqw4IWhMnarKurs16jAtCOjjRRCaqNE8iOv4BD3kMBx.rR3gHETnrotRbTMqQeQaKZgE0Zt.1 DvLXkcAEPBhppId1b2Eg81inUSZdBrgvvd8XK_y8FaOpirFa0mDQ.Oz1Sm1zxC4DJKhx3snP2yEp bOSVvfsd_idHn1edvX3565efqNc4RDrjGFjaGASh1qrPWdaZkrMBC0oL9YYZq0YhNHCiPVE7jXX6 qHgEDPtos7a3aYck288PHcsGCq.t_4hvSDH8r7HF5PPF54s1WrCRK.n7.IOW9382S0LIR5OT15Bt IuF0bhjD1.0GcCKfaMypD.IaRCyXJakaM7.lELtD.vOpO3basPbH.LloQh08yUxaoQVS_BsiuS5d cD1jaRn6fGEoolcFStL_yAOFaOZik656M1ZH6JOlF1b4_LHiXO_ZgQ6.iCBIlD4kIev9UphVkh18 1ucOazS_YFncl8vxMDlsYn.VUfL.tUwWkOUnXrvmkODjSqIddOn5Wr8Kz8o_f9V_nmp.0VMEquQp v8_t_G_6HpzG5NYws6HQROBhBRJOkYA352l0Iv6KfHH1AyTTGQlslPe90Ki_N.UHu0vbq9rh.3Dl pqwME5Sibzn.bsN7FlVtIUv5nXvcau7CX12TcWxFp1J0z_vt_igKpbvfk0NIsTFNkufd8FEXyJ_C wb3utMqI8rzzIqG2as76pu.UyDKCA0Mq1V0GhJqTIHSmXYFY7lQVbfXDkSoUD5YDdVbdZnkP1FJw .W8MX2CQWpGvwxCi.R_5kRMNLW776E0x3WbT0f0gD3lA0HlK9Pp1CAszg8Ydjo1_t4tvawXVgQ6f oojiowDo4ZLfUIMkoTXi9C71MeBOy7icBO2yCKjK5Mu9Mi6b5wFBpr_yRpjwehMto3Ue4pbjLmZj oKyIOsIa2UtwqYsMXL1EA7qA_L9zO7WQyYtBjsOvAQM9U3UKhZVOMXVS809d8MuNIamc2qsB3yQT 3jgOnzm16qA0FtdmQPCgnpagMJ4oe3D_pYav_8dFLy228f.l5xruKB2fL4fhqEOhM969By5sM47g VRDgta8B17AORLYZ_Dk9g1A--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Tue, 5 May 2020 15:49:14 +0000
Received: by smtp427.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e332219c6e2483285e558ff6fc0e39c8; Tue, 05 May 2020 15:49:08 +0000 (UTC)
To: sidrops@ietf.org
References: <a9448e54-320f-300c-d4f9-d01aca2b6ef4.ref@verizon.net> <a9448e54-320f-300c-d4f9-d01aca2b6ef4@verizon.net> <63c18696-fe3b-c66f-d8ae-fb132f78ee9f@ripe.net> <a0067385-adb8-cadd-3a7f-3a362176d265@verizon.net> <e3bcba98-c664-0c27-850f-137251cc314a@ripe.net> <a1c7b748-6dda-c555-0ab7-3727d34bc672@verizon.net> <20200415124611.7af291b1@glaurung.nlnetlabs.nl> <974eeeaa-32e6-45b2-860f-6b1408ae14e6@www.fastmail.com> <24215.11555.329412.270610@oz.mt.att.com> <20200505113647.GA93200@vurt.meerval.net>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <90271ae6-0295-9c8d-514c-ea59ec4c9850@verizon.net>
Date: Tue, 5 May 2020 11:49:08 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200505113647.GA93200@vurt.meerval.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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/IdxUwc897gSM9X6r7CTRu8IN8PE>
Subject: Re: [Sidrops] trying to limit RP processing variability
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: Tue, 05 May 2020 15:49:18 -0000

Job,
> ...
> I think I was wrong to agree here. I had discussions with some people
> about 'where does the publication point exist?' - is it a remote entity?
> or is a local construction of pulled data? I'm now leaning more towards
> an interpretation that the publication point only exists in the mind of
> the RP.

4.2 of RFC 6480 says:

    For every certificate in the PKI, there will be a corresponding file
    system directory in the repository that is the authoritative
    publication point for all objects (certificates, CRLs, ROAs, and
    manifests) verifiable via this certificate.

It goes on to note that the publication point is identified by the SIA 
(URI) in a CA cert.

4.8.8 of RFC 6487  reiterates this characterization of a pub point being 
identified by the SIA in a CA cert.

So, I believe that a pub point is a location in the repository system 
where a CA publishes signed objects.

I'm not commenting on the rest of your analysis, just this definition.

Steve