From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6493.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc6493.txt (limited to 'doc/rfc/rfc6493.txt') 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 + Intended usage: COMMON + Restrictions on usage: None + Author: Randy Bush + Change controller: Randy Bush + +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] + -- cgit v1.2.3