I would suggest that you allow multiple CAs to publish to your publication server/repository. This will allow operators to create child CAs in krill (or other CAs) and assign prefixes from the parent CA to these child CAs. The child CAs can then be assigned to various business units within an organization. Each business unit can then be responsible for the generation/maintenance of their own ROAs. Also, I suggest that the industry standardize on a term used for this service. I am partial to the term “hybrid” which ARIN and others are using. The three options being hosted, delegated, and hybrid. “Publish in Parent” seems like a mouthful. Maybe we can compress it to “PiP”? 😊
-Rich From: routing-wg <[email protected]> on behalf of Felipe Victolla Silveira <[email protected]> Date: Thursday, September 29, 2022 at 8:15 AM To: "[email protected]" <[email protected]> Subject: [EXTERNAL] [routing-wg] Publish in Parent - input requested CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance. Dear all, As some of you are aware, the RIPE NCC has been working on a new service for RPKI, called Publish in Parent. This service is intended for RPKI users who have chosen to run their own Certificate Authority (delegated RPKI) but don’t want to take the burden of maintaining a highly available publication point. By using this service, it will be possible for our members with delegated RPKI to publish their signed RPKI objects in the RIPE NCC repositories (RRDP and rsync) instead of maintaining their own. Following a discussion with the Executive Board in our meeting last June, we would like to ask our community for input on the requirements for this service. The service was originally designed to allow all objects to be published in our repositories, regardless of whether the associated resources are part of the RIPE NCC or another RIR, and this is how we would like to proceed. However, it has been argued that there should be a restriction in this service so that it allows only RIPE NCC resources to be published and not resources belonging to a different RIR. If you are potential user of this service, what are your expectations for its functionality? Do you want to be able to publish all your objects in RIPE NCC repositories, regardless of whether they are from the RIPE NCC or not? Or will you publish each object in the corresponding RIR repositories? Please note that we are only talking about publication. The objects out of region will be signed with their own parent certificate. If you are a developer of one of the Relying Party softwares, will the presence or absence of such a restriction impact your software package in any way? Do you expect the need to make changes, depending on the direction this takes? To make informed decisions on how we should progress with Publish in Parent, we need input from potential users of the service. Please reply with your feedback until 14 October so we can incorporate it in our planning and inform you about our progress at RIPE 85. Kind regards, Felipe Victolla Silveira Chief Operations Officer RIPE NCC E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.
-- To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/routing-wg
