Secure Inter-Domain Routing Working GroupInternet Engineering Task Force (IETF) M. ReynoldsInternet-DraftRequest for Comments: 8209 IPSw Updates: 6487(if approved)S. TurnerIntended status: StandardCategory: Standards Track sn3rdExpires: July 9, 2017ISSN: 2070-1721 S. Kent BBNJanuary 5,September 2017 A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requestsdraft-ietf-sidr-bgpsec-pki-profiles-21Abstract This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is the standard for inter-domain routing in the Internet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. Theend-entityend entity (EE) certificates specified by this profile are issued to routers within anAutonomous System.AS. Each of these certificates is issued under a Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the ASIdentifier DelegationResource extension. An EE certificate of this type asserts that therouter(s)router or routers holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certificationrequests,requests and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends the RPKI; therefore, thisdocumentsdocument updates the RPKI Resource Certificates Profile (RFC 6487). Status ofthisThis Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 ofsix monthsRFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."https://www.rfc-editor.org/info/rfc8209. Copyright Notice Copyright (c) 2017 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)(https://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. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3....................................................3 1.1. Terminology. . . . . . . . . . . . . . . . . . . . . . . 3................................................4 2. Describing Resources in Certificates. . . . . . . . . . . . . 3............................4 3. Updates to[RFC6487] . . . . . . . . . . . . . . . . . . . . . 5 3.1RFC 6487 .............................................6 3.1. BGPsec Router Certificate Fields. . . . . . . . . . . . . 5...........................6 3.1.1. Subject. . . . . . . . . . . . . . . . . . . . . . . 5.............................................6 3.1.2. Subject Public Key Info. . . . . . . . . . . . . . . 5.............................6 3.1.3. BGPsec Router Certificate Version 3 Extension Fields. 5....................................6 3.1.3.1. Basic Constraints. . . . . . . . . . . . . . . . 5..........................6 3.1.3.2. Extended Key Usage. . . . . . . . . . . . . . . . 5.........................6 3.1.3.3. Subject Information Access. . . . . . . . . . . . 6.................7 3.1.3.4. IP Resources. . . . . . . . . . . . . . . . . . . 6...............................7 3.1.3.5. AS Resources. . . . . . . . . . . . . . . . . . . 6...............................7 3.2. BGPsec Router Certificate Request Profile. . . . . . . . 6..................7 3.3. BGPsec Router Certificate Validation. . . . . . . . . . . 7.......................8 3.4. Router Certificates and Signing Functions in the RPKI. . 7......8 4. Design Notes. . . . . . . . . . . . . . . . . . . . . . . . . 8....................................................9 5. Implementation Considerations. . . . . . . . . . . . . . . . . 8...................................9 6. Security Considerations. . . . . . . . . . . . . . . . . . . 9........................................10 7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 9............................................10 8.Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9.References. . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1......................................................11 8.1. Normative References. . . . . . . . . . . . . . . . . . . 10 9.2.......................................11 8.2. Informative References. . . . . . . . . . . . . . . . . . 11....................................12 Appendix A. ASN.1 Module. . . . . . . . . . . . . . . . . . . . 12..........................................14 Acknowledgements ..................................................15 Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 12................................................15 1. Introduction This document defines a profile for X.509end-entityend entity (EE) certificates [RFC5280] for use in the context of certification of Autonomous System (AS) paths in theBGPsec.BGPsec protocol. Such certificates are termed "BGPsec Router Certificates". The holder of the private key associated with a BGPsec Router Certificate is authorized to send secure route advertisements (BGPsec UPDATEs) on behalf of the AS(es) named in the certificate. A router holding the private key is authorized to send route advertisements (to its peers) identifying the router'sASNAS number (ASN) as the source of the advertisements. A key property provided by BGPsec is that every AS along the ASPATHpath can verify that the other ASes along the path have authorized the advertisement of the given route (to the next AS along the ASPATH).path). This document is a profile of [RFC6487], which is a profile of [RFC5280];thusthus, this document updates [RFC6487]. It establishes requirements imposed on a Resource Certificate that is used as a BGPsec Router Certificate, i.e., it defines constraints for certificate fields and extensions for the certificate to be valid in this context. This document also profiles the certification requests used to acquire BGPsec Router Certificates. Finally, this document specifies the Relying Party (RP) certificate path validation procedures for these certificates. 1.1. Terminology It is assumed that the reader is familiar with the terms and concepts described in "A Profile for X.509 PKIX Resource Certificates" [RFC6487], "BGPsec Protocol Specification"[ID.sidr-bgpsec-protocol],[RFC8205], "A Border Gateway Protocol 4 (BGP-4)" [RFC4271], "BGP Security Vulnerabilities Analysis" [RFC4272], "Considerations in Validating the Path in BGP" [RFC5123], and"Capability"Capabilities Advertisement with BGP-4" [RFC5492]. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in[RFC2119].BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Describing Resources in Certificates Figure 1 depicts some of the entities in theRPKIResource Public Key Infrastructure (RPKI) and some of the products generated by RPKI entities. IANA issues a Certification Authority (CA) certificate to each Regional Internet Registry (RIR). TheRIR,RIR inturn,turn issues a CA certificate to an Internet Service Provider (ISP). The ISP in turn issues EECertificatescertificates to itself to enable verification of signatures on RPKI signed objects. The CA also generates Certificate Revocation Lists (CRLs). These CA and EE certificates are referred to as "ResourceCertificates",Certificates" and are profiled in [RFC6487]. [RFC6480] envisioned using Resource Certificates to enable verification ofManifestsmanifests [RFC6486] and Route Origin Authorizations (ROAs) [RFC6482]. ROAs andManifestsmanifests include the Resource Certificates used to verify them. +---------+ +------+ | CA Cert |---| IANA | +---------+ +------+ \ +---------+ +-----+ | CA Cert |---| RIR | +---------+ +-----+ \ +---------+ +-----+ | CA Cert |---| ISP | +---------+ +-----+ / | | | +-----+ / | | | +-----+ | CRL |--+ | | +---| ROA | +-----+ | | +-----+ | | +----------+ +----+ | +---| Manifest | +-| EE |---+ +----------+ | +----+ +-----+ Figure 1 This document defines another type of Resource Certificate, which is referred to as a "BGPsec Router Certificate". The purpose of this certificate is explained in Section 1 and falls within the scope of appropriate uses defined within [RFC6484]. The issuance of BGPsec Router Certificates has minimal impact on RPKI CAs because the RPKI CA certificate and CRL profile remain unchanged (i.e., they are as specified in [RFC6487]). Further, the algorithms used to generate RPKI CA certificates that issue the BGPsec Router Certificates and the CRLs necessary to check the validity of the BGPsec Router Certificates remain unchanged (i.e., they are as specified in [RFC7935]). The only impact is that RPKI CAs will need to be able to process a profiled certificate request (see Section5)3.2) signed with algorithms found in[ID.sidr-bgpsec-algs].[RFC8208]. BGPsec Router Certificates are used only to verify the signature on the BGPsec certificate request (only CAs process these) and the signature on a BGPsecUpdate Message [ID.sidr-bgpsec-protocol]UPDATE message [RFC8205] (only BGPsec routers process these); BGPsec Router Certificates are not used to processManifestsmanifests and ROAs or verify signatures on Certificates or CRLs. This document enumerates only the differences between this profile and the profile in [RFC6487]. Note that BGPsec Router Certificates are EEcertificatescertificates, and as such there is no impact onprocessthe algorithm agility procedure described in [RFC6916]. 3. Updates to[RFC6487] 3.1RFC 6487 3.1. BGPsec Router Certificate Fields A BGPsec Router Certificate is consistent with the profile in [RFC6487] as modified by the specifications in this section. As such, it is a valid X.509 public key certificate and consistent with the PKIX profile [RFC5280]. The differences between this profile and the profile in [RFC6487] are specified in this section. 3.1.1. SubjectCommon name encodingEncoding options for the common name that are supported are printableString and UTF8String. For BGPsec Router Certificates, it is RECOMMENDED that the common name attribute contain the literal string "ROUTER-" followed by the 32-bitAS NumberASN [RFC3779] encoded as eight hexadecimal digits and that the serial number attribute contain the 32-bit BGP Identifier [RFC4271] (i.e., the router ID) encoded as eight hexadecimal digits. If there is more than oneAS number,ASN, the choice of which to include in the common name is at the discretion of the Issuer. If the same certificate is issued to more than one router(hence(and hence the private key is shared among these routers), the choice of the router ID used in this name is at the discretion of the Issuer. 3.1.2. Subject Public Key Info Refer tosectionSection 3.1 of[ID.sidr-bgpsec-algs].[RFC8208]. 3.1.3. BGPsec Router Certificate Version 3 Extension Fields 3.1.3.1. Basic Constraints BGPsec speakers are EEs; therefore, the Basic Constraints extension must not be present, as per [RFC6487]. 3.1.3.2. Extended Key Usage BGPsec Router Certificates MUST include the Extended Key Usage (EKU) extension. As specified in[RFC6487][RFC6487], this extension must not be markedas non-critical.critical. This document defines one EKU for BGPsec Router Certificates: id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) } id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 } A BGPsec router MUST require theextended key usageEKU extensiontobe present in a BGPsec Router Certificate it receives. If multiple KeyPurposeId values are included, the BGPsec routers need not recognize all of them, as long as the required KeyPurposeId value is present. BGPsec routers MUST reject certificates that do not contain the BGPsec Router EKU even if they include the anyExtendedKeyUsage OID defined in [RFC5280]. 3.1.3.3. Subject Information Access This extension is not used in BGPsec Router Certificates. It MUST be omitted. 3.1.3.4. IP Resources This extension is not used in BGPsec Router Certificates. It MUST be omitted. 3.1.3.5. AS Resources Each BGPsec Router Certificate MUST include the ASResource Identifier DelegationResources extension, as specified insectionSection 4.8.11 of [RFC6487]. The ASResource Identifier DelegationResources extension MUST include one or moreAS numbers,ASNs, and the "inherit" element MUST NOT be specified. 3.2. BGPsec Router Certificate Request Profile Refer tosectionSection 6 of [RFC6487]. The only differences between this profile and the profile in [RFC6487]are:are as follows: o The Basic Constraints extension: If included, the CA MUST NOT honor the cA boolean if set to TRUE. o TheExtended Key UsageEKU extension: If included, id-kp-bgpsec-router MUST be present (see Section3.1).3.1.3.2). If included, the CA MUST honor the request forid-kp- bgpsec-router.id-kp-bgpsec-router. o The Subject Information Access (SIA) extension: If included, the CA MUST NOT honor the request to include the extension. o The SubjectPublicKeyInfo field is specified in[ID.sidr-bgpsec- algs].[RFC8208]. o The request is signed with the algorithms specified in[ID.sidr- bgpsec-algs].[RFC8208]. 3.3. BGPsec Router Certificate Validation The validation procedure used for BGPsec Router Certificates is identical to the validation procedure described in Section 7 of [RFC6487] (and any RFC that updates that procedure), as modified below. For example, in step3:3 (of the criteria listed in Section 7.2 of [RFC6487]), "The certificate contains all fields that MUST be present"-refers to the fields that are required by this specification. The differences are as follows: o BGPsec Router Certificates MUST include the BGPsec Router EKU defined in Section 3.1.3.2. o BGPsec Router Certificates MUST NOT include the SIA extension. o BGPsec Router Certificates MUST NOT include the IPResourceResources extension. o BGPsec Router Certificates MUST include the ASResource Identifier DelegationResources extension. o BGPsec RouterCertificateCertificates MUST include the subjectPublicKeyInfo field described in[ID.sidr-bgpsec-algs].[RFC8208]. NOTE: BGPsec RPs will need to support the algorithms in[ID.sidr- bgpsec-algs],[RFC8208], which are used to validate BGPsec signatures, as well as the algorithms in [RFC7935], which are needed to validate signatures on BGPsec certificates, RPKI CA certificates, and RPKI CRLs. 3.4. Router Certificates and Signing Functions in the RPKI As described in Section 1, the primary function of BGPsecroute certificatesRouter Certificates in the RPKI is for use in the context of certification ofAutonomous System (AS)AS paths in the BGPsec protocol. The private key associated with a router EE certificate may be used multiple times in generating signatures in multiple instances of theBGPsec_Path AttributeBGPsec_PATH attribute Signature Segments[ID.sidr-bgpsec-protocol]. I.e.,[RFC8205]. That is, the BGPsecrouter certificateRouter Certificate is used to validate multiple signatures. BGPsecrouter certificatesRouter Certificates are stored in the issuing CA's repository, where a repository followingRFC6481[RFC6481] MUST use a .cer filename extension for the certificate file. 4. Design Notes The BGPsec Router Certificate profile is based on the Resource Certificate profile as specified in[RFC7935].[RFC6487]. As a result, many of the design choices herein are a reflection of the design choices that were taken in that prior work. The reader is referred to [RFC6484] for a fuller discussion of those choices. CAs are required by the Certificate Policy (CP) [RFC6484] to issue properly formed BGPsec Router Certificates regardless of what is present in thecertification requestcertificate request, so there is some flexibility permitted in the certificate requests: o BGPsec Router Certificates are always EE certificates; therefore, requests to issue a CA certificate result in EE certificates; o BGPsec Router Certificates are always EE certificates; therefore, requests for Key Usage extension values keyCertSign and cRLSign result in certificates with neither of these values; o BGPsec Router Certificates always include the BGPsecRouerRouter EKU value; therefore,requestrequests without the value result in certificates with the value; and, o BGPsec Router Certificates never include theSubject Information AccessSIA extension; therefore,requestrequests with this extension result in certificates without the extension. Note that this behavior is similar to the CA including the ASResource Identifier DelegationResources extension in issued BGPsec RouterCertificatesCertificates, despite the fact that it is not present in the request. 5. Implementation Considerations This document permits the operator to include a list of ASNs in a BGPsec Router Certificate. In that case, the router certificate would become invalid if any one of the ASNs is removed from any superior CA certificate along the path to a trust anchor. Operators could choose to avoid this possibility by issuing a separate BGPsec Router Certificate for each distinct ASN, so that the router certificates for ASNs that are retained in the superior CA certificate would remain valid. 6. Security Considerations TheSecurity Considerationssecurity considerations of [RFC6487] apply. A BGPsec Router Certificate will fail RPKIvalidation,validation as defined in[RFC6487],[RFC6487] because the cryptographic algorithms used are different. Consequently,aan RP needs to identify the EKU to determine the appropriate Validation constraint. A BGPsec Router Certificate is an extension of the RPKI [RFC6480] to encompass routers. It is a building block of BGPsec and is used to validate signatures on BGPsecSignature-SegmentSignature Segment origination ofSigned-Pathsigned path segments[ID.sidr-bgpsec-protocol]. Thus[RFC8205]. Thus, its essential security function is the secure binding of one or moreAS numbersASNs to a public key, consistent with the RPKI allocation/assignment hierarchy. Hash functions[ID.sidr-bgpsec-algs][RFC8208] are used when generating the two key identifier extensions (i.e., Subject Key Identifier and Issuer Key Identifier) included in BGPsec certificates.HoweverHowever, as noted in [RFC6818], collision resistance is not a required property of one-way hash functions when used to generate key identifiers. Regardless, hash collisions are unlikely, but they arepossiblepossible, and if detected an operator should be alerted. Asubject key identifierSubject Key Identifier collision might cause the incorrect certificate to be selected from the cache, resulting in a failed signature validation. 7. IANA Considerations This document makes use of twoobject identifiersOIDs in the SMIRegistryregistry for PKIX. One is for the ASN.1 module [X680] [X690] in AppendixAA, and it comes from theSMI"SMI Security for PKIX ModuleIdentifierIdentifier" IANA registry(id- mod-bgpsec-eku).(id-mod-bgpsec-eku). The other is for the BGPsecrouterRouter EKU defined in Section 3.1.3.2 and AppendixAA, and it comes from theSMI"SMI Security for PKIX Extended KeyPurposePurpose" IANAregistry.registry (id-kp-bgpsec-router). These OIDs were assigned before management of the PKIX Arc was handed to IANA.No IANA allocations are request of IANA, but please update theThe references in those registrieswhen this document is published by the RFC editor. 8. Acknowledgements We would likehave been updated tothank Geoff Huston, George Michaelson, and Robert Loomans for their work on [RFC6487], which this work is based on. In addition, the efforts of Matt Lepinski were instrumental in preparing this work. Additionally, we'd likepoint tothank Rob Austein, Roque Gagliano, Richard Hansen, Geoff Huston, David Mandelberg, Sandra Murphy, and Sam Weiller for their reviews and comments. 9.this document. 8. References9.1.8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,<http://www.rfc- editor.org/info/rfc2119>.<https://www.rfc-editor.org/info/rfc2119>. [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, DOI 10.17487/RFC3779, June 2004,<http://www.rfc- editor.org/info/rfc3779>.<https://www.rfc-editor.org/info/rfc3779>. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006,<http://www.rfc- editor.org/info/rfc4271>.<https://www.rfc-editor.org/info/rfc4271>. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,<http://www.rfc-editor.org/info/rfc5280>.<https://www.rfc-editor.org/info/rfc5280>. [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <https://www.rfc-editor.org/info/rfc6481>. [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012,<http://www.rfc-editor.org/info/rfc6486>.<https://www.rfc-editor.org/info/rfc6486>. [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012,<http://www.rfc- editor.org/info/rfc6487>.<https://www.rfc-editor.org/info/rfc6487>. [RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, August 2016,<http://www.rfc-editor.org/info/rfc7935>. [ID.sidr-bgpsec-protocol]<https://www.rfc-editor.org/info/rfc7935>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8205] Lepinski,M.M., Ed., and K. Sriram, Ed., "BGPsec Protocol Specification",draft-ietf-sidr-bgpsec-protocol, work-in-progress. [ID.sidr-bgpsec-algs]RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/info/rfc8205>. [RFC8208] Turner,S.,S. and O. Borchert, "BGP Algorithms, Key Formats,&and Signature Formats",draft-ietf-sidr-bgpsec-algs, work-in- progress. 9.2.RFC 8208, DOI 10.17487/RFC8208, September 2017, <https://www.rfc-editor.org/info/rfc8208>. [X680] ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC 8824-1, August 2015, <https://www.itu.int/rec/T-REC-X.680/en>. [X690] ITU-T, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1, August 2015, <https://www.itu.int/rec/T-REC-X.690/en>. 8.2. Informative References [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006,<http://www.rfc-editor.org/info/rfc4272>.<https://www.rfc-editor.org/info/rfc4272>. [RFC5123] White, R. and B. Akyol, "Considerations in Validating the Path in BGP", RFC 5123, DOI 10.17487/RFC5123, February 2008,<http://www.rfc-editor.org/info/rfc5123>.<https://www.rfc-editor.org/info/rfc5123>. [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009,<http://www.rfc-editor.org/info/rfc5492>.<https://www.rfc-editor.org/info/rfc5492>. [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012,<http://www.rfc-editor.org/info/rfc6480>.<https://www.rfc-editor.org/info/rfc6480>. [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, DOI 10.17487/RFC6482, February 2012,<http://www.rfc- editor.org/info/rfc6482>.<https://www.rfc-editor.org/info/rfc6482>. [RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate Policy (CP) for the Resource Public Key Infrastructure (RPKI)", BCP 173, RFC 6484, DOI 10.17487/RFC6484, February 2012,<http://www.rfc-editor.org/info/rfc6484>. [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for<https://www.rfc-editor.org/info/rfc6484>. [RFC6818] Yee, P., "Updates to theResourceInternet X.509 Public Key Infrastructure(RPKI)",Certificate and Certificate Revocation List (CRL) Profile", RFC6486,6818, DOI10.17487/RFC6486, February 2012, <http://www.rfc-editor.org/info/rfc6486>.10.17487/RFC6818, January 2013, <https://www.rfc-editor.org/info/rfc6818>. [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013,<http://www.rfc-editor.org/info/rfc6916>.<https://www.rfc-editor.org/info/rfc6916>. Appendix A. ASN.1 Module BGPSECEKU { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-bgpsec-eku(84) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- -- IMPORTS NOTHING -- -- OID Arc -- id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) kp(3) } -- BGPsec Router Extended Key Usage -- id-kp-bgpsec-router OBJECT IDENTIFIER ::= { id-kp 30 } END Acknowledgements We would like to thank Geoff Huston, George Michaelson, and Robert Loomans for their work on [RFC6487], which this work is based on. In addition, the efforts of Matt Lepinski were instrumental in preparing this work. Additionally, we'd like to thank Rob Austein, Roque Gagliano, Richard Hansen, Geoff Huston, David Mandelberg, Sandra Murphy, and Sam Weiler for their reviews and comments. Authors' Addresses Mark Reynolds Island Peak Software 328 Virginia Road Concord, MA 01742 United States of America Email: mcr@islandpeaksoftware.com Sean Turner sn3rdEMail:Email: sean@sn3rd.com Stephen Kent Raytheon BBN Technologies 10 Moulton St. Cambridge, MA 02138 United States of America Email:kent@bbn.comkent@alum.mit.edu