summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6493.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6493.txt')
-rw-r--r--doc/rfc/rfc6493.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc6493.txt b/doc/rfc/rfc6493.txt
new file mode 100644
index 0000000..1e8a9a9
--- /dev/null
+++ b/doc/rfc/rfc6493.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) R. Bush
+Request for Comments: 6493 Internet Initiative Japan
+Category: Standards Track February 2012
+ISSN: 2070-1721
+
+
+ The Resource Public Key Infrastructure (RPKI) Ghostbusters Record
+
+Abstract
+
+ In the Resource Public Key Infrastructure (RPKI), resource
+ certificates completely obscure names or any other information that
+ might be useful for contacting responsible parties to deal with
+ issues of certificate expiration, maintenance, roll-overs,
+ compromises, etc. This document describes the RPKI Ghostbusters
+ Record containing human contact information that may be verified
+ (indirectly) by a Certification Authority (CA) certificate. The data
+ in the record are those of a severely profiled vCard.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6493.
+
+Copyright Notice
+
+ Copyright (c) 2012 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 as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+Bush Standards Track [Page 1]
+
+RFC 6493 RPKI Ghostbusters Record February 2012
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
+ 3. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . 3
+ 4. RPKI Ghostbusters Record Payload Example . . . . . . . . . . . 4
+ 5. vCard Profile . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 6. CMS Packaging . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 7. Validation . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+ 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
+ 9.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 9.2. File Extension . . . . . . . . . . . . . . . . . . . . . . 6
+ 9.3. Media Type . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 11.1. Normative References . . . . . . . . . . . . . . . . . . . 7
+ 11.2. Informative References . . . . . . . . . . . . . . . . . . 8
+
+1. Introduction
+
+ In the operational use of the RPKI, it can become necessary to
+ contact, human to human, the party responsible for a resource-holding
+ CA certificate, AKA the certificate's maintainer, be it the holder of
+ the certificate's private key or an administrative person in the
+ organization, a NOC, etc. An important example is when the operator
+ of a prefix described by a Route Origin Authorization (ROA) sees a
+ problem, or an impending problem, with a certificate or Certificate
+ Revocation List (CRL) in the path between the ROA and a trust anchor.
+ For example, a certificate along that path has expired, is soon to
+ expire, or a CRL associated with a CA along the path is stale, thus
+ placing the quality of the routing of the address space described by
+ the ROA in jeopardy.
+
+ As the names in RPKI certificates are not meaningful to humans, see
+ [RFC6484], there is no way to use a certificate itself to lead to the
+ worrisome certificate's or CRL's maintainer. So, "Who you gonna
+ call?"
+
+ This document specifies the RPKI Ghostbusters Record, an object
+ verified via an end-entity (EE) certificate, issued under a CA
+ certificate, the maintainer of which may be contacted using the
+ payload information in the Ghostbusters Record.
+
+ The Ghostbusters Record conforms to the syntax defined in [RFC6488].
+ The payload of this signed object is a severely profiled vCard.
+
+
+
+
+
+Bush Standards Track [Page 2]
+
+RFC 6493 RPKI Ghostbusters Record February 2012
+
+
+ Note that the Ghostbusters Record is not an identity certificate, but
+ rather an attestation to the contact data made by the maintainer of
+ the CA certificate issuing the EE certificate whose corresponding
+ private key signs the Ghostbusters Record.
+
+ This record is not meant to supplant or be used as resource registry
+ whois data. It gives information about an RPKI CA certificate
+ maintainer, not a resource holder.
+
+ The Ghostbusters Record is optional; CA certificates in the RPKI can
+ have zero or more associated Ghostbuster Records.
+
+ Given a certificate, to find the closest Ghostbuster Record, go up
+ until a CA certificate is reached, which may be the object itself of
+ course. That CA certificate will have Subject Information Access
+ (SIA) to the publication point where all subsidiary objects (until
+ you hit a down-chain CA certificate's signed objects) are published.
+ The publication point will contain zero or more Ghostbuster Records.
+
+ This specification has three main sections. The first, Section 5, is
+ the format of the contact payload information, a severely profiled
+ vCard. The second, Section 6, profiles the packaging of the payload
+ as a profile of the RPKI Signed Object Template specification
+ [RFC6488]. The third, Section 7, describes the proper validation of
+ the signed Ghostbusters Record.
+
+2. Requirements Language
+
+ 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].
+
+3. Suggested Reading
+
+ It is assumed that the reader understands the RPKI [RFC6480], the
+ RPKI Repository Structure [RFC6481], Signed RPKI Objects [RFC6488],
+ and vCards [RFC6350].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush Standards Track [Page 3]
+
+RFC 6493 RPKI Ghostbusters Record February 2012
+
+
+4. RPKI Ghostbusters Record Payload Example
+
+ An example of an RPKI Ghostbusters Record payload with all properties
+ populated is as follows:
+
+ BEGIN:VCARD
+ VERSION:4.0
+ FN:Human's Name
+ ORG:Organizational Entity
+ ADR;TYPE=WORK:;;42 Twisty Passage;Deep Cavern;WA;98666;U.S.A.
+ TEL;TYPE=VOICE,TEXT,WORK;VALUE=uri:tel:+1-666-555-1212
+ TEL;TYPE=FAX,WORK;VALUE=uri:tel:+1-666-555-1213
+ EMAIL:human@example.com
+ END:VCARD
+
+5. vCard Profile
+
+ The goal in profiling the vCard is not to include as much information
+ as possible, but rather to include as few properties as possible
+ while providing the minimal necessary data to enable one to contact
+ the maintainer of the RPKI data that threatens the ROA[s] of concern.
+
+ The Ghostbusters vCard payload is a minimalist subset of the vCard as
+ described in [RFC6350].
+
+ BEGIN - pro forma packaging that MUST be the first line in the vCard
+ and MUST have the value "BEGIN:VCARD" as described in [RFC6350].
+
+ VERSION - pro forma packaging that MUST be the second line in the
+ vCard and MUST have the value "VERSION:4.0" as described in
+ Section 3.7.9 of [RFC6350].
+
+ FN - the name, as described in Section 6.2.1 of [RFC6350], of a
+ contactable person or role who is responsible for the CA
+ certificate.
+
+ ORG - an organization as described in Section 6.6.4 of [RFC6350].
+
+ ADR - a postal address as described in Section 6.3 of [RFC6350].
+
+ TEL - a voice and/or fax phone as described in Section 6.4.1 of
+ [RFC6350].
+
+ EMAIL - an Email address as described in Section 6.4.2 of [RFC6350]
+
+ END - pro forma packaging that MUST be the last line in the vCard
+ and MUST have the value "END:VCARD" as described in [RFC6350].
+
+
+
+
+Bush Standards Track [Page 4]
+
+RFC 6493 RPKI Ghostbusters Record February 2012
+
+
+ Per [RFC6350], the BEGIN, VERSION, FN, and END properties MUST be
+ included in a record. To be useful, at least one of ADR, TEL, and
+ EMAIL MUST be included. Other properties MUST NOT be included.
+
+6. CMS Packaging
+
+ The Ghostbusters Record is a CMS signed-data object conforming to the
+ "Signed Object Template for the Resource Public Key Infrastructure
+ (RPKI)", [RFC6488].
+
+ The content-type of a Ghostbusters Record is defined as id-ct-
+ rpkiGhostbusters, and has the numerical value of
+ 1.2.840.113549.1.9.16.1.35. This OID MUST appear both within the
+ eContentType in the encapContentInfo object as well as the content-
+ type signed attribute in the signerInfo object. See [RFC6488].
+
+ eContent: The content of a Ghostbusters Record is described in
+ Section 5.
+
+ Similarly to a ROA, a Ghostbusters Record is verified using an EE
+ certificate issued by the resource-holding CA certificate whose
+ maintainer is described in the vCard.
+
+ The EE certificate used to verify the Ghostbusters Record is the one
+ that appears in the CMS data structure that contains the payload
+ defined above.
+
+ This EE certificate MUST describe its Internet Number Resources using
+ the "inherit" attribute, rather than explicit description of a
+ resource set; see [RFC3779].
+
+7. Validation
+
+ The validation procedure defined in Section 3 of [RFC6488] is applied
+ to a Ghostbusters Record. After this procedure has been performed,
+ the Version number type within the payload is checked, and the OCTET
+ STRING containing the vCard data is extracted. These data are
+ checked against the profile defined in Section 5 of this document.
+ Only if all of these checks pass is the Ghostbusters payload deemed
+ valid and made available to the application that requested the
+ payload.
+
+
+
+
+
+
+
+
+
+
+Bush Standards Track [Page 5]
+
+RFC 6493 RPKI Ghostbusters Record February 2012
+
+
+8. Security Considerations
+
+ Though there is no on-the-wire protocol in this specification, there
+ are attacks that could abuse the data described. As the data, to be
+ useful, need to be public, little can be done to avoid this exposure.
+
+ Phone Numbers: The vCards may contain real world telephone numbers,
+ which could be abused for telemarketing, abusive calls, etc.
+
+ Email Addresses: The vCards may contain Email addresses, which could
+ be abused for purposes of spam.
+
+ Relying parties are hereby warned that the data in a Ghostbusters
+ Record are self-asserted. These data have not been verified by the
+ CA that issued the CA certificate to the entity that issued the EE
+ certificate used to validate the Ghostbusters Record.
+
+9. IANA Considerations
+
+9.1. OID
+
+ The IANA has registered the OID for the Ghostbusters Record in the
+ registry created by [RFC6488] as follows:
+
+ Name OID Specification
+ -----------------------------------------------------------
+ Ghostbusters 1.2.840.113549.1.9.16.1.35 [RFC6493]
+
+9.2. File Extension
+
+ Realizing the deep issues raised by [RFC5513], the IANA has added an
+ item for the Ghostbusters Record file extension to the "RPKI
+ Repository Name Scheme" created by [RFC6481] as follows:
+
+ Filename Extension RPKI Object Reference
+ -----------------------------------------------------------
+ .gbr Ghostbusters Record [RFC6493]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush Standards Track [Page 6]
+
+RFC 6493 RPKI Ghostbusters Record February 2012
+
+
+9.3. Media Type
+
+ The IANA has registered the media type application/rpki-ghostbusters
+ as follows:
+
+ Type name: application
+ Subtype name: rpki-ghostbusters
+ Required parameters: None
+ Optional parameters: None
+ Encoding considerations: binary
+ Security considerations: Carries an RPKI Ghostbusters Record
+ [RFC6493].
+ Interoperability considerations: None
+ Published specification: This document.
+ Applications that use this media type: RPKI administrators.
+ Additional information:
+ Content: This media type is a signed object, as defined
+ in [RFC6488], which contains a payload
+ of a profiled vCard as defined above in this document.
+ Magic number(s): None
+ File extension(s): .gbr
+ Macintosh file type code(s):
+ Person & email address to contact for further information:
+ Randy Bush <randy@psg.com>
+ Intended usage: COMMON
+ Restrictions on usage: None
+ Author: Randy Bush <randy@psg.com>
+ Change controller: Randy Bush <randy@psg.com>
+
+10. Acknowledgments
+
+ The author wishes to thank Russ Housley, the authors of [RFC6481],
+ Stephen Kent, Sandy Murphy, Rob Austein, Michael Elkins, and Barry
+ Leiba for their contributions.
+
+11. References
+
+11.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
+ Addresses and AS Identifiers", RFC 3779, June 2004.
+
+ [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
+ August 2011.
+
+
+
+
+Bush Standards Track [Page 7]
+
+RFC 6493 RPKI Ghostbusters Record February 2012
+
+
+ [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
+ Resource Certificate Repository Structure", RFC 6481,
+ February 2012.
+
+ [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
+ Template for the Resource Public Key Infrastructure
+ (RPKI)", RFC 6488, February 2012.
+
+11.2. Informative References
+
+ [RFC5513] Farrel, A., "IANA Considerations for Three Letter
+ Acronyms", RFC 5513, April 1 2009.
+
+ [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
+ Secure Internet Routing", RFC 6480, February 2012.
+
+ [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate
+ Policy (CP) for the Resource Public Key Infrastructure
+ (RPKI)"", RFC 6484, February 2012.
+
+Author's Address
+
+ Randy Bush
+ Internet Initiative Japan
+ 5147 Crystal Springs
+ Bainbridge Island, Washington 98110
+ US
+
+ Phone: +1 206 780 0431 x1
+ EMail: randy@psg.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush Standards Track [Page 8]
+