One document matched: draft-ietf-sidr-rpki-oob-setup-03.xml
<?xml version="1.0"?>
<!-- $Id: draft-ietf-sidr-rpki-oob-setup.xml 3436 2015-10-19 12:14:08Z sra $ -->
<?rfc compact="yes"?><?rfc sortrefs="yes"?><?rfc subcompact="no"?><?rfc symrefs="yes"?><?rfc toc="yes"?><rfc docName="draft-ietf-sidr-rpki-oob-setup-03" ipr="trust200902" category="std">
<front>
<title abbrev="RPKI Out-Of-Band Setup">
An Out-Of-Band Setup Protocol For RPKI Production Services
</title>
<author initials="R." surname="Austein" fullname="Rob Austein">
<organization>Dragon Research Labs</organization>
<address>
<email> sra@hactrn.net </email>
</address>
</author>
<!-- month="December" year="2013" -->
<date/>
<keyword>RPKI</keyword>
<abstract>
<t>
This note describes a simple out-of-band protocol to ease
setup of the RPKI provisioning and publication protocols
between two parties. The protocol is encoded in a small
number of XML messages, which can be passed back and forth by
any mutually agreeable secure means.
</t>
<t>
This setup protocol is not part of the provisioning or
publication protocol, rather, it is intended to simplify
configuration of these protocols by setting up relationships
and exchanging BPKI keying material.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="introduction">
<t>
This note describes a small XML-based out-of-band protocol
used to set up relationships between parents and children in
the RPKI provisioning protocol
(<xref target="RFC6492"/>)
and between publishers and repositories in the RPKI
publication protocol
(<xref target="I-D.ietf-sidr-publication"/>).
</t>
<t>
The basic function of this protocol is public key exchange, in
the form of self-signed BPKI X.509 certificates, but workshop
experience has demonstrated that it's simpler for the user if
we also bundle the other configuration information needed to
bring up a new player into the messages used in the key
exchange.
</t>
<t>
The underlying transport for this protocol is deliberately
unspecified. It might be a USB stick, a web interface secured
with conventional HTTPS, PGP-signed email, a T-shirt printed
with a QR code, or a carrier pigeon.
</t>
<t>
Since much of the purpose of this protocol is key exchange,
authentication and integrity of the key exchange MUST be
ensured via external means. Typically such means will tie
directly to a new or existing business relationship
</t>
</section>
<section title="Overview of the BPKI">
<t>
Several protocols related to RPKI provisioning use signed CMS
messages (<xref target="RFC5652"/>) to authenticate the
underlying XML-based protocols. Verification of these CMS
messages requires X.509 certificates. The PKI that holds
these certificates is distinct from the RPKI, and contains no
RFC 3779 resources. We refer to this as the "Business PKI"
(BPKI), to distinguish it from the RPKI. The "B" is a hint
that the certificate relationships in the BPKI are likely to
follow and become part of existing contractual relationships
between the issuers and subjects of this PKI.
</t>
<t>
The RPKI provisioning protocol does not dictate a particular
structure for the BPKI, beyond the basic requirement that it
be possible for one party to sign and the other party to
verify the CMS messages. This allows a certain amount of
flexibility to allow an Internet registry to reuse an existing
PKI as the BPKI if that makes sense in their context.
</t>
<t>
In order to keep this protocol simple, we adopt a somewhat
constrained model of the BPKI. The first two operations in
this protocol are an exchange of public keys between child and
parent for use in the provisioning protocol, the latter two
operations in this protocol are an exchange of public keys
between publisher and repository for use in the publication
protocol. In each of these operations, the sending
party includes its public key, in the form of a self-signed
X.509 CA certificate. The private keys corresponding to the
exchanged certificates are not used to sign CMS messages
directly; instead, the exchanged CA certificates are the
issuers of the BPKI end-entity (EE) certificates which will be
included in the CMS messages and can be used, along with the
exchanged certificates, to verify the CMS messages.
</t>
<t>
Details of how to tie the exchanged certificates into an
implementation's local BPKI are left to the implementation,
but the recommended approach is to cross-certify the received
public key and subject name under one's own BPKI, using a
Basic Constraints extension with cA = TRUE, pathLenConstraint
= 0, indicating that the cross-certified certificate is a CA
certificate which is allowed to issue EE certificates but is
not allowed to issue CA certificates. See section 4.2.1.9 of
<xref target="RFC5280"/> for more information about the Basic
Constraints extension.
</t>
<t>
For example, suppose that Alice and Bob each have their own
self-signed BPKI certificates:
</t>
<figure>
<artwork>
Issuer: CN = Alice CA
Subject: CN = Alice CA
Public Key: [Alice CA Public Key]
BasicConstraints: cA = TRUE
Issuer: CN = Bob CA
Subject: CN = Bob CA
Public Key: [Bob CA Public Key]
BasicConstraints: cA = TRUE
</artwork>
</figure>
<t>
Alice sends Bob her self-signed BPKI certificate, and Bob
cross-certifies its public key and subject name under
Bob's own self-signed BPKI certificate:
</t>
<figure>
<artwork>
Issuer: CN = Bob CA
Subject: CN = Alice CA
Public Key: [Alice CA Public Key]
BasicConstraints: cA = TRUE, pathLenConstraint = 0
</artwork>
</figure>
<t>
Later, when Bob receives a CMS message from Alice, Bob can
verify this message via a trust chain back to Bob's own trust
anchor:
</t>
<figure>
<artwork>
Issuer: CN = Alice CA
Subject: CN = Alice EE
Public Key: [Alice EE Public Key]
</artwork>
</figure>
<t>
[[Need some text detailing required and allowed values in the
certificates: 2048-bit RSA, what extensions, .... But once we
go there we also have to provide a path for algorithm
agility.]]
</t>
</section>
<section title="Protocol Elements">
<t>
Each message in the protocol is a distinct XML element in the
"http://www.hactrn.net/uris/rpki/rpki-setup/" XML namespace.
</t>
<!--
- Add a bulleted list (or something) describing the steps in
- the normal exchange?
-->
<section title="Nomenclature" anchor="nomenclature">
<t>
All of the protocols configured by this setup protocol have
their own terminology for their actors, but in the context
of this protocol that terminology becomes somewhat
confusing. All of the players in this setup protocol issue
certificates, are the subjects of other certificates,
operate servers, and, in most cases, act as clients for one
protocol or another. Therefore, this note uses its own
terms for the actors in this protocol.
<list style="hanging">
<t hangText="Child:">
An entity acting in the client ("subject") role of the
provisioning protocol defined in
<xref target="RFC6492"/>.
</t>
<t hangText="Parent:">
An entity acting in the server ("issuer") role of the
provisioning protocol defined in
<xref target="RFC6492"/>.
</t>
<t hangText="Publisher:">
An entity acting in the client role of the publication
protocol defined in
<xref target="I-D.ietf-sidr-publication"/>.
</t>
<t hangText="Repository:">
An entity acting in the server role of the publication
protocol defined in
<xref target="I-D.ietf-sidr-publication"/>.
</t>
</list>
</t>
<t>
Note that a given entity might act in more than one of these
roles; for example, in one of the simplest cases, the child
is the same entity as the publisher, while the parent is the
same entity as the repository.
</t>
</section>
<section title="Common Protocol Elements" anchor="common">
<t>
The first XML attribute in each message is a version field.
This document describes version 1 of the protocol.
</t>
<t>
Most messages contain, among other things, a self-signed
BPKI X.509 certificate. These certificates are represented
as XML elements whose text value is the Base64 text encoding
the DER representation of the X.509 certificate.
</t>
<t>
A number of attributes contain "handles". A handle in this
protocol is a text string in the US-ASCII character set
consisting of letters, digits, and the special characters
"/", "-", and "_". This protocol places no special
semantics on the structure of these handles, although
implementations might. Handles are protocol elements, not
necessarily meaningful to humans, thus the simplicity of a
restricted character set makes more sense than the complex
rules which would be needed for internationalized text.
</t>
</section>
<section title="Protocol Messages" anchor="protocol-messages">
<t>
The core of this protocol consists of four message types,
representing the basic request and response semantics
needed to configure a RPKI engine to talk to its parent and
its repository via the provisioning and publication
protocols, respectively.
</t>
<section title="<child_request/>" anchor="child_request">
<t>
The <child_request/> message is an initial setup
request from a provisioning protocol child to its
provisioning protocol parent.
</t>
<t>
Fields in the <child_request/> message:
<list style="hanging">
<t hangText="version:">
The version attribute specifies the protocol version.
This note describes protocol version 1.
</t>
<t hangText="child_handle:">
The child_handle attribute is what the child
calls itself. This is just a hint from the child
to the parent, the parent need not honor it.
</t>
<t hangText="child_bpki_ta:">
The <child_bpki_ta/> element is the child's BPKI
identity, a self-signed X.509 BPKI certificate, encoded
in Base64.
</t>
<t>
This CA certificate will be the issuer of the BPKI EE
certificates corresponding to private keys that the
child will use when sending provisioning protocol
messages to the parent.
</t>
</list>
</t>
<!-- Begin inclusion: example.child_request.Bob.xml --><figure><artwork>
---------------------------------------------------------------------
<child_request
child_handle="Bob"
version="1"
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
<child_bpki_ta>
R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
</child_bpki_ta>
</child_request>
---------------------------------------------------------------------
</artwork></figure><!-- End inclusion: example.child_request.Bob.xml -->
</section>
<section title="<parent_response/>" anchor="parent_response">
<t>
The <parent_response/> message is a response from a
provisioning protocol parent to a provisioning protocol
child that had previously sent a <child_request/>
message.
</t>
<t>
Fields in the <parent_response/> message:
<list style="hanging">
<t hangText="version:">
The version attribute specifies the protocol version.
This note describes protocol version 1.
</t>
<t hangText="service_uri:">
The service_uri attribute contains an HTTP URL that
the child should contact for up-down
(<xref target="RFC6492"/>) service.
</t>
<!--
- Tim notes that "might or might not match" == "MAY match",
- but that'd be the first 2119 language in this draft,
- not sure I want to open that can of worms today.
-->
<t hangText="child_handle:">
The child_handle attribute is the parent's name for the
child. This might or might not match the child_handle
from the <child_request/> message. If they do not
match, the parent wins, because the parent gets to
dictate the names in the provisioning protocol. This
value is the sender field in provisioning protocol
request messages and the recipient field in provisioning
protocol response messages.
</t>
<t hangText="parent_handle:">
The parent_handle attribute is the parent's name for
itself. This value is the recipient field in
provisioning protocol request messages and the sender
field in provisioning protocol response messages.
</t>
<t hangText="parent_bpki_ta:">
The <parent_bpki_ta/> element is the parent's BPKI
identity, a self-signed X.509 BPKI certificate.
</t>
<t>
This certificate is the issuer of the BPKI EE
certificates corresponding to private keys that the
parent will use to sign provisioning protocol messages
to the child.
</t>
<t hangText="offer:">
If an <offer/> element is present, the parent is
offering publication service to the child. The
<offer/> element, if present, is empty.
</t>
<t hangText="referral:">
If a <referral/> element is present, it suggests a
third-party publication services that the child might
use, and contains:
<list style="hanging">
<t hangText="referrer:">
A referrer attribute, containing the handle by which
the publication repository knows the parent,
</t>
<t hangText="contact_uri:">
An optional contact_uri attribute that the child may
be able to follow for more information, and
</t>
<t hangText="Authorization token:">
The text of the <referral/> element is the
Base64 encoding of a signed authorization token
granting the child the right to use a portion of the
parent's namespace at the publication repository in
question. See <xref target="authorization"/> for
details on the authorization token.
</t>
</list>
</t>
</list>
</t>
<!-- Begin inclusion: example.parent_response.Alice.xml --><figure><artwork>
---------------------------------------------------------------------
<parent_response
child_handle="Bob-42"
parent_handle="Alice"
service_uri="http://a.example/up-down/Alice/Bob-42"
version="1"
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
<parent_bpki_ta>
WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
</parent_bpki_ta>
<offer/>
</parent_response>
---------------------------------------------------------------------
</artwork></figure><!-- End inclusion: example.parent_response.Alice.xml -->
<!-- Begin inclusion: example.parent_response.Bob.xml --><figure><artwork>
---------------------------------------------------------------------
<parent_response
child_handle="Carol"
parent_handle="Bob"
service_uri="http://bob.example/up-down/Bob/Carol"
version="1"
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
<parent_bpki_ta>
R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
</parent_bpki_ta>
<referral
referrer="Alice/Bob-42">
R28sIGxlbW1pbmdzLCBnbyE=
</referral>
</parent_response>
---------------------------------------------------------------------
</artwork></figure><!-- End inclusion: example.parent_response.Bob.xml -->
</section>
<section title="<publisher_request/>" anchor="publisher_request">
<t>
The <publisher_request/> message is a setup request
from a publisher to a repository.
</t>
<t>
Fields in the <publisher_request/> message:
<list style="hanging">
<t hangText="version:">
The version attribute specifies the protocol version.
This note describes protocol version 1.
</t>
<t hangText="publisher_handle:">
The publisher_handle attribute is the publisher's name
for itself. This is just a hint, the repository need
not honor it.
</t>
<t hangText="publisher_bpki_ta:">
The <publisher_bpki_ta/> element is the
publisher's BPKI identity, a self-signed X.509 BPKI
certificate. This certificate is the issuer of the
BPKI EE certificates corresponding to private keys
that the publisher will use to sign publication
protocol messages to the repository.
</t>
<t hangText="referral:">
If a <referral/> element is present, it contains:
<list style="hanging">
<t hangText="referrer:">
A referrer attribute containing the publication
handle of the referring parent, and
</t>
<t hangText="Authorization token:">
The text of the <referral/> element is the
Base64 encoding of a signed authorization token
granting the publisher the right to use a portion
of its parent's namespace at this repository. See
<xref target="authorization"/> for details on the
authorization token.
</t>
</list>
These fields are copies of values that a parent
provided to the child in the <parent_response/>
message (see <xref target="parent_response"/>).
The referrer attribute is present to aid lookup of the
corresponding certificate by the repository.
Note that the repository operator makes the final
decision on whether to grant publication service to
the prospective publisher. The <referral/>
element just conveys a parent's grant of permission to
use a portion of that parent's namespace.
</t>
</list>
</t>
<!-- Begin inclusion: example.publisher_request.Bob.xml --><figure><artwork>
---------------------------------------------------------------------
<publisher_request
publisher_handle="Bob"
version="1"
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
<publisher_bpki_ta>
R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
</publisher_bpki_ta>
</publisher_request>
---------------------------------------------------------------------
</artwork></figure><!-- End inclusion: example.publisher_request.Bob.xml -->
</section>
<section title="<repository_response/>" anchor="repository_response">
<t>
The <repository_response/> message is a repository's
response to a publisher which has previously sent a
<publisher_request/> message.
</t>
<t>
Fields in the <repository_response/> message:
<list style="hanging">
<t hangText="version:">
The version attribute specifies the protocol version.
This note describes protocol version 1.
</t>
<t hangText="service_uri:">
The service_uri attribute contains an HTTP URL that
the publisher should contact for publication service
(<xref target="I-D.ietf-sidr-publication"/>).
</t>
<t hangText="publisher_handle:">
The publisher_handle attribute is the repository's
name for the publisher. This may or may not match the
publisher_handle attribute in the publisher's
<publisher_request/> message.
</t>
<t hangText="sia_base:">
The sia_base attribute is the rsync:// URI for the
base of the publication space allocated to the
publisher.
</t>
<t hangText="rrdp_notification_uri:">
The optional rrdp_notification_uri attribute is the
URI for the RRDP notification file covering the
publication space allocated to the publisher
(<xref target="I-D.ietf-sidr-delta-protocol"/>).
</t>
<t hangText="repository_bpki_ta:">
The <repository_bpki_ta/> element is the
repository's BPKI identity, a self-signed X.509 BPKI
certificate.
</t>
</list>
</t>
<!-- Begin inclusion: example.repository_response.Alice.Bob-42.xml --><figure><artwork>
---------------------------------------------------------------------
<repository_response
publisher_handle="Alice/Bob-42"
rrdp_notification_uri="https://rpki.example/rrdp/notify.xml"
service_uri="http://a.example/publication/Alice/Bob-42"
sia_base="rsync://a.example/rpki/Alice/Bob-42/"
version="1"
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
<repository_bpki_ta>
WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
</repository_bpki_ta>
</repository_response>
---------------------------------------------------------------------
</artwork></figure><!-- End inclusion: example.repository_response.Alice.Bob-42.xml -->
</section>
</section>
<section title="<authorization/>" anchor="authorization">
<t>
The <authorization/> element is a separate message
which is signed with CMS, then included as the Base64
content of <referral/> elements in other messages.
</t>
<t>
The eContentType for the signed CMS message is id-ct-xml.
</t>
<t>
Fields in the <authorization/> element:
<list style="hanging">
<t hangText="version:">
The version attribute specifies the protocol version.
This note describes protocol version 1.
</t>
<t hangText="authorized_sia_base:">
The value of the authorized_sia_base attribute is the
rsync:// URI of the base of the namespace which the
referrer is delegating.
</t>
<t hangText="bpki_ta:">
The <bpki_ta/> element is the identity of the
entity to whom the referrer is delegating the portion of
the namespace named in the authorized_sia_base
attribute. The identity is represented as a self-signed
X.509 BPKI certificate.
</t>
</list>
</t>
<!-- Begin inclusion: example.authorization.xml --><figure><artwork>
---------------------------------------------------------------------
<authorization
authorized_sia_base="rsync://a.example/rpki/Alice/Bob-42/Carol/"
version="1"
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
</authorization>
---------------------------------------------------------------------
</artwork></figure><!-- End inclusion: example.authorization.xml -->
</section>
<section title="<error/>" anchor="error">
<t>
The <error/> element is an optional message which can
be used in response to any of the core protocol messages
described in <xref target="protocol-messages"/>.
</t>
<t>
Whether an <error/> element is an appropriate way to
signal errors back to the sender of a protocol message
depends on details of the implementation which are outside
this specification. For example, if this protocol is
embedded in a web portal interface which is designed to let
a human being upload and download these messages via upload
and download forms, a human-readable error message may be
more appropriate. On the other hand, a portal intended to
be driven by a robotic client might well want to use an
<error/> message to signal errors. Similar arguments
apply to non-web encapsulations (email, USB stick, ...); the
primary factor is likely to be whether the implementation
expects the error to be handled by a human being or by a
program.
</t>
<t>
Fields in the <error/> message:
<list style="hanging">
<t hangText="version:">
The version attribute specifies the protocol version.
This note describes protocol version 1.
</t>
<t hangText="reason:">
The reason attribute contains a code indicating what was
wrong with the message. This version of the protocol
defines the following codes:
<list style="hanging">
<t hangText="syntax-error:">
Receiver could not parse the offending message.
</t>
<t hangText="authentication-failure:">
Receiver could not authenticate the offending message.
</t>
<t hangText="refused:">
Receiver refused to perform the requested action.
</t>
</list>
</t>
<t hangText="Offending message:">
The <error/> element contains a verbatim copy of
the message to which this error applies.
</t>
</list>
</t>
<!-- Begin inclusion: example.error.child_request.Carol.xml --><figure><artwork>
---------------------------------------------------------------------
<error
reason="refused"
version="1"
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
<child_request
child_handle="Carol">
<child_bpki_ta>
SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
</child_bpki_ta>
</child_request>
</error>
---------------------------------------------------------------------
</artwork></figure><!-- End inclusion: example.error.child_request.Carol.xml -->
</section>
</section>
<section title="Protocol Walk-Through">
<t>
This section walks through a few simple examples of the
protocol in use, and stars our old friends, Alice, Bob, and
Carol. In this example, Alice is the root of a RPKI tree, Bob
wants to get address and ASN resources from Alice, and Carol
wants to get some of those resources in turn from Bob. Alice
offers publication service, which is used by all three.
</t>
<t>
Alice, Bob, and Carol each generates his or her own
self-signed BPKI certificate.
</t>
<t>
Bob constructs a <child_request/> message and sends it
to Alice:
</t>
<!-- Begin inclusion: example.child_request.Bob.xml --><figure><artwork>
---------------------------------------------------------------------
<child_request
child_handle="Bob"
version="1"
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
<child_bpki_ta>
R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
</child_bpki_ta>
</child_request>
---------------------------------------------------------------------
</artwork></figure><!-- End inclusion: example.child_request.Bob.xml -->
<t>
<list style="symbols">
<t>
Bob's preferred handle is "Bob", so Bob uses that when setting
child_handle.
</t>
<t>
<child_bpki_ta/> is Bob's self-signed BPKI
certificate.
</t>
</list>
</t>
<t>
Alice replies with a <parent_response/> message, but
Alice already has 41 other children named Bob, so she calls
this one "Bob-42". Alice's provisioning protocol server
happens to use a RESTful URL scheme so that it can find the
expected validation context for the provisioning protocol CMS
message just by looking at the URL, so the service URL she
provides to Bob includes both her name and Bob's. Alice
offers publication service, so she offers to let Bob use it;
Alice doesn't have to do this, she could just omit this and
leave Bob to find publication service on his own, but Alice is
trying to be helpful to her customer Bob. Bob doesn't have to
accept Alice's offer, but may choose to do so.
</t>
<!-- Begin inclusion: example.parent_response.Alice.xml --><figure><artwork>
---------------------------------------------------------------------
<parent_response
child_handle="Bob-42"
parent_handle="Alice"
service_uri="http://a.example/up-down/Alice/Bob-42"
version="1"
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
<parent_bpki_ta>
WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
</parent_bpki_ta>
<offer/>
</parent_response>
---------------------------------------------------------------------
</artwork></figure><!-- End inclusion: example.parent_response.Alice.xml -->
<t>
<list style="symbols">
<t>
<parent_bpki_ta/> is Alice's own self-signed BPKI
certificate.
</t>
</list>
</t>
<t>
Bob receives Alice's <parent_response/> and extracts the
fields Bob's RPKI engine will need to know about
(child_handle, parent_handle, service_uri, and
<parent_bpki_ta/>). Bob also sees the repository offer,
decides to take Alice up on this offer, and constructs a
<publisher_request/> message accordingly:
</t>
<!-- Begin inclusion: example.publisher_request.Bob.xml --><figure><artwork>
---------------------------------------------------------------------
<publisher_request
publisher_handle="Bob"
version="1"
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
<publisher_bpki_ta>
R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
</publisher_bpki_ta>
</publisher_request>
---------------------------------------------------------------------
</artwork></figure><!-- End inclusion: example.publisher_request.Bob.xml -->
<t>
Alice receives Bob's request to use Alice's publication
service, decides to honor the offer she made, and sends back a
<repository_response/> message in response. Alice
recognizes Bob as one of her own children, because she's
already seen Bob's self-signed BPKI certificate, so she
allocates publication space to Bob under her own publication
space, so that relying parties who rsync her products will
pick up Bob's products automatically without needing an
additional fetch operation.
</t>
<!-- Begin inclusion: example.repository_response.Alice.Bob-42.xml --><figure><artwork>
---------------------------------------------------------------------
<repository_response
publisher_handle="Alice/Bob-42"
rrdp_notification_uri="https://rpki.example/rrdp/notify.xml"
service_uri="http://a.example/publication/Alice/Bob-42"
sia_base="rsync://a.example/rpki/Alice/Bob-42/"
version="1"
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
<repository_bpki_ta>
WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
</repository_bpki_ta>
</repository_response>
---------------------------------------------------------------------
</artwork></figure><!-- End inclusion: example.repository_response.Alice.Bob-42.xml -->
<t>
Bob should now have everything he needs to talk to Alice both
for provisioning and for publication.
</t>
<t>
A more interesting case is Bob's child, Carol. Carol wants to
get her resources from Bob, and, like Bob, does not
particularly want to operate a publication service. Bob
doesn't have a publication service of his own to offer, but he
can refer Carol to Alice, along with his permission for Carol
to use a portion of the namespace that Alice gave him.
</t>
<t>
Carol's <child_request/> to Bob looks very similar to
Bob's earlier request to Alice:
</t>
<!-- Begin inclusion: example.child_request.Carol.xml --><figure><artwork>
---------------------------------------------------------------------
<child_request
child_handle="Carol"
version="1"
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
<child_bpki_ta>
SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
</child_bpki_ta>
</child_request>
---------------------------------------------------------------------
</artwork></figure><!-- End inclusion: example.child_request.Carol.xml -->
<t>
Bob's <parent_response/> to Carol also looks a lot like
Alice's response to Bob, except that Bob includes a
<referral/> element instead of an <offer/>
element. Carol is an only child, so Bob leaves her name
alone:
</t>
<!-- Begin inclusion: example.parent_response.Bob.xml --><figure><artwork>
---------------------------------------------------------------------
<parent_response
child_handle="Carol"
parent_handle="Bob"
service_uri="http://bob.example/up-down/Bob/Carol"
version="1"
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
<parent_bpki_ta>
R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
</parent_bpki_ta>
<referral
referrer="Alice/Bob-42">
R28sIGxlbW1pbmdzLCBnbyE=
</referral>
</parent_response>
---------------------------------------------------------------------
</artwork></figure><!-- End inclusion: example.parent_response.Bob.xml -->
<t>
Bob's response includes a <referral/> element with a
referrer attribute of "Alice/Bob-42", since that's Bob's name
to Alice's repository. The Base64-encoded authorization token
is an <authorization/> element in a CMS message that can
be verified against Bob's self-signed BPKI certificate, using
a BPKI EE certificate included in the CMS wrapper. The
<authorization/> text is Carol's self-signed BPKI
certificate; Bob's signature over this element indicates Bob's
permission for Carol to use the indicated portion of Bob's
publication space.
</t>
<!-- Begin inclusion: example.authorization.xml --><figure><artwork>
---------------------------------------------------------------------
<authorization
authorized_sia_base="rsync://a.example/rpki/Alice/Bob-42/Carol/"
version="1"
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
</authorization>
---------------------------------------------------------------------
</artwork></figure><!-- End inclusion: example.authorization.xml -->
<t>
Carol, not wanting to have to run a publication service,
presents Bob's referral to Alice in the hope that Alice will
let Carol use Alice's publication service. So Carol
constructs a <publisher_request/> message
including the referral information received from Bob, and
sends it all to Alice:
</t>
<!-- Begin inclusion: example.publisher_request.Carol.xml --><figure><artwork>
---------------------------------------------------------------------
<publisher_request
publisher_handle="Carol"
version="1"
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
<publisher_bpki_ta>
SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
</publisher_bpki_ta>
<referral
referrer="Alice/Bob-42">
R28sIGxlbW1pbmdzLCBnbyE=
</referral>
</publisher_request>
---------------------------------------------------------------------
</artwork></figure><!-- End inclusion: example.publisher_request.Carol.xml -->
<t>
Alice sees the signed authorization token Bob gave to Carol,
checks its signature, and unpacks it. When the signature
proves valid and the contained BPKI TA matches Carol's, Alice
knows that Bob is willing to let Carol use a portion of Bob's
namespace. Given this, Alice is willing to provide
publication service to Carol in the subtree allocated by Bob
for this purpose, so Alice sends back a
<repository_response/>:
</t>
<!-- Begin inclusion: example.repository_response.Alice.Bob-42.Carol.xml --><figure><artwork>
---------------------------------------------------------------------
<repository_response
publisher_handle="Alice/Bob-42/Carol"
service_uri="http://a.example/publication/Alice/Bob-42/Carol"
sia_base="rsync://a.example/rpki/Alice/Bob-42/Carol/"
version="1"
xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
<repository_bpki_ta>
WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
</repository_bpki_ta>
</repository_response>
---------------------------------------------------------------------
</artwork></figure><!-- End inclusion: example.repository_response.Alice.Bob-42.Carol.xml -->
<t>
Once Carol receives this response, Carol should be good to go.
</t>
<t>
In theory the publication referral mechanism can extend
indefinitely (for example, Carol can refer her child Dave to
Alice for publication service and it should all work). In
practice, this has not yet been implemented, much less tested.
In order to keep the protocol relatively simple, we've
deliberately ignored perverse cases such as Bob being willing
to refer Carol to Alice but not wanting Carol to be allowed to
refer Dave to Alice.
</t>
</section>
<section title="IANA Considerations">
<t>
Blah.
</t>
</section>
<section title="Security Considerations">
<t>
As stated in <xref target="introduction"/>, the basic function
of this protocol is an exchange of public keys to be used as
BPKI trust anchors. Integrity and authentication of these
exchanges MUST be ensured via external mechanisms deliberately
left unspecified in this protocol.
</t>
</section>
<section title="Acknowledgements">
<t>
The author would like to thank:
Byron Ellacott,
George Michaelson,
Leif Johansson,
Matsuzaki Yoshinobu,
Michael Elkins,
Randy Bush,
Seiichi Kawamura,
Tim Bruijnzeels,
and anybody else who helped along the way whose name the
author has temporarily forgotten.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<!-- Begin inclusion: reference.I-D.ietf-sidr-publication.xml --><!-- Automatically generated, do not edit. --><reference anchor="I-D.ietf-sidr-publication">
<front>
<title>A Publication Protocol for the Resource Public Key Infrastructure (RPKI)</title>
<author initials="S." surname="Weiler" fullname="Samuel Weiler"><organization/></author>
<author initials="A." surname="Sonalker" fullname="Anuja Sonalker"><organization/></author>
<author initials="R." surname="Austein" fullname="Rob Austein"><organization/></author>
<date day="25" month="September" year="2015"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-sidr-publication-07"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-sidr-publication-07.txt"/>
</reference><!-- End inclusion: reference.I-D.ietf-sidr-publication.xml -->
<!-- Begin inclusion: reference.I-D.ietf-sidr-delta-protocol.xml --><!-- Automatically generated, do not edit. --><reference anchor="I-D.ietf-sidr-delta-protocol">
<front>
<title>RPKI Repository Delta Protocol</title>
<author initials="T." surname="Bruijnzeels" fullname="Tim Bruijnzeels"><organization/></author>
<author initials="O." surname="Muravskiy" fullname="Oleg Muravskiy"><organization/></author>
<author initials="B." surname="Weber" fullname="Bryan Weber"><organization/></author>
<author initials="R." surname="Austein" fullname="Rob Austein"><organization/></author>
<author initials="D." surname="Mandelberg" fullname="David Mandelberg"><organization/></author>
<date day="19" month="October" year="2015"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-sidr-delta-protocol-01"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-sidr-delta-protocol-01.txt"/>
</reference><!-- End inclusion: reference.I-D.ietf-sidr-delta-protocol.xml -->
<!-- Begin inclusion: reference.RFC.6492.xml --><reference anchor="RFC6492">
<front>
<title>A Protocol for Provisioning Resource Certificates</title>
<author fullname="G. Huston" initials="G." surname="Huston">
<organization/>
</author>
<author fullname="R. Loomans" initials="R." surname="Loomans">
<organization/>
</author>
<author fullname="B. Ellacott" initials="B." surname="Ellacott">
<organization/>
</author>
<author fullname="R. Austein" initials="R." surname="Austein">
<organization/>
</author>
<date month="February" year="2012"/>
<keyword>RPKI</keyword>
<abstract>
<t>This document defines a framework for certificate management interactions between an Internet Number Resource issuer ("issuer") and an Internet Number Resource recipient ("subject") through the specification of a protocol for interaction between the two parties. The protocol supports the transmission of requests from the subject, and corresponding responses from the issuer encompassing the actions of certificate issuance, certificate revocation, and certificate status information reports. This protocol is intended to be limited to the application of Internet Number Resource Certificate management and is not intended to be used as part of a more general certificate management framework. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6492"/>
<format type="TXT" octets="65896" target="http://www.rfc-editor.org/rfc/rfc6492.txt"/>
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference><!-- End inclusion: reference.RFC.6492.xml -->
<!-- Begin inclusion: reference.RFC.5280.xml --><reference anchor="RFC5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author fullname="D. Cooper" initials="D." surname="Cooper">
<organization/>
</author>
<author fullname="S. Santesson" initials="S." surname="Santesson">
<organization/>
</author>
<author fullname="S. Farrell" initials="S." surname="Farrell">
<organization/>
</author>
<author fullname="S. Boeyen" initials="S." surname="Boeyen">
<organization/>
</author>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization/>
</author>
<author fullname="W. Polk" initials="W." surname="Polk">
<organization/>
</author>
<date month="May" year="2008"/>
<keyword>X.509 v3</keyword>
<keyword>X.509 v2</keyword>
<keyword>certificate extensions</keyword>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5280"/>
<format type="TXT" octets="352580" target="http://www.rfc-editor.org/rfc/rfc5280.txt"/>
<!-- obsoletes RFC3280 RFC4325 RFC4630 -->
<!-- updated-by RFC6818 -->
<!-- current-status PROPOSED STANDARD -->
<!-- publication-status PROPOSED STANDARD -->
</reference><!-- End inclusion: reference.RFC.5280.xml -->
<!-- Begin inclusion: reference.RFC.5652.xml --><reference anchor="RFC5652">
<front>
<title>Cryptographic Message Syntax (CMS)</title>
<author fullname="R. Housley" initials="R." surname="Housley">
<organization/>
</author>
<date month="September" year="2009"/>
<keyword>digital signature</keyword>
<keyword>message content</keyword>
<abstract>
<t>This document describes the Cryptographic Message Syntax (CMS). This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5652"/>
<seriesInfo name="STD" value="70"/>
<format type="TXT" octets="126813" target="http://www.rfc-editor.org/rfc/rfc5652.txt"/>
<!-- obsoletes RFC3852 -->
<!-- current-status INTERNET STANDARD -->
<!-- publication-status DRAFT STANDARD -->
</reference><!-- End inclusion: reference.RFC.5652.xml -->
</references>
<!-- <references title="Informative References"/> -->
<!-- RelaxNG Schema specification is at: -->
<!-- http://www.relaxng.org/compact-20021121.html -->
<section title="RelaxNG Schema">
<t>
Here is a RelaxNG schema describing the protocol elements.
</t>
<!-- Begin inclusion: rpki-setup.xml --><figure><artwork># $Id: rpki-setup.rnc 3429 2015-10-14 23:46:50Z sra $
default namespace = "http://www.hactrn.net/uris/rpki/rpki-setup/"
version = "1"
base64 = xsd:base64Binary { maxLength="512000" }
handle = xsd:string { maxLength="255" pattern="[\-_A-Za-z0-9/]*" }
uri = xsd:anyURI { maxLength="4096" }
any = element * { attribute * { text }*, ( any | text )* }
authorization_token = base64
bpki_ta = base64
start |= element child_request {
attribute version { version },
attribute child_handle { handle },
element child_bpki_ta { bpki_ta }
}
start |= element parent_response {
attribute version { version },
attribute service_uri { uri },
attribute child_handle { handle },
attribute parent_handle { handle },
element parent_bpki_ta { bpki_ta },
element offer { empty }?,
element referral {
attribute referrer { handle },
attribute contact_uri { uri }?,
authorization_token
}*
}
start |= element publisher_request {
attribute version { version },
attribute publisher_handle { handle },
element publisher_bpki_ta { bpki_ta },
element referral {
attribute referrer { handle },
authorization_token
}*
}
start |= element repository_response {
attribute version { version },
attribute service_uri { uri },
attribute publisher_handle { handle },
attribute sia_base { uri },
attribute rrdp_notification_uri { uri }?,
element repository_bpki_ta { bpki_ta }
}
start |= element authorization {
attribute version { version },
attribute authorized_sia_base { uri },
bpki_ta
}
start |= element error {
attribute version { version },
attribute reason {
"syntax-error" |
"authentication-failure" |
"refused"
},
any?
}
</artwork></figure><!-- End inclusion: rpki-setup.xml -->
</section>
</back>
</rfc><!--
- Local Variables:
- mode:sgml
- mode:flyspell
- indent-tabs-mode: nil
- End:
-->
| PAFTECH AB 2003-2026 | 2026-04-22 22:57:39 |