Network Working Group T. Bruijnzeels Internet-Draft NLnet Labs Intended status: Standards Track 24 October 2022 Expires: 27 April 2023 RPKI Publication Protocol Version 2 draft-timbru-sidrops-rpki-publication-v2-00 Abstract The RPKI Publication Protocol first described in RFC 8181 has worked very well. That said, as it turns out, there are a number of requirements emerging from operational experience which cannot be supported by the current protocol. In particular, identity key roll overs, support for publication quota and stricter verification of content by the server. This document is an early write-up with the following goals: (1) support discussions about requirements for additional work and (2) explore a possible version 2 with solutions to meet those requirements. 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 27 April 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Bruijnzeels Expires 27 April 2023 [Page 1] Internet-Draft Publication Protocol V2 October 2022 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. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Naming Conventions in this Document . . . . . . . . . . . . . 4 3.1. Publisher . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. Server . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4. Reply . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.5. V1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.6. V2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Version Negotiation . . . . . . . . . . . . . . . . 4 5. Protocol Message Specification . . . . . . . . . . . . . . . 5 5.1. eContent . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. eContentType . . . . . . . . . . . . . . . . . . . . . . 7 5.3. EE Certificate and Timing Parameters . . . . . . . . . . 7 5.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 7 5.4.1. Publisher to Server . . . . . . . . . . . . . . . . . 7 5.4.2. Server to Publisher . . . . . . . . . . . . . . . . . 7 6. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . 8 6.1. General Replies . . . . . . . . . . . . . . . . . . . . . 8 6.1.1. Rate Limit Reply . . . . . . . . . . . . . . . . . . 8 6.1.2. Unknown Publisher Reply . . . . . . . . . . . . . . . 8 6.1.3. Bad Request Reply . . . . . . . . . . . . . . . . . . 9 6.1.4. Server Error 5xx Responses . . . . . . . . . . . . . 10 6.1.5. General Server Error Reply . . . . . . . . . . . . . 10 6.1.6. Ok Reply . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Repository Info Exchange . . . . . . . . . . . . . . . . 11 6.2.1. Repository Info Query . . . . . . . . . . . . . . . . 11 6.2.2. Repository Info Reply . . . . . . . . . . . . . . . . 11 6.3. Status Exchange . . . . . . . . . . . . . . . . . . . . . 14 6.3.1. Status Query . . . . . . . . . . . . . . . . . . . . 14 6.3.2. Status Reply . . . . . . . . . . . . . . . . . . . . 14 6.3.3. NewBpkiTaCert . . . . . . . . . . . . . . . . . . . . 16 6.4. Publication Exchange . . . . . . . . . . . . . . . . . . 16 6.4.1. Publication Query . . . . . . . . . . . . . . . . . . 17 6.4.2. Publication Ok Reply . . . . . . . . . . . . . . . . 17 6.4.3. Publication Warning Reply . . . . . . . . . . . . . . 17 6.4.4. Publication Error Reply . . . . . . . . . . . . . . . 18 6.5. Server Key Accepted Exchange . . . . . . . . . . . . . . 19 6.5.1. Server Key Accepted Query . . . . . . . . . . . . . . 19 6.5.2. Server Key Accepted Ok Reply . . . . . . . . . . . . 20 Bruijnzeels Expires 27 April 2023 [Page 2] Internet-Draft Publication Protocol V2 October 2022 6.5.3. Server Key Accepted Error Reply . . . . . . . . . . . 20 6.6. Publisher Key Change Exchange . . . . . . . . . . . . . . 20 6.6.1. Publisher Key Change Query . . . . . . . . . . . . . 20 6.6.2. Publisher Key Change Ok Reply . . . . . . . . . . . . 21 6.6.3. Publisher Key Change Error Reply . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 10. Normative References . . . . . . . . . . . . . . . . . . . . 21 11. Informative References . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Requirements notation 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Introduction The RPKI Publication Protocol first described in RFC 8181 has worked very well. At the time of this writing, there are at least four completely independent interoperable software implementations, and over 50 separate deployments. At least one server deployment has well over 1000 remote publishers communicating to it using the RFC 8181 protocol. That said, as it turns out, there are a number of requirements emerging from operational experience which cannot be supported by the current protocol. In particular, identity key roll overs, support for publication quota and stricter verification of content by the server. This document is an early write-up with the following goals: (1) support discussions about requirements for additional work and (2) explore a possible version 2 with solutions to meet those requirements. Bruijnzeels Expires 27 April 2023 [Page 3] Internet-Draft Publication Protocol V2 October 2022 It should be noted that a key feature in the possible solution discussed in this document is the support for seamless version negotiations between publishers (RPKI Certification Authorities) and the RPKI Publication Server. Any version 2 capable publisher will simply continue to use version 1 (RFC 8181) if the Publication Server is not capable to do version 2, and vice versa, version 2 capable servers will simply continue to use version 1 for version 2 non- capable publishers. This is important because it allows for incremental deployment of this new version without the need for centralised coordination on upgrades. 3. Naming Conventions in this Document 3.1. Publisher An RPKI Certification Authority which implements the client side of the protocol defined in this document - i.e. it uses a 'server' to publish its RPKI content. 3.2. Query A request sent by a Publisher. 3.3. Server An RPKI Publication Server that implements the server side of the protocol defined in this document. 3.4. Reply A reply returned by the Server in response to a Query sent by a Publisher. 3.5. V1 The RPKI Publication Protocol as defined in [RFC8181]. 3.6. V2 The RPKI Publication Protocol version 2 defined in this document. 4. Protocol Version Negotiation Publishers and servers can negotiate whether to use V1 or V2 without requiring either party to implement V2. This is important because it allows for incremental deployment of V2 without the need for centralised coordination. Bruijnzeels Expires 27 April 2023 [Page 4] Internet-Draft Publication Protocol V2 October 2022 For this reason all V2 capable Publishers and Servers SHOULD also support V1. An exception can be made if the Publisher and Server have prior knowledge that both support V2, in which case this protocol version negotiation is not applicable. Given that Publishers contact the Server in V1 over an HTTP based client- server protocol, we can leverage HTTP "Accept" and "Content- Type" headers to support version negotiation. The Publisher MUST use V1 queries as long as the Server is not known to be V2 capable. The publisher SHOULD initiate version negotiation whenever it sends any V1 query by including the following additional HTTP header: Accept: application/rpki-publication, application/rpki-publication-v2 If the Server is not V2 capable then it can ignore this header and respond with the normal applicable V1 reply which will include a Content-Type header with the value "application/rpki-publication". If the server supports V2 then it MUST respond with a V2 "Repository Info Reply" and use a Content-Type header with the value "application/rpki-publication-v2", instead of performing any action that would normally be done in response to the V1 query. The Publisher MUST then proceed to use V2 for subsequent queries using the (possibly new) service URI in that reply. In case a server receives a V2 request, and for some reason it no longer supports V2, then it may be expected according to [RFC8181] that a V1 is returned and the content type "application/rpki-publication" is used in the response. If the Publisher gets the V1 content type "application/rpki- publication" in response to any V2 request that it sent, then it MUST fall back to using using the V1 protocol. But, it MAY continue to initiate protocol version negotiation as described above in future requests. 5. Protocol Message Specification The publication protocol uses a simple request/response interaction over HTTPS. We will refer to requests sent by the publisher as 'queries', and we will refer to responses returned by the server as 'replies'. All queries and replies MUST use the Content-Type header. The value of this header MUST be: Bruijnzeels Expires 27 April 2023 [Page 5] Internet-Draft Publication Protocol V2 October 2022 application/rpki-publication-v2 Queries and replies are RPKI Publication Protocol Version 2 Messages, which are signed Cryptographic Message Syntax (CMS) messages. The CMS encapsulation is similar to the definition in V1 (section 2 of [RFC8181]), and almost identical to that used in Section 3.1 of [RFC6492], with the following notable differences. 5.1. eContent A key difference with the eContent specification from Section 3.1.1.3.2 of [RFC6492] is that we will use DER encoded content here, rather than the XML message content that is used in [RFC6492] and [RFC8181]. Note that one of the reasons for preferring DER over XML is that it will allow for more concise messages. For example V1 uses base64 encoded (DER) objects wrapped in XML for publication queries. This is rather wasteful. Another reason is that we may benefit from formal ASN.1 notations, rather than XML schema definitions. While ASN.1 may not be very widely known in general, implementing Publishers and Servers are already required to understand and deal with ASN.1 and DER in many other parts of this protocol, and the RPKI standards in general, so using it here does not seem to place a huge additional burden. On the other hand, it is understood that the threshold to implement may be lower if XML is used as it will require fewer changes in existing code. So, this idea is not cast in stone. eContent ::= SEQUENCE { nonce UUID, MessageType MessageType, MessageContent [0] EXPLICIT OCTET STRING OPTIONAL, } UUID ::= OCTET STRING (SIZE(16)) -- constrained to a UUID MessageType ::= PrintableString (SIZE (1..32)) MessageContent ::= OCTET STRING -- constrained to DER encoded message type -- specific content - specified in the relevant -- sections of this document. Bruijnzeels Expires 27 April 2023 [Page 6] Internet-Draft Publication Protocol V2 October 2022 Note that each query and response type defined in this document will specify its own MessageType value and MessageContent definition. 5.2. eContentType Because we no longer use XML based eContent, we will also use a new eContentType OID, rather the value defined in Section 3.1.1.3.1 of [RFC6492]. The eContentType for the RPKI Publication Protocol Version 2 Message object is defined as "To be determined", and has numerical value of "To be determined". TODO: Request OID from IANA. 5.3. EE Certificate and Timing Parameters Single use EE certificates MUST be used in the CMS wrapper. Each EE certificate MUST use a new unique key-pair. As specified in [RFC6492] either the signing-time attribute, or binary-signing-time attribute, or both attributes MUST be present. Their values MUST represent the actual time of signing the CMS. The EE certificate SHOULD use a 'notBefore' time that is set to 5 minutes before the signing time, and a 'notAfter' time that is set to 5 minutes after the signing time. The reason for this is there may be a small amount of clock skew between a publisher and server, and because the protocol messages are generated moments before they are sent, small time differences could lead to rejection of all messages. Note that this protocol uses additional measures to protect against replays. 5.4. Replay Protection 5.4.1. Publisher to Server The publisher MUST generate a new unique UUID that will be used as the nonce value for any query that it sends to the server. The server MUST keep track of received nonce values for all received queries for which the EE certificate is not yet expired, and the server MUST reject any query that is found to re-use any such existing nonce. 5.4.2. Server to Publisher The server MUST use the nonce value from the applicable query whenever it generates a reply for that query. The publisher MUST verify that the nonce is any reply matches the query that they sent, and MUST reject the reply if this is not the case. Bruijnzeels Expires 27 April 2023 [Page 7] Internet-Draft Publication Protocol V2 October 2022 6. Protocol Exchanges All protocol exchanges are initiated by the Publisher. In a typical exchange the Publisher sends a specific type of Query and then gets a matching Reply from the Server in response. 6.1. General Replies There are a number of generic replies that the server could return in response to a query: 6.1.1. Rate Limit Reply The server MAY enforce a rate limit on publisher connections. If the server does this, then it SHOULD enforce rate limits on a per publisher basis in order to avoid that a bad actor publisher can impact other publishers. Furthermore, if a rate limit is used then it MUST be included in the Status Reply to publishers. One of the main motivations for rate limiting publisher connections is to protect the server from resource exhaustion because of publisher query parsing and validation, and generating and signing replies. For this reason the rate limit response will use a plain "429 Too Many Requests" response (section 4 of [RFC6585]) in case the rate limit threshold is set. If a rate limit response is sent then the query MUST NOT be processed by the server. When a publisher encounters a rate limit response, then it MUST NOT try to contact the server again for at least the last known rate limit period received in a status reply, or 5 minutes if no such limit is known to the publisher. 6.1.2. Unknown Publisher Reply The server SHOULD return a '404 Not Found' response ([RFC9110]) if a publisher is not known. Note that all publishers SHOULD each get a unique unguessable service URI in their initial [RFC8183] response so that the server can efficiently determine that a publisher is unknown. Strictly speaking it is possible to guess which publisher sent a message by looking at the Authority Key Identifier of the embedded EE certificate in a query message CMS wrapper, but doing so would be extremely inefficient and leave the server vulnerable to denial of service attacks. Bruijnzeels Expires 27 April 2023 [Page 8] Internet-Draft Publication Protocol V2 October 2022 6.1.3. Bad Request Reply This type of Reply is used in case of general issues with the request that was sent, rather than the content of the query in the request CMS. The server SHOULD return a '400 Bad Request' response ([RFC9110]) in case the protocol message could not be parsed or validated. The message body MAY contain a clear text hint as a courtesy to the publisher. The message MUST NOT be longer 128 characters, SHOULD use visible 7-bit ASCII characters, and SHOULD be written in english. Theoretically, we could have the server return detailed and signed error replies. However, this (signing) would cause load on the server and could be abused as an attack vector, and on top of that detailed errors could aid malicious attackers. The following fairly minimal message bodies are RECOMMENDED for error conditions: +===================+===========================================+ | message | explanation | +===================+===========================================+ | "invalid syntax" | Message could not be parsed | +-------------------+-------------------------------------------+ | "replay detected" | Message may be valid, but was seen before | +-------------------+-------------------------------------------+ | "key unknown" | Message EE AKI does not match key for | | | publisher | +-------------------+-------------------------------------------+ | "not yet valid" | Message EE not-before is after now | +-------------------+-------------------------------------------+ | "expired" | Message EE not-after is before now | +-------------------+-------------------------------------------+ | "message invalid" | Message validation failed for some other | | | reason | +-------------------+-------------------------------------------+ Table 1 Publishers SHOULD log any Bad Request Response in a way that would be visible to the operators of the publisher, because in many cases manual intervention will be required to resolve the issue. Bruijnzeels Expires 27 April 2023 [Page 9] Internet-Draft Publication Protocol V2 October 2022 If the error is caused by "message key unknown" then this is indicative of an issue where the publisher and server are out-of-sync with regards to the BPKI TA key pair used by the publisher. In this case the operator of the publisher should try to re-exchanges [RFC8183] XML with the server. Other errors are most likely caused by clock skew, or a bug on either the publisher or server side. Because the issue could be on the server side and be fixed there, the publisher SHOULD keep retrying to contact the server albeit with the same timing constrains as mentioned in relation to Rate Limit Responses. 6.1.4. Server Error 5xx Responses The server SHOULD NOT return any 5xx type HTTP error responses. However, this kind of response can occur as a result of an unrecoverable error at the server. Publishers SHOULD treat any 5xx responses they encounter as though they were Rate Limit Responses, but it is RECOMMENDED that they are logged in order to help debugging should they persist. 6.1.5. General Server Error Reply Note that exchanges define their own typed error replies where applicable. That said, the server SHOULD return a General Server Error Reply in case it encountered some unexpected error that it could recover from. Publisher MUST treat this type of reply similar to a 5xx response. 6.1.5.1. MessageType The MessageType for this query is: "general-server-error" 6.1.5.2. MessageContent This response MAY include a human readable, preferably english, error message directed at operators. Note that the publisher software can only log this information, but it cannot take any specific action based on the content. MessageContent ::= PrintableString(SIZE (0..127)) Bruijnzeels Expires 27 April 2023 [Page 10] Internet-Draft Publication Protocol V2 October 2022 6.1.6. Ok Reply The Ok Reply is used in some exchanges where the server wants to inform the publisher that their query was successfully processed, but there is no additional information to include in the response. 6.1.6.1. MessageType The MessageType for this query is: "ok-reply" 6.1.6.2. MessageContent There is no content to include for this reply. 6.2. Repository Info Exchange The reply of this exchange is used in protocol version negotiation and serves to inform the Publisher about the possibly new service URI that it should use for V2, as well as further applicable constrains. The Publisher MAY initiate a new repository info exchange later, but the response SHOULD NOT change over time, with the possible exception of the value of "SupportedTypes". (perhaps that means that does not belong here) Publisher ---- Repository Info Query -----> Server <--- Repository Info Reply ------ 6.2.1. Repository Info Query The MessageType for this query is "repository-info-query", and the MessageContent is omitted. 6.2.2. Repository Info Reply The MessageType for this reply is "repository-info-reply", and the MessageContent is as follows: Bruijnzeels Expires 27 April 2023 [Page 11] Internet-Draft Publication Protocol V2 October 2022 MessageContent ::= SEQUENCE { ServiceUri [0] ServiceUri, RsyncModuleUri [1] RsyncModuleUri, BasePath [2] BasePath, RrdpNotifyUri [3] RrdpNotifyUri OPTIONAL, SupportedTypes [4] SupportedTypes OPTIONAL, } HttpsUri ::= IA5String -- Constrained to an HTTPS URI BasePath ::= IA5String, -- relative base path for the publisher RsyncModuleUri ::= IA5String -- Constrained to an rsync URI -- MUST end with a slash and refer to the base -- directory of the publication server's -- rsync module. RrdpNotifyUri ::= IA5String -- Constrained to an HTTP(s) URI -- MUST refer to the RRDP Notification URI [RFC8182] -- for this publication server. SupportedTypes ::= SEQUENCE (SIZE(1..MAX)) OF RpkiObjectType RpkiObjectType ::= PrintableString (SIZE (4)) -- Constrained to a '.' character followed -- by a three letter extension specified in -- the IANA "RPKI Repository Name Scheme" registry 6.2.2.1. ServiceUri Contains the unique service URI for this publisher. If this is a new URI, then it MUST be on the same host (avoid key theft and MiTM redirecting publishers). V2 will require unique URIs so that we do not need to send publisher handles in each query but can do it as a path parameter. It also allows more efficient processing for unknown publishers and per publisher rate limits to be enforced more intuitively and without the need for object parsing which could be a DoS vector otherwise. Bruijnzeels Expires 27 April 2023 [Page 12] Internet-Draft Publication Protocol V2 October 2022 6.2.2.2. RsyncBaseUri This is an rsync URI [RFC5781] pointing to the base rsync module used by the publication server. 6.2.2.3. BasePath This is the relative base path under the rsync module where the querying publisher is allowed to publish their objects. The BasePath MUST NOT be empty if the server supports multiple publishers. The BasePath MUST be a unix style relative directory path. It MUST use the following ABNF syntax [RFC5234]: BasePath = empty / sub-dir empty = "" sub-dir = dir *(dir) dir = *(DIGIT / ALPHA / "-" / "_" ) "/" Note that publishers will specify relative object paths under their base path during the publication exchange defined below to ensure that _all_ objects are always constrained to the publishers space. This eliminates the possibility of Publishers trying to update any object outside of their own "jail". In V1 the full path was used for objects, and the Server would response with a "permission_failure" error code in case a Publisher tried to use an URI it was not authorised to use. The publisher can derive public URIs for their objects, e.g. for use in SIA and AIA fields of certificates and objects they sign, by concatenating the following: URI = Rsync Base Uri / Base Path / Relative Object Path 6.2.2.4. RrdpNotifyUri If the publication server supports the RRDP [RFC8182], then it MUST include the public HTTPS URI [RFC8820] for the RRDP notification file here. 6.2.2.5. SupportedTypes If the server enforces RPKI object type restrictions, then it MUST include the full list of supported object types. Object types are defined by the extension registered in the IANA "RPKI Repository Name Scheme" registry. E.g. the object type for ROA is ".roa". Bruijnzeels Expires 27 April 2023 [Page 13] Internet-Draft Publication Protocol V2 October 2022 6.3. Status Exchange The status exchange is used to query the server for the current objects and quota state for this publisher. Furthermore, the server can communicate a planned key rollover of its identity key in this exchange. Publishers SHOULD initiate a status exchange before initiating any publication exchange. Publisher ---------- Status Query ---------> Server <--------- Status Reply ---------- 6.3.1. Status Query The MessageType for this query is: "status-query", the MessageContent is omitted. 6.3.2. Status Reply The MessageType for this query is: "status-reply". The MessageContent is as follows: Bruijnzeels Expires 27 April 2023 [Page 14] Internet-Draft Publication Protocol V2 October 2022 MessageContent ::= SEQUENCE { CurrentFiles CurrentFiles, QuotaNumberInfo [0] QuotaNumberInfo OPTIONAL QuotaSizeInfo [1] QuotaSizeInfo OPTIONAL NewBpkiTaCert [2] NewBpkiTaCert OPTIONAL } CurrentFiles ::= SEQUENCE (SIZE(0..MAX)) OF CurrentFile CurrentFile ::= SEQUENCE { RelativePath IA5String, Hash BitString } QuotaNumberInfo ::= SEQUENCE { used Integer, warn Integer, limit Integer } QuotaSizeInfo ::= SEQUENCE { used Integer, warn Integer, limit Integer } NewBpkiTaCert ::= OCTET STRING -- constrained to a DER encoded self-signed -- BPKI TA certificate 6.3.2.1. CurrentFiles Contains the full list of current published files. Files are described by their relative path under the publisher's base path and use the SHA-256 hash. 6.3.2.2. QuotaNumberInfo Optional element that MUST be included if the server enforces any quota based on the number of files published by a publisher. It is RECOMMENDED that servers enforce such quota. If they do, they SHOULD choose a number for the warn level that is significantly lower than the limit. Bruijnzeels Expires 27 April 2023 [Page 15] Internet-Draft Publication Protocol V2 October 2022 6.3.2.3. QuotaNumberSize Optional element that MUST be included if the server enforces any quota based on the combined size of files published by a publisher. Numbers are in kB, rounded up in case of 'used'. It is RECOMMENDED that servers enforce this type of quota. If they do, they SHOULD choose a number for the warn level that is significantly lower than the limit. 6.3.3. NewBpkiTaCert Servers may wish to perform a key roll of their BPKI TA certificate (see [RFC8183]). To achieve this the server can generate a new keypair and self-signed BPKI TA certificate - which can be used for publishers in future [RFC8183] out-of-band setup exchanges. However, it would be extremely impractical to require that all existing publishers re-do such an exchange. Furthermore, the server has no active way to reach out to publishers because all exchanges are initiated by the publishers. By including the optional NewBpkiTaCert element in a status reply the Server MAY communicate to Publishers that they intend to migrate to a new identity key. If a publisher sees a new BPKI TA certificate included this way, then they SHOULD perform a "Server Key Accept Exchange" (see elsewhere in doc) at their earliest convenience. The server MUST NOT include this element to publishers which have accepted the new key. Note that if a publisher wishes to perform a key roll of their own BPKI TA certificate, they need to initiate a "Publisher Key Change Exchange" (section ..). 6.4. Publication Exchange The publishers initiates a publication exchange in order to request adding, updating, or withdrawing objects under its designated publication point at the server. The server reply can be an empty ok reply, a warning reply which indicates that publication was successful but the publisher should be aware of certain things (like quota warnings), or an error reply which indicates that publication was rejected. Bruijnzeels Expires 27 April 2023 [Page 16] Internet-Draft Publication Protocol V2 October 2022 Publisher ---- Publication Query ----------> Server <-- Publication Ok Reply --------- one of: <-- Publication Warning Reply ---- <-- Publication Error Reply ------ 6.4.1. Publication Query The MessageType for this query is: "publication-query". The MessageContent is as follows: MessageContent ::= SEQUENCE { Additions SEQUENCE (SIZE(0..MAX)) OF AddedFile Updates SEQUENCE (SIZE(0..MAX)) OF UpdatedFile Withdrawals SEQUENCE (SIZE(0..MAX)) OF WithdrawnFile } AddedFile ::= SEQUENCE { RelativePath RelativePath, Content OctetString } UpdatedFile ::= SEQUENCE { RelativePath RelativePath, Content OctetString, OldFileHash Hash } WithdrawnFile ::= SEQUENCE { RelativePath RelativePath, OldFileHash Hash } RelativePath ::= IA5String Hash ::= BIT STRING 6.4.2. Publication Ok Reply The MessageType for this reply is: "publication-ok-reply", and the MessageContent is omitted. 6.4.3. Publication Warning Reply The MessageType for this reply is: "publication-warning-reply", the MessageContent is as follows: Bruijnzeels Expires 27 April 2023 [Page 17] Internet-Draft Publication Protocol V2 October 2022 MessageContent ::= SEQUENCE { QuotaNumberWarning [0] QuotaNumberInfo OPTIONAL QuotaSizeWarning [1] QuotaSizeInfo OPTIONAL } QuotaNumberInfo ::= SEQUENCE { used Integer, warn Integer, limit Integer } QuotaSizeInfo ::= SEQUENCE { used Integer, warn Integer, limit Integer } A publication warning reply MUST contain at least one of the possible warnings. If there is nothing to warn about then either a "Publication Ok Replay" or "Publication Error Reply" would be applicable. Publisher software SHOULD log any publication warning reply it receives in a way that is visible to operators so that they could enter in a dialogue with their server operator. Publisher software MAY try to reduce the number and size of objects by aggregating ROAs for the same origin ASN. Normally it is recommended that separate ROA objects are made for each ROA prefix and origin ASN because otherwise the loss of one prefix on a covering certificate would invalidate the complete ROA object. But, in case of quota issues this risk aversion may not outweigh the potential benefit of space saving through aggregation. 6.4.4. Publication Error Reply 6.4.4.1. MessageType The MessageType for this reply is: "publication-error-reply" 6.4.4.2. MessageContent Format to be determined. Publication rejected. Some possible reasons from V1: adding duplicate object, trying update/withdraw object for unknown relative path - or hash mismatch. Bruijnzeels Expires 27 April 2023 [Page 18] Internet-Draft Publication Protocol V2 October 2022 Some new reasons we may wish to support: unsupported object type included, object could not be parsed, publication point inconsistent (w.r.t. manifest). We will need more discussion on which errors we wish to flag, how to communicate relevant constraints at setup / protocol negotiation time, and how to report run time errors here. Some errors may be general, others may be specific to objects. Dependent on the errors we define, we may need specific instructions to Publishers about how to deal with them. For example, if an object type is not supported by the Server, then the Publisher may still wish to publish other object types and inform their user - who may then wish to migrate to another publication server. 6.5. Server Key Accepted Exchange This exchange SHOULD be initiated by the publisher at its earliest convenience after learning (Status Exchange) that a new key exists. It will confirm to the server that it can now use the new key instead of the previous key to sign replies. The typical reply is an ok reply signed with the new key. Or an error reply. 6.5.1. Server Key Accepted Query 6.5.1.1. MessageType The MessageType for this reply is: "server-key-accept" 6.5.1.2. MessageContent The Publisher repeats the new BPKI TA Certificate that it believes the Server intends to migrate towards: MessageContent ::= SEQUENCE { NewBpkiTaCert NewBpkiTaCert -- Use a SEQUENCE for extensibility? } NewBpkiTaCert ::= OCTET STRING -- constrained to a DER encoded self-signed -- BPKI TA certificate Bruijnzeels Expires 27 April 2023 [Page 19] Internet-Draft Publication Protocol V2 October 2022 6.5.2. Server Key Accepted Ok Reply The MessageType for this reply is: "server-key-accept-ok". There is no content, but the response is signed using the now accepted key. The Publisher MAY now forget the (now) old server key and MUST expect the new (now current) key to be used in future replies signed by the Server. The Server SHOULD no longer inform this Publisher about the new key in in new Status Reply responses. If this was the last Publisher to accept the new key, the Server MAY now delete its old key pair. 6.5.3. Server Key Accepted Error Reply It is not expected that an error is returned. However, it could be that the Publisher was confused an sent a Server Key Accepted Query for a key that the Server does not wish to migrate to. Or the server changed its mind in between last informing the the Publisher in a Status Reply and now. In any event.. the server MUST return an error in this case, an the Publisher MUST continue to expect the current server key to be used for signing replies. The MessageType for this reply is: "server-key-accepted-error". There is no content. 6.6. Publisher Key Change Exchange 6.6.1. Publisher Key Change Query 6.6.1.1. MessageType The MessageType for this query is: "client-key-change" 6.6.1.2. MessageContent The publisher sends its new key to the server by means of a (validly self-signed) BPKI TA certificate. MessageContent ::= SEQUENCE { NewBpkiTaCert NewBpkiTaCert -- Use a SEQUENCE for extensibility? } NewBpkiTaCert ::= OCTET STRING -- constrained to a DER encoded self-signed -- BPKI TA certificate Bruijnzeels Expires 27 April 2023 [Page 20] Internet-Draft Publication Protocol V2 October 2022 6.6.2. Publisher Key Change Ok Reply The MessageType for this reply is: "client-key-change-ok". There is no content. The Publisher MUST now use the new key in future exchanges, at least until the new key itself is changed of course. The Server MAY now forget the previous key for the Publisher and MUST now expect this new key to be used. 6.6.3. Publisher Key Change Error Reply The MessageType for this reply is: "client-key-change-error". There is no content. The server SHOULD return this error only in case it finds that the new BPKI TA Certificate is not validly signed. I.e. there was no proof of possession of the private key. This is unlikely to happen and it would point at a serious issue with either the Publisher or the Server software, or both.. Both the Publisher and Server should alert their operators in the applicable ways that can (log, report status error etc). The Publisher SHOULD continue to use its previous key, it MUST NOT start to use its intended new key until this issue is resolved - presumably after operator and/or developer actions. 7. IANA Considerations OID needs to be requested. 8. Security Considerations TBD 9. Acknowledgements To be determined. As it stands this document represents early ideas about a possible direction for a next version of the publication protocol. There have been some informal discussions with various people. It's not certain yet how we will proceed. Perhaps this will become a working group document, perhaps it will only serve discussion and another document or documents follow. So.. to be determined. 10. Normative References Bruijnzeels Expires 27 April 2023 [Page 21] Internet-Draft Publication Protocol V2 October 2022 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A Protocol for Provisioning Resource Certificates", RFC 6492, DOI 10.17487/RFC6492, February 2012, . [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, . [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, . [RFC8820] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 8820, DOI 10.17487/RFC8820, June 2020, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . 11. Informative References Bruijnzeels Expires 27 April 2023 [Page 22] Internet-Draft Publication Protocol V2 October 2022 [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, . Author's Address Tim Bruijnzeels NLnet Labs Email: tim@nlnetlabs.nl URI: https://www.nlnetlabs.nl/ Bruijnzeels Expires 27 April 2023 [Page 23]