Network Working Group T. Bruijnzeels
Internet-Draft O. Muravskiy
Intended status: Standards Track RIPE NCC
Expires: March 07, 2015 B. Weber
Cobenian
September 05, 2014
RPKI Repository Delta Protocol
draft-tbruijnzeels-sidr-delta-protocol-02
Abstract
In the Resource Public Key Infrastructure (RPKI), certificate
authorities publish certificates, including end entity certificates,
and CRLs to repositories on publication servers. Relying Parties
(RP) retrieve the published information from the repository and MAY
store it in a cache. This document specifies a delta protocol which
provides relying parties with a mechanism to query a repository for
changes, thus enabling the RP to keep its state in sync with the
repository.
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 http://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 March 07, 2015.
Copyright Notice
Copyright (c) 2014 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 (http://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 Simplified BSD License text
Bruijnzeels, Muravskiy & Expires March 07, 2015 [Page 1]
Internet-Draft RPKI Repository Delta Protocol September 2014
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. RPKI Repository Delta Protocol Implementation . . . . . . . . 3
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Transport protocol . . . . . . . . . . . . . . . . . . . . 4
3.3. File Format . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Update Notification File . . . . . . . . . . . . . . . . . 4
3.4.1. Root Element . . . . . . . . . . . . . . . . . . . . . 5
3.4.2. Contents . . . . . . . . . . . . . . . . . . . . . . . 5
3.4.2.1. SNAPSHOT ELEMENT . . . . . . . . . . . . . . . . . 5
3.4.2.2. SNAPSHOT SEGMENT ELEMENT . . . . . . . . . . . . . 6
3.4.2.3. DELTAS ELEMENT . . . . . . . . . . . . . . . . . . 6
3.4.2.4. DELTA SEGMENT ELEMENT . . . . . . . . . . . . . . 6
3.4.3. Sample Notification File . . . . . . . . . . . . . . . 7
3.4.4. Snapshot and Delta Availability Requirements . . . . . 9
3.5. Snapshot Segment Format . . . . . . . . . . . . . . . . . 9
3.5.1. Root Element . . . . . . . . . . . . . . . . . . . . . 9
3.5.2. Contents . . . . . . . . . . . . . . . . . . . . . . . 10
3.5.2.1. PUBLISH ELEMENT . . . . . . . . . . . . . . . . . 10
3.5.3. Sample SNAPSHOT SEGMENT file . . . . . . . . . . . . . 10
3.5.4. Applying changes from snapshot segments . . . . . . . 11
3.6. Incremental Delta Format . . . . . . . . . . . . . . . . . 11
3.6.1. Root Element . . . . . . . . . . . . . . . . . . . . . 11
3.6.2. Contents . . . . . . . . . . . . . . . . . . . . . . . 12
3.6.2.1. DELTA ELEMENT . . . . . . . . . . . . . . . . . . 12
3.6.2.1.1. WITHDRAW ELEMENT . . . . . . . . . . . . . . . 12
3.6.2.1.2. PUBLISH ELEMENT . . . . . . . . . . . . . . . 13
3.6.3. Sample DELTAS file . . . . . . . . . . . . . . . . . . 13
3.6.4. Applying changes from delta segments . . . . . . . . . 14
3.7. SIA for CA certificates . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] .
2. Introduction
Bruijnzeels, Muravskiy & Expires March 07, 2015 [Page 2]
Internet-Draft RPKI Repository Delta Protocol September 2014
In the Resource Public Key Infrastructure (RPKI), certificate
authorities publish certificates, including end entity certificates,
and CRLs to repositories on publication servers. Relying Parties
(RP) retrieve the published information from the repository and MAY
store it in a cache. This document specifies a delta protocol which
provides relying parties with a mechanism to query a repository for
changes, thus enabling the RP to keep its state in sync with the
repository.
This protocol aims to minimize the amount of data that traverses the
network and thus helps minimize the amount of time until repository
convergence occurs. This protocol also provides a standards based
way to obtain consistent, point in time views of a single repository
eliminating a number of consistency related issues. The protocol is
designed to be consistent with the publication protocol (http://
datatracker.ietf.org/doc/draft-ietf-sidr-publication/) wherever
possible.
3. RPKI Repository Delta Protocol Implementation
3.1. Overview
Relying parties in the RPKI retrieve information from repositories.
In order to retrieve the information as efficiently as possible this
protocol defines an update notification file which can be used to
determine if the RP and repository are synchronized. If the RP is
not in sync with the repository, the update notification file
provides a means to locate files containing deltas from the past 24
hours or snapshot file(s) with a complete, point in time version of
the repository no less than 24 hours old. When possible the use of
deltas SHOULD be preferred as the means for synchronizing the state
of the RP with the repository. When a RP is in a state such that the
available deltas are insufficient to synchronize its state with the
repository then the snapshot file(s) MUST be used. Such cases can
occur when a new RP is first brought online, when a RP has not
retrieved updates for more than 24 hours, when a RP has become out of
sync with the repository due to an error or when the repository must
transition to a new session id. After downloading a snapshot it MAY
be necessary to apply deltas to synchronize with the current version
of the repository. Therefore, it MUST always be possible to apply
zero or more deltas to the snapshot to synchronize a RP with the
current version of the repository. The snapshot and delta files are
immutable in that the contents for a given URI never change and can
safely be cached. Immutable files cause less processing to be done
on the server and allow for safe caching of repository content.
The snapshot provides a consistent, point in time view of the
repository. The snapshot can be large so it is RECOMMENDED to break
Bruijnzeels, Muravskiy & Expires March 07, 2015 [Page 3]
Internet-Draft RPKI Repository Delta Protocol September 2014
it into multiple segment files. Each file making up the snapshot
MUST have a unique URI. It is RECOMMENDED to make each URI contain
the session id, version and segment number.
Each delta file describes changes in the repository from one point in
time to another point in time. A single delta file MAY contain many
updates. Due to the way that Certificate Authorities frequently sign
new manifests and CRLs in large batches some deltas may contain a
large number of changes. For this reason it is also RECOMMENDED to
split large deltas into multiple segment files. Each delta segment
file MUST be made available over a unique URI. It is recommended to
include the following information in the URI; session id, from
version number, to version number, and segment number if applicable.
In this document we will assume that HTTP is used as the transport
protocol. The unique URIs for snapshot and delta files are intended
to support HTTP caching, possibly by Content Delivery Networks
(CDNs). We will include HTTP specific hints with regards to the
caching and retrieval of the update notification file. It should be
noted that other transport protocols can also be used, provided that
the same caching semantics are observed.
3.2. Transport protocol
The delta protocol described here has been designed to use HTTP as
the transport protocol although it is not strictly required. Any
transport protocol that meets the requirements laid out in the
following sections can be used in place of HTTP.
3.3. File Format
This protocol uses XML for the update notification, snapshot and
delta files.
3.4. Update Notification File
The update notification file is used by RPs to discover whether any
changes exist between the state of the publication server's
repository and the RP's cache. It describes the location of the
files containing the snapshot and incremental deltas which can be
used by the RP to synchronize with the repository. The update
notification file can be cached, but it SHOULD NOT be cached for more
than five minutes. The URIs for each snapshot and delta file MUST be
unique and the contents of the files for each URI MUST NOT change.
Assuming that HTTP is used as the transport protocol, publication
servers SHOULD use appropriate cache headers. The maximum allowed
time to cache MUST NOT exceed 5 minutes (e.g. add header: Cache-
Control: max-age=300). It is RECOMMENDED that Relying Parties use the
"If-Modified-Since" header in GET requests for the notification file.
Bruijnzeels, Muravskiy & Expires March 07, 2015 [Page 4]
Internet-Draft RPKI Repository Delta Protocol September 2014
A RP MUST NOT process any update notification file that is incomplete
or not well formed.
3.4.1. Root Element
The XML namespace MUST be http://www.ripe.net/rpki/rrdp.
The encoding MUST be us-ascii.
The root element MUST be msg and it contains the following
attributes:
+---------------+-------------------------------+-------------------+
| Attribute | Description | Value |
+---------------+-------------------------------+-------------------+
| type | The type of this RRDP | notification |
| | message. | |
| version | The RRDP protocol version of | 1 |
| | this message. | |
+---------------+-------------------------------+-------------------+
3.4.2. Contents
The message MUST contain one notification element. The element has
the following attributes:
+---------------------+---------------------------------------------+
| Attribute | Description |
+---------------------+---------------------------------------------+
| session_id | Unique identifier of the session id of the |
| | publication server. It is RECOMMENDED that |
| | a UUID is used as the session_id. |
| current_version | Unbounded, unsigned integer representing |
| | the current version of the repository. |
+---------------------+---------------------------------------------+
The current version number MUST be one greater than the previous
version number for a given session id. If a repository server is no
longer able to provide contiguous deltas it MUST reset the session id
and start with version 0.
The notification element MUST contain one 'snapshot' element and MAY
contain a 'deltas' element. In practice the 'deltas' element will
almost always be present because most Certificate Authorities re-sign
manifests and CRLs at a frequency of at least once every 24 hours.
The snapshot and deltas elements are each described below.
3.4.2.1. SNAPSHOT ELEMENT
A snapshot is a point in time view of the state of the entire
repository. A snapshot MUST have one or more 'snapshot-segment'
elements.
Bruijnzeels, Muravskiy & Expires March 07, 2015 [Page 5]
Internet-Draft RPKI Repository Delta Protocol September 2014
The snapshot segment files MUST NOT contain duplicate entries for the
same certificate or CRL URI. This means that snapshot segments do not
have to be applied in serial.
+-----------------+-------------------------------------------------+
| Attribute | Description |
+-----------------+-------------------------------------------------+
| version | The version number of the repository for this |
| | full snapshot. |
+-----------------+-------------------------------------------------+
3.4.2.2. SNAPSHOT SEGMENT ELEMENT
A snapshot-segment contains information about one segment of a full
snapshot.
+----------+--------------------------------------------------------+
| Attribut | Description |
| e | |
+----------+--------------------------------------------------------+
| uri | A unique URI for this snapshot segment. The URI must |
| | be unique so the file can be cached indefinitely. It |
| | is RECOMMENDED to construct this URI based on the |
| | session id, version and segment number. E.g. |
| | http://host/snapshots/SESSION_ID/VERSION/SEGMENT.xml |
| | or with concrete data |
| | http://host/snapshots/9f735ad0-aef4-4d8b- |
| | 820d-559472936265/203/4.xml |
| hash | The SHA-256 hash of the snapshot segment file (similar |
| | to RFC 6485). This does not provide any additional |
| | security, it merely helps detect transport errors. |
+----------+--------------------------------------------------------+
3.4.2.3. DELTAS ELEMENT
The deltas element contains delta segment elements with information
about the available deltas. It does not have any attributes.
The delta segments MUST be listed in chronological order and MUST be
replayed in the order specified in the updated notification file.
While one version MAY be covered in more than one file there MUST NOT
be any overlap in version numbers. There are two possible valid
cases. The first is that the from and to versions are identical to
the previous segment and the segment number is one greater than the
previous delta. The other valid case is when the from version is
equal to the to version of the previous delta and the to version of
the element is greater than or equal to the from version of the
element. In this case the segment number MAY be present and have a
value of 1 or MUST NOT be present. Any case that does not meet one
of these two requirements MUST be considered invalid.
3.4.2.4. DELTA SEGMENT ELEMENT
Bruijnzeels, Muravskiy & Expires March 07, 2015 [Page 6]
Internet-Draft RPKI Repository Delta Protocol September 2014
A delta segment file element contains information about one or more
sets of deltas specified by the starting 'from' version and going
until the ending 'to' version. These deltas may be aggregated over
time, however each delta file remains immutable. The delta element
serves for deltas that are too large to fit in one file. It is
broken into segments similar to the way that the snapshot file is
broken into segments.
+---------+---------------------------------------------------------+
| Attribu | Description |
| te | |
+---------+---------------------------------------------------------+
| from | The first version contained in the delta. |
| to | The last version contained in the delta. |
| uri | A URI pointing to the file containing the changes in |
| | this delta. The URI must be unique so the file can be |
| | cached indefinitely. It is RECOMMENDED to construct |
| | this URI based on the session id, from version, to |
| | version and segment number (if applicable) for this |
| | delta. E.g. |
| | http://host/deltas/SESSION_ID/FROM/TO/SEGMENT.xml or |
| | http://host/deltas/9f735ad0-aef4-4d8b- |
| | 820d-559472936265/173/174/5.xml |
| hash | The SHA-256 hash of the delta segment file (similar to |
| | RFC 6485). This does not provide any additional |
| | security, it merely helps detect transport errors. |
+---------+---------------------------------------------------------+
3.4.3. Sample Notification File
Bruijnzeels, Muravskiy & Expires March 07, 2015 [Page 7]
Internet-Draft RPKI Repository Delta Protocol September 2014
It should be noted that the length of the UUID and SHA-256 hashes are
not the correct length, this example is only for illustrative
purposes.
3.4.4. Snapshot and Delta Availability Requirements
It is RECOMMENDED that publication servers aggregate deltas after
some time to reduce the number of fetches that RPs need to perform
and to keep the notification file small. There are several
strategies possible to optimize this, so this is not limited strictly
here.
The publication server MUST provide a set of deltas that allow RPs to
synchronize to the current version number from the snapshot. The RP
MAY need to process more than one delta to achieve this.
3.5. Snapshot Segment Format
A snapshot MUST contain all objects from the repository current as of
the time of the publication. Each segment contains a subset of the
objects such that the union of all the segments make up the full
snapshot. Snapshot segments only contain publish elements. They
MUST NOT contain withdraw elements.
3.5.1. Root Element
The XML namespace MUST be http://www.ripe.net/rpki/rrdp.
The encoding MUST be us-ascii.
The root element MUST be msg and it contains the following
attributes:
+-----------+--------------------------------------------+----------+
| Attribute | Description | Value |
+-----------+--------------------------------------------+----------+
| type | The type of this RRDP message. | snapshot |
| version | The RRDP protocol version of this message. | 1 |
+-----------+--------------------------------------------+----------+
Bruijnzeels, Muravskiy & Expires March 07, 2015 [Page 9]
Internet-Draft RPKI Repository Delta Protocol September 2014
3.5.2. Contents
The message MUST contain one snapshot element. The element has the
following attributes:
+--------------+----------------------------------------------------+
| Attribute | Description |
+--------------+----------------------------------------------------+
| session_id | Unique identifier of the session id of the |
| | publication server. It is RECOMMENDED that a UUID |
| | is used as the session_id. |
| version | Unbounded, unsigned integer representing the |
| | current version of the repository. |
| index | The index of this segment for the given version, |
| | as in, this is segment 2 of 9 for version 836. The |
| | index is one based so the first value is 1 and NOT |
| | 0. |
+--------------+----------------------------------------------------+
3.5.2.1. PUBLISH ELEMENT
The publish element is an exact copy of the publish element as
described in the publication document (reference: http://
tools.ietf.org/html/draft-ietf-sidr-publication-03#section-3.3).
+-----------------+-------------------------------------------------+
| Attribute | Description |
+-----------------+-------------------------------------------------+
| uri | The URI that was included in the original |
| | 'publish' element. |
+-----------------+-------------------------------------------------+
The content of each element is the base 64 encoded object.
The URI is useful for current RP implementations that use URIs to
work out relations in the RPKI. It should be noted though that RPs
can also work this out based on manifests and object properties such
as key identifiers, signatures and the hash of the binary object.
See: http://www.ietf.org/internet-drafts/draft-tbruijnzeels-sidr-
validation-local-cache-00.txt
The extension of the filename can be used by the RP to determine the
type of object.
3.5.3. Sample SNAPSHOT SEGMENT file
Bruijnzeels, Muravskiy & Expires March 07, 2015 [Page 10]
Internet-Draft RPKI Repository Delta Protocol September 2014
MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQD
jRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFMkEzMB4XE
........................................................
h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx0iwPYdLiDbdWFbtTdPcXBau
MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQD
h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx0iwPYdLiDbdWFbtTdPcXBau
........................................................
jRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFMkEzMB4XD
MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEwLwYDVQQD
h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx0iwPYdLiDbdWFbtTdPcXBau
........................................................
jRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFMkEzMB4XD
Lines containing only periods signify additional lines of base 64
encoded data.
3.5.4. Applying changes from snapshot segments
Snapshot segments for a given session id and version MUST NOT contain
publish elements for a given URI. Therefore snapshot segments do not
have to be applied in a particular order.
3.6. Incremental Delta Format
An incremental delta segment file contains all changes between the
start and end versions.
3.6.1. Root Element
The XML namespace MUST be http://www.ripe.net/rpki/rrdp.
The encoding MUST be us-ascii.
The root element MUST be msg and it contains the following
attributes:
Bruijnzeels, Muravskiy & Expires March 07, 2015 [Page 11]
Internet-Draft RPKI Repository Delta Protocol September 2014
+-----------+--------------------------------------------+--------+
| Attribute | Description | Value |
+-----------+--------------------------------------------+--------+
| type | The type of this RRDP message. | deltas |
| version | The RRDP protocol version of this message. | 1 |
+-----------+--------------------------------------------+--------+
3.6.2. Contents
The message MUST contain one deltas element. The deltas must be
applied in the numeric order by version and then by the order in
which they appear in this file. The deltas element has the following
attributes:
+--------------+----------------------------------------------------+
| Attribute | Description |
+--------------+----------------------------------------------------+
| session_id | Unique identifier of the session id of the |
| | publication server. It is RECOMMENDED that a UUID |
| | is used as the session_id. |
| from | Unbounded, unsigned integer representing the first |
| | version for this delta. |
| to | Unbounded, unsigned integer representing the last |
| | version for this delta. |
| index | The index of this delta IF the delta was not able |
| | to fit in one file, as in, this is segment 2 of 9 |
| | for the delta that covers the changes from version |
| | 3 to version 4. The index is one based so the |
| | first value is 1 and NOT 0. This attribute is |
| | OPTIONAL, but it MUST be present if the particular |
| | version range is covered by more than one file. |
+--------------+----------------------------------------------------+
3.6.2.1. DELTA ELEMENT
+-----------+-----------------------------------+
| Attribute | Description |
+-----------+-----------------------------------+
| version | The version of the delta changes. |
+-----------+-----------------------------------+
The delta element contains withdraw and publish elements.
3.6.2.1.1. WITHDRAW ELEMENT
The withdraw element is an exact copy of the withdraw element as
described in the publication document (reference: http://
tools.ietf.org/html/draft-ietf-sidr-publication-03#section-3.3).
Bruijnzeels, Muravskiy & Expires March 07, 2015 [Page 12]
Internet-Draft RPKI Repository Delta Protocol September 2014
+-----------------+-------------------------------------------------+
| Attribute | Description |
+-----------------+-------------------------------------------------+
| uri | The URI that was included in the original |
| | withdraw element. |
+-----------------+-------------------------------------------------+
3.6.2.1.2. PUBLISH ELEMENT
The publish element is an exact copy of the publish element as
described in the publication document (reference: http://
tools.ietf.org/html/draft-ietf-sidr-publication-03#section-3.3).
+-----------------+-------------------------------------------------+
| Attribute | Description |
+-----------------+-------------------------------------------------+
| uri | The URI that was included in the original |
| | publish element. |
+-----------------+-------------------------------------------------+
The content of each element is the base 64 encoded object.
The URI is useful for current RP implementations that use URIs to
work out relations in the PKI. It should be noted though that RPs can
also work this out based on manifests and object properties such as
key identifiers, signatures and the hash of the binary object. See:
http://www.ietf.org/internet-drafts/draft-tbruijnzeels-sidr-
validation-local-cache-00.txt
The extension of the filename can be used by the RP to determine the
type of object.
3.6.3. Sample DELTAS file
Bruijnzeels, Muravskiy & Expires March 07, 2015 [Page 13]
Internet-Draft RPKI Repository Delta Protocol September 2014
MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEw
jRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFM
................................................
h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx0iwPYdLiDbdWFbt
MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEw
h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx0iwPYdLiDbdWFbt
................................................
jRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFM
MIIE+jCCA+KgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAzMTEw
h8zeHoFVu6ghRPy5dbOA4akX/KG6b8XIx0iwPYdLiDbdWFbt
................................................
jRBODAxN0U2NkE5RTkxNzJFNDYxMkQ4Q0Y0QzgzRjIzOERFM
The dotted lines signify additional lines of Base 64 encoded data.
3.6.4. Applying changes from delta segments
Delta segment files which are not well formed MUST NOT be processed.
The delta segment with the lowest from version for a given session id
MUST be processed first. Each version for a given session id SHOULD
NOT be applied more than once. Delta segments for a given session
id, from version and to version MUST be applied in the order of the
version and then by the order in which they are specified in the
file.
3.7. SIA for CA certificates
Certificate Authorities that use this delta protocol MUST have an
instance of an SIA AccessDescription in addition to the ones defined
in [RFC6487],
Bruijnzeels, Muravskiy & Expires March 07, 2015 [Page 14]
Internet-Draft RPKI Repository Delta Protocol September 2014
AccessDescription ::= SEQUENCE {
accessMethod OBJECT IDENTIFIER,
accessLocation GeneralName }
This extension MUST use an accessMethod of id-ad-rrdpNotify,
id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }
id-ad-rrdpNotify OBJECT IDENTIFIER ::= { id-ad TBD }
The accessLocation MUST be a URI [RFC3986], using the 'http'
protocol, that will point to the update notification file for the
publication server that publishes the products of this CA
certificate.
4. Security Considerations
TBD
5. IANA Considerations
This document has no actions for IANA.
6. Acknowledgements
TBD
7. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[RFC6487] Huston, G., Michaelson, G. and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487, February
2012.
Authors' Addresses
Tim Bruijnzeels
RIPE NCC
Email: tim@ripe.net
Oleg Muravskiy
RIPE NCC
Email: oleg@ripe.net
Bruijnzeels, Muravskiy & Expires March 07, 2015 [Page 15]
Internet-Draft RPKI Repository Delta Protocol September 2014
Bryan Weber
Cobenian
Email: bryan@cobenian.com
Bruijnzeels, Muravskiy & Expires March 07, 2015 [Page 16]