draft-ietf-sidr-rpki-oob-setup-08.txt   draft-ietf-sidr-rpki-oob-setup-09.txt 
Network Working Group R. Austein Network Working Group R. Austein
Internet-Draft Dragon Research Labs Internet-Draft Dragon Research Labs
Intended status: Standards Track February 22, 2017 Intended status: Standards Track February 22, 2017
Expires: August 26, 2017 Expires: August 26, 2017
An Out-Of-Band Setup Protocol For RPKI Production Services An Out-Of-Band Setup Protocol For RPKI Production Services
draft-ietf-sidr-rpki-oob-setup-08 draft-ietf-sidr-rpki-oob-setup-09
Abstract Abstract
This note describes a simple out-of-band protocol to ease setup of This note describes a simple out-of-band protocol to ease setup of
the RPKI provisioning and publication protocols between two parties. the RPKI provisioning and publication protocols between two parties.
The protocol is encoded in a small number of XML messages, which can The protocol is encoded in a small number of XML messages, which can
be passed back and forth by any mutually agreeable means which be passed back and forth by any mutually agreeable means which
provides acceptable data integrity and authentication. provides acceptable data integrity and authentication.
This setup protocol is not part of the provisioning or publication This setup protocol is not part of the provisioning or publication
skipping to change at page 6, line 26 skipping to change at page 6, line 26
Since "1" is currently the only value allowed for the version Since "1" is currently the only value allowed for the version
attribute in the schema, an incorrect protocol version can be attribute in the schema, an incorrect protocol version can be
detected either by checking the version attribute directly or as a detected either by checking the version attribute directly or as a
schema validation error. schema validation error.
5.1. Common Protocol Elements 5.1. Common Protocol Elements
Most messages contain, among other things, a self-signed BPKI X.509 Most messages contain, among other things, a self-signed BPKI X.509
certificate. These certificates are represented as XML elements certificate. These certificates are represented as XML elements
whose text value is the Base64 text encoding the DER representation whose text value is the Base64 text ([RFC4648] section 4, with line
of the X.509 certificate. breaks within the Base64 text permitted but not required) encoding
the DER representation of the X.509 certificate.
A number of attributes contain "handles". A handle in this protocol A number of attributes contain "handles". A handle in this protocol
is a text string in the US-ASCII character set consisting of letters, is a text string in the US-ASCII character set consisting of letters,
digits, and the special characters "/", "-", and "_". This protocol digits, and the special characters "/", "-", and "_". This protocol
places no special semantics on the structure of these handles, places no special semantics on the structure of these handles,
although implementations might. Handles are protocol elements, not although implementations might. Handles are protocol elements, not
necessarily meaningful to humans, thus the simplicity of a restricted necessarily meaningful to humans, thus the simplicity of a restricted
character set makes more sense than the complex rules which would be character set makes more sense than the complex rules which would be
needed for internationalized text. needed for internationalized text.
skipping to change at page 8, line 7 skipping to change at page 8, line 7
Fields in the <parent_response/> message: Fields in the <parent_response/> message:
version: The version attribute specifies the protocol version. This version: The version attribute specifies the protocol version. This
note describes protocol version 1. note describes protocol version 1.
tag: If the <child_request/> message included a "tag" attribute, the tag: If the <child_request/> message included a "tag" attribute, the
parent MUST include an identical "tag" attribute in the parent MUST include an identical "tag" attribute in the
<parent_response/> message; if the request did not include a tag <parent_response/> message; if the request did not include a tag
attribute, the response MUST NOT include a tag attribute either. attribute, the response MUST NOT include a tag attribute either.
service_uri: The service_uri attribute contains an HTTP URL that the service_uri: The service_uri attribute contains an HTTP or HTTPS URL
child should contact for up-down ([RFC6492]) service. ([RFC7230]) that the child should contact for up-down ([RFC6492])
service.
child_handle: The child_handle attribute is the parent's name for child_handle: The child_handle attribute is the parent's name for
the child. This MAY match the child_handle from the the child. This MAY match the child_handle from the
<child_request/> message. If they do not match, the parent wins, <child_request/> message. If they do not match, the parent wins,
because the parent gets to dictate the names in the provisioning because the parent gets to dictate the names in the provisioning
protocol. This value is the sender field in provisioning protocol protocol. This value is the sender field in provisioning protocol
request messages and the recipient field in provisioning protocol request messages and the recipient field in provisioning protocol
response messages. response messages.
parent_handle: The parent_handle attribute is the parent's name for parent_handle: The parent_handle attribute is the parent's name for
skipping to change at page 11, line 21 skipping to change at page 11, line 21
version: The version attribute specifies the protocol version. This version: The version attribute specifies the protocol version. This
note describes protocol version 1. note describes protocol version 1.
tag: If the <publisher_request/> message included a "tag" attribute, tag: If the <publisher_request/> message included a "tag" attribute,
the repository MUST include an identical "tag" attribute in the the repository MUST include an identical "tag" attribute in the
<repository_response/> message; if the request did not include a <repository_response/> message; if the request did not include a
tag attribute, the response MUST NOT include a tag attribute tag attribute, the response MUST NOT include a tag attribute
either. either.
service_uri: The service_uri attribute contains an HTTP URL that the service_uri: The service_uri attribute contains an HTTP or HTTPS URL
publisher should contact for publication service ([RFC7230]) that the publisher should contact for publication
([I-D.ietf-sidr-publication]). service ([I-D.ietf-sidr-publication]).
publisher_handle: The publisher_handle attribute is the repository's publisher_handle: The publisher_handle attribute is the repository's
name for the publisher. This may or may not match the name for the publisher. This may or may not match the
publisher_handle attribute in the publisher's <publisher_request/> publisher_handle attribute in the publisher's <publisher_request/>
message. message.
sia_base: The sia_base attribute is the rsync:// URI for the base of sia_base: The sia_base attribute is the rsync:// URI for the base of
the publication space allocated to the publisher. the publication space allocated to the publisher.
rrdp_notification_uri: The optional rrdp_notification_uri attribute rrdp_notification_uri: The optional rrdp_notification_uri attribute
skipping to change at page 12, line 26 skipping to change at page 12, line 26
</repository_bpki_ta> </repository_bpki_ta>
</repository_response> </repository_response>
--------------------------------------------------------------------- ---------------------------------------------------------------------
5.3. <authorization/> 5.3. <authorization/>
The <authorization/> element is a separate message which is signed The <authorization/> element is a separate message which is signed
with CMS, then included as the Base64 content of <referral/> elements with CMS, then included as the Base64 content of <referral/> elements
in other messages. in other messages.
The eContentType for the signed CMS message is id-ct-xml. The eContentType for the signed CMS message is id-ct-xml ([RFC6492]).
Fields in the <authorization/> element: Fields in the <authorization/> element:
version: The version attribute specifies the protocol version. This version: The version attribute specifies the protocol version. This
note describes protocol version 1. note describes protocol version 1.
authorized_sia_base: The value of the authorized_sia_base attribute authorized_sia_base: The value of the authorized_sia_base attribute
is the rsync:// URI of the base of the namespace which the is the rsync:// URI of the base of the namespace which the
referrer is delegating. referrer is delegating.
skipping to change at page 20, line 5 skipping to change at page 20, line 5
(RPKI)", draft-ietf-sidr-publication-11 (work in (RPKI)", draft-ietf-sidr-publication-11 (work in
progress), February 2017. progress), February 2017.
[RelaxNG] Clark, J., "RELAX NG Compact Syntax", OASIS , November [RelaxNG] Clark, J., "RELAX NG Compact Syntax", OASIS , November
2002, <https://www.oasis-open.org/committees/relax-ng/ 2002, <https://www.oasis-open.org/committees/relax-ng/
compact-20021121.html>. compact-20021121.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A
Protocol for Provisioning Resource Certificates", Protocol for Provisioning Resource Certificates",
RFC 6492, February 2012. RFC 6492, February 2012.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014.
10.2. Informative References 10.2. Informative References
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 5652, STD 70, September 2009. RFC 5652, STD 70, September 2009.
 End of changes. 7 change blocks. 
9 lines changed or deleted 18 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/