A BPKI key rollover protocol for the Resource Public Key Infrastructure (RPKI)

Internet-Draft	RPKI BPKI Rollover	July 2024
Misell	Expires 9 January 2025	[Page]

Abstract

This document extends the RPKI setup protocol to allow the server and client to update their Trust Anchor CA keys in-band.¶

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 9 January 2025.¶

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

1. Introduction

The RPKI setup protocol specified in [RFC8183] does not specify a mechanism for key rollover of the CA keys exchanged during the setup process. This document extends [RFC6492] and [RFC8181] to allow both the server and client to update their TA CA keys in-band.¶

1.1. Requirements Language

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [BCP14] when, and only when, they appear in all capitals, as shown here.¶

2. Protocol specification

2.1. Protocol negotiation

This document does not define a method to negotiate usage of these new extensions. It is up to operators to use out-of-band mechanisms to agree on support for this document.¶

2.2. XML Namespace

All new XML elements defined in this document belong to the namespace of https://as207960.net/spec/rpki/setup-update/. This document uses the XML namespace prefix of setup_update however compliant implementations MUST accept other namespace prefixes.¶

2.3. New message types

The type field of the message element in the http://www.apnic.net/specs/rescerts/up-down/ namespace, and the type field of the msg element in the http://www.hactrn.net/uris/rpki/publication-spec/ namespace are extended with the following new values:¶

update_client_certificate¶
updated_client_certificate_accepted¶
request_updated_server_certificate¶
updated_server_certificate¶
accept_updated_server_certificate¶

The messages for these extensions are defined below.¶

2.3.1. The `update_client_certificate` message

The value of the message type element for this request is:¶

                        type="update_client_certificate"

Payload:¶

<setup_update:new_child_bpki_ta xmnls:setup_update="https://as207960.net/spec/rpki/setup-update/">
  [New child TA CA]
</setup_update:new_child_bpki_ta>

The child CA MUST be encoded as specified in [RFC8183]¶

This command directs the server to update its stored TA for the client. The server MUST update its stored certificate or respond with a Request-Not-Performed Response. If the client receives a Request-Not-Performed Response it MUST continue to use its old TA.¶

2.3.2. The `updated_client_certificate_accepted` message

The value of the message type element for this request is:¶

                        type="updated_client_certificate_accepted"

This message has no payload.¶

Receipt of this message by a client in response to an update_client_certificate message indicates the server has accepted the client's new TA and that the client MUST use its new TA in all future exchanges.¶

2.3.3. The `request_updated_server_certificate` message

The value of the message type element for this request is:¶

                        type="request_updated_server_certificate"

This message has no payload.¶

This message indicates a request from the client to the server for the server's new TA CA, if available. Servers MUST respond with an updated_server_certificate unless an internal error occurred.¶

Clients SHOULD send this message periodically to check for a new TA from the parent.¶

2.3.4. The `updated_server_certificate` message

The value of the message type element for this request is:¶

                        type="updated_server_certificate"

Payload:¶

<setup_update:new_parent_bpki_ta xmnls:setup_update="https://as207960.net/spec/rpki/setup-update/">
  [New parent TA CA]
</setup_update:new_parent_bpki_ta>

OR¶

<setup_update:no_new_parent_bpki_ta xmnls:setup_update="https://as207960.net/spec/rpki/setup-update/"/>

The parent CA MUST be encoded as specified in [RFC8183]¶

This response either includes the parents new TA if one is available, or a statement that the parent doesn't have a new TA it wishes to communicate to its client.¶

2.3.5. The "accept_updated_server_certificate" message

The value of the message "type" element for this request is:¶

                        type="accept_updated_server_certificate"

This message has no payload.¶

This message indicates that the client has accepted the server's new TA. Future exchanges MUST use the parent's new TA.¶

2.4. End Entity Certificates for updating the Trust Anchor

Each CMS message in [RFC6492] and [RFC8181] must be signed by an EE certificate. Due to the sensitive nature of updating the TA a standard EE cannot be used to update the TA and ensure sufficient security.¶

The EE certificate used to sign a CMS message containing a message relating to a TA MUST include an rpkiBpkiTAUpdate X.509 extendedKeyUsage. If a client or a server receives a message relating to TAs not including this EKU it MUST reject the message.¶

The rpkiBpkiTAUpdate has the OID of 1.3.6.1.4.1.56292.1.2.1¶

2.5. Error codes

The [RFC6492] error codes are extended with the following additional codes:¶

1401: The new TA presented by the child wasn't acceptable to the server, the reasons SHOULD be elaborated in the "description" element.¶

The [RFC8181] error codes are extended with the following additional codes:¶

unacceptable_child_ca: The new TA presented by the child wasn't acceptable to the server, the reasons SHOULD be elaborated in the "error_text" element.¶

3. References

3.1. Normative References

[BCP14]: Best Current Practice 14, <https://www.rfc-editor.org/info/bcp14>.
At the time of writing, this BCP comprises the following:

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC6492]: Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A Protocol for Provisioning Resource Certificates", RFC 6492, DOI 10.17487/RFC6492, February 2012, <https://www.rfc-editor.org/info/rfc6492>.
[RFC8181]: Weiler, S., Sonalker, A., and R. Austein, "A Publication Protocol for the Resource Public Key Infrastructure (RPKI)", RFC 8181, DOI 10.17487/RFC8181, July 2017, <https://www.rfc-editor.org/info/rfc8181>.
[RFC8183]: Austein, R., "An Out-of-Band Setup Protocol for Resource Public Key Infrastructure (RPKI) Production Services", RFC 8183, DOI 10.17487/RFC8183, July 2017, <https://www.rfc-editor.org/info/rfc8183>.

Author's Address

Q Misell

AS207960 Cyfyngedig

13 Pen-y-lan Terrace

Caerdydd

CF23 9EU

United Kingdom

Email: q@as207960.net, q@magicalcodewit.ch

URI: https://magicalcodewit.ch