Internet DRAFT - draft-timbru-sidrops-rpki-publication-v2
draft-timbru-sidrops-rpki-publication-v2
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 <report_error/> 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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[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>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
<https://www.rfc-editor.org/info/rfc6585>.
[RFC8174] 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>.
[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>.
[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
"The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
DOI 10.17487/RFC8182, July 2017,
<https://www.rfc-editor.org/info/rfc8182>.
[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>.
[RFC8820] Nottingham, M., "URI Design and Ownership", BCP 190,
RFC 8820, DOI 10.17487/RFC8820, June 2020,
<https://www.rfc-editor.org/info/rfc8820>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
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,
<https://www.rfc-editor.org/info/rfc5781>.
Author's Address
Tim Bruijnzeels
NLnet Labs
Email: tim@nlnetlabs.nl
URI: https://www.nlnetlabs.nl/
Bruijnzeels Expires 27 April 2023 [Page 23]
