doc: Add RFC documents

1 files changed, 1459 insertions, 0 deletions

diff --git a/doc/rfc/rfc8211.txt b/doc/rfc/rfc8211.txt
new file mode 100644
index 0000000..5d99265
--- /dev/null
+++ b/doc/rfc/rfc8211.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           S. Kent
+Request for Comments: 8211                              BBN Technologies
+Category: Informational                                            D. Ma
+ISSN: 2070-1721                                                     ZDNS
+                                                          September 2017
+
+
+Adverse Actions by a Certification Authority (CA) or Repository Manager
+            in the Resource Public Key Infrastructure (RPKI)
+
+Abstract
+
+   This document analyzes actions by or against a Certification
+   Authority (CA) or an independent repository manager in the RPKI that
+   can adversely affect the Internet Number Resources (INRs) associated
+   with that CA or its subordinate CAs.  The analysis is done from the
+   perspective of an affected INR holder.  The analysis is based on
+   examination of the data items in the RPKI repository, as controlled
+   by a CA (or an independent repository manager) and fetched by Relying
+   Parties (RPs).  The analysis does not purport to be comprehensive; it
+   does represent an orderly way to analyze a number of ways that errors
+   by or attacks against a CA or repository manager can affect the RPKI
+   and routing decisions based on RPKI data.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It has been approved for publication by the Internet
+   Engineering Steering Group (IESG).  Not all documents approved by the
+   IESG are a candidate for any level of Internet Standard; see
+   Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8211.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kent & Ma                     Informational                     [Page 1]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+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
+   (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
+   2.  Analysis of RPKI Repository Objects . . . . . . . . . . . . .   4
+     2.1.  CA Certificates . . . . . . . . . . . . . . . . . . . . .   6
+     2.2.  Manifest  . . . . . . . . . . . . . . . . . . . . . . . .   9
+     2.3.  Certificate Revocation List . . . . . . . . . . . . . . .  12
+     2.4.  ROA . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
+     2.5.  Ghostbusters Record . . . . . . . . . . . . . . . . . . .  17
+     2.6.  Router Certificates . . . . . . . . . . . . . . . . . . .  18
+   3.  Analysis of Actions Relative to Scenarios . . . . . . . . . .  19
+     3.1.  Scenario A  . . . . . . . . . . . . . . . . . . . . . . .  21
+     3.2.  Scenario B  . . . . . . . . . . . . . . . . . . . . . . .  21
+     3.3.  Scenario C  . . . . . . . . . . . . . . . . . . . . . . .  21
+     3.4.  Scenario D  . . . . . . . . . . . . . . . . . . . . . . .  22
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  23
+     6.2.  Informative References  . . . . . . . . . . . . . . . . .  25
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  26
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kent & Ma                     Informational                     [Page 2]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+1.  Introduction
+
+   In the context of this document, any change to the Resource Public
+   Key Infrastructure (RPKI) [RFC6480] that diminishes the set of
+   Internet Number Resources (INRs) associated with an INR holder, and
+   that is contrary to the holder's wishes, is termed "adverse".  This
+   analysis is done from the perspective of an affected INR holder.  An
+   action that results in an adverse charge (as defined above) may be
+   the result of an attack on a CA [RFC7132], an error by a CA, or an
+   error by or an attack on a repository operator.  Note that the CA
+   that allocated the affected INRs may be acting in accordance with
+   established policy; thus, the change may be contractually justified
+   even though viewed as adverse by the INR holder.  This document
+   examines the implications of adverse actions within the RPKI with
+   respect to INRs, irrespective of the cause of the actions.
+
+   Additionally, when a Route Origin Authorization (ROA) or router
+   certificate is created that "competes" with an existing ROA or router
+   certificate (respectively), the creation of the new ROA or router
+   certificate may be adverse.  (A newer ROA competes with an older ROA
+   if the newer ROA points to a different Autonomous System Number
+   (ASN), contains the same or a more specific prefix, and is issued by
+   a different CA.  A newer router certificate competes with an older
+   router certificate if the newer one contains the same ASN, contains a
+   different public key, and is issued by a different CA.)  Note that
+   transferring resources or changing of upstream providers may yield
+   competing ROAs and/or router certificates under some circumstances.
+   Thus, not all instances of competition are adverse actions.
+
+   As noted above, adverse changes to RPKI data may arise due to several
+   types of causes.  A CA may make a mistake in managing the RPKI
+   objects it signs, or it may be subject to an attack.  If an attack
+   allows an adversary to use the private key of that CA to sign RPKI
+   objects, then the effect is analogous to the CA making mistakes.
+   There is also the possibility that a CA or repository operator may be
+   subject to legal measures that compel them to make adverse changes to
+   RPKI data.  In many cases, such actions may be hard to distinguish
+   from mistakes or attacks, other than with respect to the time
+   required to remedy the adverse action.  (Presumably, the CA will take
+   remedial action when a mistake or an attack is detected, so the
+   effects are similar in these cases.  If a CA has been legally
+   compelled to effect an adverse change, remediation will likely not be
+   swift.)
+
+   This document analyzes the various types of actions by a CA (or an
+   independent repository operator) that can adversely affect the INRs
+   associated with that CA, as well as the INRs of subordinate CAs.  The
+   analysis is based on examination of the data items in the RPKI
+
+
+
+Kent & Ma                     Informational                     [Page 3]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+   repository, as controlled by a CA (or an independent repository
+   operator) and fetched by RPs.
+
+2.  Analysis of RPKI Repository Objects
+
+   This section enumerates the RPKI repository system objects and
+   examines how changes to them affect Route Origin Authorizations
+   (ROAs) and router certificate validation.  Identifiers are assigned
+   to errors for reference by later sections of this document.  Note
+   that not all adverse actions may be encompassed by this taxonomy.
+
+   The RPKI repository [RFC6481] contains a number of (digitally signed)
+   objects that are fetched and processed by RPs.  Until the deployment
+   of BGPsec [RFC8205], the principal goal of the RPKI is to enable an
+   RP to validate ROAs [RFC6482].  A ROA binds address space to an ASN.
+   A ROA can be used to verify BGP announcements with respect to route
+   origin [RFC6483].  The most important objects in the RPKI for origin
+   validation are ROAs; all of the other RPKI objects exist to enable
+   the validation of ROAs in a fashion consistent with the INR
+   allocation system.  Thus, errors that result in changes to a ROA, or
+   to RPKI objects needed to validate a ROA, can cause RPs to reach
+   different (from what was intended) conclusions about the validity of
+   the bindings expressed in a ROA.
+
+   When BGPsec is deployed, router certificates [RFC8209] will be added
+   to repository publication points.  These are end entity (EE)
+   certificates used to verify signatures applied to BGP update data and
+   to enable path validation [RFC8205].  Router certificates are as
+   important to path validation as ROAs are to origin validation.
+
+   The objects contained in the RPKI repository are of two types:
+   conventional PKI objects (certificates and Certificate Revocation
+   Lists (CRLs)) and RPKI-specific signed objects.  The latter make use
+   of a common encapsulation format [RFC6488] based on the Cryptographic
+   Message Syntax (CMS) [RFC5652].  A syntax error in this common format
+   will cause an RP to reject the object, e.g., a ROA or manifest, as
+   invalid.
+
+   Adverse actions take several forms:
+
+      *  Deletion (D) is defined as removing an object from a
+         publication point, without the permission of the INR holder.
+
+      *  Suppression (S) is defined as not deleting an object, or not
+         publishing an object, as intended by an INR holder.  This
+         action also includes retaining a prior version of an object in
+         a publication point when a newer version is available for
+         publication.
+
+
+
+Kent & Ma                     Informational                     [Page 4]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+      *  Corruption (C) is defined as modification of a signed object in
+         a fashion not requiring access to the private key used to sign
+         the object.  Thus, a corrupted object will not carry a valid
+         signature.  Implicitly, the corrupted object replaces the
+         legitimate version.
+
+      *  Modification (M) is defined as publishing a syntactically
+         valid, verifiable version of an object that differs from the
+         (existing) version authorized by the INR holder.  Implicitly,
+         the legitimate version of the affected object is deleted and
+         replaced by the modified object.
+
+      *  Revocation (R) is defined as revoking a certificate (EE or CA)
+         by placing its Serial Number on the appropriate CRL, without
+         authorization of the INR holder.
+
+      *  Injection (I) is defined as introducing an instance of a signed
+         object into a publication point (without authorization of the
+         INR holder).  It assumes that the signature on the object will
+         be viewed as valid by RPs.
+
+   The first three of these actions (deletion, suppression, and
+   corruption) can be effected by any entity that manages the
+   publication point of the affected INR holder.  Also, an entity with
+   the ability to act as a man-in-the-middle between an RP and a
+   repository can effect these actions with respect to the RP in
+   question.
+
+   The latter three actions (modification, revocation, and injection)
+   nominally require access to the private key of the INR holder.
+
+   All six of these actions also can be effected by a parent CA.  A
+   parent CA could reissue the INR holder's CA certificate, but with a
+   different public key, matching a private key to which the parent CA
+   has access.  The CA could generate new signed objects using the
+   private key associated with the reissued certificate and publish
+   these objects at a location of its choosing.
+
+   Most of these actions may be performed independently or in
+   combination with one another.  For example, a ROA may be revoked and
+   deleted or revoked and replaced with a modified ROA.  Where
+   appropriate, the analysis of adverse actions will distinguish between
+   individual actions, or combinations thereof, that yield different
+   outcomes for RPs.  Recall that the focus of the analysis is the
+   impact on ROAs and router certificates, with respect to RP
+   processing.
+
+
+
+
+
+Kent & Ma                     Informational                     [Page 5]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+   The following sections examine how the actions enumerated above
+   affect objects in the RPKI repository system.  Each action is
+   addressed in order (deletion, suppression, corruption, modification,
+   revocation, and injection) for each object, making it easy to see how
+   each action has been considered with regard to each object.  (For the
+   Ghostbusters Record [RFC6493], we condensed the discussion of the
+   actions because the impact is the same in each case.)
+
+2.1.  CA Certificates
+
+   Every INR holder is represented by one or more CA certificates.  An
+   INR holder has multiple CA certificates if it holds resources
+   acquired from different sources.  Also, every INR holder has more
+   than one CA certificate during key rollover [RFC6489] and algorithm
+   rollover [RFC6916].
+
+   If a publication point is not a "leaf" in the RPKI hierarchy, then
+   the publication point will contain one or more CA certificates, each
+   representing a subordinate CA.  Each subordinate CA certificate
+   contains a Subject Information Access (SIA) pointer to the
+   publication point where the signed objects associated with that CA
+   can be found [RFC6487].
+
+   A CA certificate is a complex data structure; thus, errors in that
+   structure may have different implications for RPs depending on the
+   specific data that is in error.
+
+   Adverse actions against a CA certificate can cause the following
+   errors:
+
+      A-1.1  Deletion
+
+             A-1.1.1  Deletion of a CA certificate would cause an RP to
+                      not be able to locate signed objects generated by
+                      that CA, except those that have been cached by the
+                      RP.  Thus, an RP would be unaware of changed or
+                      new (issued after the cached data) INR bindings
+                      asserted in subordinate ROAs, and the RP would be
+                      unable to validate new or changed router
+                      certificates.  If the missed objects were intended
+                      to replace ROAs or router certificates prior to
+                      expiration, then when those objects expire, RPs
+                      may cease to view them as valid.  As a result,
+                      valid routes may be viewed as NotFound or Invalid.
+
+
+
+
+
+
+
+Kent & Ma                     Informational                     [Page 6]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+      A-1.2  Suppression
+
+             A-1.2.1  If publication of a CA certificate is suppressed,
+                      the impact depends on what changes appeared in the
+                      suppressed certificate.  If the SIA value changed,
+                      the effect would be the same as in A-1.1 or
+                      A-1.4.3.  If the [RFC3779] extensions in the
+                      suppressed certificate changed, the impact would
+                      be the same as in A-1.4.1.  If the Authority
+                      Information Access (AIA) extension changed in the
+                      suppressed certificate, the impact would be the
+                      same as in A-1.4.4.  Suppression of a renewed/
+                      re-issued certificate may cause an old certificate
+                      to expire and thus be rejected by RPs.
+
+      A-1.3  Corruption
+
+             A-1.3.1  Corruption of a CA certificate will cause it to be
+                      rejected by RPs.  In turn, this may cause
+                      subordinate signed objects to become invalid.  An
+                      RP that has cached the subtree under the affected
+                      CA certificate may continue to view it as valid,
+                      until objects expire.  But changed or new objects
+                      might not be retrieved, depending on details of
+                      the design of the RP software.  Thus, this action
+                      may be equivalent to suppressing changes to the
+                      affected subtree.
+
+      A-1.4  Modification
+
+             A-1.4.1  If a CA certificate is modified but still conforms
+                      to the RPKI certificate profile [RFC7935], it will
+                      be accepted by RPs.  If an [RFC3779] extension in
+                      this certificate is changed to exclude INRs that
+                      were previously present, then subordinate signed
+                      objects will become invalid if they rely on the
+                      excised INRs.  If these objects are CA
+                      certificates, their subordinate signed objects
+                      will be treated as invalid.  If the objects are
+                      ROAs, the binding expressed by the affected ROAs
+                      will be ignored by RPs.  If the objects are router
+                      certificates, BGPsec_PATH attributes [RFC8205]
+                      verifiable under these certificates will be
+                      considered invalid.
+
+
+
+
+
+
+
+Kent & Ma                     Informational                     [Page 7]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+             A-1.4.2  If the SIA extension of a CA certificate is
+                      modified to refer to another publication point,
+                      this will cause an RP to look at another location
+                      for subordinate objects.  This could cause RPs to
+                      not acquire the objects that the INR holder
+                      intended to be retrieved -- manifests, ROAs,
+                      router certificates, Ghostbuster Records, or any
+                      subordinate CA certificates associated with that
+                      CA.  If the objects at this new location contain
+                      invalid signatures or appear to be corrupted, they
+                      may be rejected.  In this case, cached versions of
+                      the objects may be viewed as valid by an RP, until
+                      they expire.  If the objects at the new location
+                      have valid signatures and pass path validation
+                      checks, they will replace the cached objects,
+                      effectively replacing the INR holder's objects.
+
+             A-1.4.3  If the AIA extension in a CA certificate is
+                      modified, it would point to a different CA
+                      certificate, not the parent CA certificate.  This
+                      extension is used only for path discovery, not
+                      path validation.  Path discovery in the RPKI is
+                      usually performed on a top-down basis, starting
+                      with trust anchors (TAs) and recursively
+                      descending the RPKI hierarchy.  Thus, there may be
+                      no impact on the ability of clients to acquire and
+                      validate certificates if the AIA is modified.
+
+             A-1.4.4  If the Subject Public Key Info (and Subject Key
+                      Identifier extension) in a CA certificate is
+                      modified to contain a public key corresponding to
+                      a private key held by the parent, the parent could
+                      sign objects as children of the affected CA
+                      certificate.  With this capability, the parent
+                      could replace the INR holder, issuing new signed
+                      objects that would be accepted by RPs (as long as
+                      they do not violate the path validation criteria).
+                      This would enable the parent to effect
+                      modification, revocation, and injection actions
+                      against all of the objects under the affected CA
+                      certificate, including subordinate CA
+                      certificates.  (Note that key rollover also yields
+                      a new CA certificate.  However, the new
+                      certificate will coexist with the old one for a
+                      while, which may help distinguish this legitimate
+                      activity from an adverse action.)
+
+
+
+
+
+Kent & Ma                     Informational                     [Page 8]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+      A-1.5  Revocation
+
+             A-1.5.1  If a CA certificate is revoked, an RP will treat
+                      as invalid all subordinate signed objects, both
+                      immediate and transitive.  The effects are
+                      essentially the same as described in A-3.4.2.
+
+      A-1.6  Injection
+
+             A-1.6.1  If a CA certificate is injected, the impact will
+                      depend on the data contained in the injected
+                      certificate.  Changes will generally be equivalent
+                      to modification actions as described in A-1.4.
+
+2.2.  Manifest
+
+   Each repository publication point contains a manifest [RFC6486].  The
+   RPKI incorporates manifests to enable RPs to detect suppression and/
+   or substitution of (more recent) publication point objects, as the
+   result of a mistake or attack.  A manifest enumerates (by filename)
+   all of the other signed objects at the publication point.  The
+   manifest also contains a hash of each enumerated file to enable an RP
+   to determine if the named file content matches what the INR holder
+   identified in the manifest.
+
+   A manifest is an RPKI signed object, so it is validated as per
+   [RFC6488].  If a manifest is modified in a way that causes any of
+   these checks to fail, the manifest will be considered invalid.
+   Suppression of a manifest itself (indicated by a stale manifest) can
+   also cause an RP to not detect suppression of other signed objects at
+   the publication point.  (Note that if a manifest's EE certificate
+   expires at the time that the manifest is scheduled to be replaced, a
+   delay in publication will cause the manifest to become invalid, not
+   merely stale.  This very serious outcome should be avoided, e.g., by
+   making the manifest EE certificate's notAfter value the same as that
+   of the CA certificate under which it was issued).  If a signed object
+   at a publication point can be validated (using the rules applicable
+   for that object type), then an RP may accept that object, even if
+   there is no matching entry for it on the manifest.  However, it
+   appears that most RP software ignores publication point data that
+   fails to match manifest entries (at the time this document was
+   written).
+
+   Corruption, suppression, modification, or deletion of a manifest
+   might not affect RP processing of other publication point objects, as
+   specified in [RFC6486].  However, as noted above, many RP
+
+
+
+
+
+Kent & Ma                     Informational                     [Page 9]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+   implementations ignore objects that are present at a publication
+   point but not listed in a valid manifest.  Thus, the following
+   actions against a manifest can impact RP processing:
+
+      A-2.1  Deletion
+
+             A-2.1.1  A manifest may be deleted from the indicated
+                      publication point.  In this circumstance, an RP
+                      may elect to use the previous manifest (if
+                      available) and may ignore any new/changed objects
+                      at the publication point.  The implications of
+                      this action are equivalent to suppression of
+                      publication of the objects that are not recognized
+                      by RPs because the new objects are not present in
+                      the old manifest.  For example, a new ROA could be
+                      ignored (A-1.2).  A newly issued CA certificate
+                      might be ignored (A-1.1).  A subordinate CA
+                      certificate that was revoked might still be viewed
+                      as valid by RPs (A-4.1).  A new or changed router
+                      certificate might be ignored (A-6.2) as would a
+                      revised Ghostbusters Record (A-4.1).
+
+      A-2.2  Suppression
+
+             A-2.2.1  Publication of a newer manifest may be suppressed.
+                      Suppression of a newer manifest probably will
+                      cause an RP to rely on a cached manifest (if
+                      available).  The older manifest would not
+                      enumerate newly added objects; thus, those objects
+                      might be ignored by an RP, which is equivalent to
+                      deletion of those objects (A-1.1, A-3.1, A-4.1,
+                      A-5.1, and A-6.1).
+
+      A-2.3  Corruption
+
+             A-2.3.1  A manifest may be corrupted.  A corrupted manifest
+                      will be rejected by RPs.  This may cause RPs to
+                      rely on a previous manifest, with the same impact
+                      as A-2.2.  If an RP does not revert to using a
+                      cached manifest, the impact of this action is very
+                      severe, i.e., all publication point objects will
+                      probably be viewed as invalid, including
+                      subordinate tree objects.  This is equivalent to
+                      revoking or deleting an entire subtree (see
+                      A-4.4.2).
+
+
+
+
+
+
+Kent & Ma                     Informational                    [Page 10]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+      A-2.4  Modification
+
+             A-2.4.1  A manifest may be modified to remove one or more
+                      objects.  Because the modified manifest is viewed
+                      as valid by RPs, any objects that were removed may
+                      be ignored by RPs.  This is equivalent to deleting
+                      these objects from the repository.  The impact of
+                      this action will vary, depending on which objects
+                      are (effectively) removed.  However, the impact is
+                      equivalent to deletion of the object in question,
+                      (A-1.1, A-3.1, A-4.1, A-5.1, and A-6.1).
+
+             A-2.4.2  A manifest may be modified to add one or more
+                      objects.  If an added object has a valid signature
+                      (and is not expired), it will be accepted by RPs
+                      and processed accordingly.  If the added object
+                      was previously deleted by the INR holder, this
+                      action is equivalent to suppressing deletion of
+                      that object.  If the object is newly created or
+                      modified, it is equivalent to a modification or
+                      injection action for the type of object in
+                      question and is thus discussed in the relevant
+                      section for those actions for the object type.
+
+             A-2.4.3  A manifest may be modified to list an incorrect
+                      hash for one or more objects.  An object with an
+                      incorrect hash may be ignored by an RP.  Thus, the
+                      effect may be equivalent to corrupting the object
+                      in question, although the error reported by RP
+                      software would differ from that reported for a
+                      corrupted object.  (The manifest specifications do
+                      not require an RP to ignore an object that has a
+                      valid signature and that is not revoked or
+                      expired, but for which the hash doesn't match the
+                      object.  However, an RP may elect to do so.)
+
+      A-2.5  Revocation
+
+             A-2.5.1  A manifest may be revoked (by including its EE
+                      certificate on the CRL for the publication point).
+                      A revoked manifest will be ignored by an RP, which
+                      probably would revert to an older (cached)
+                      manifest.  The implications for RPs are equivalent
+                      to A-2.1 with regard to new/changed objects.
+
+
+
+
+
+
+
+Kent & Ma                     Informational                    [Page 11]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+      A-2.6  Injection
+
+             A-2.6.1  A manifest representing different objects may be
+                      injected into a publication point.  The effects
+                      are the same as for a modified manifest (see
+                      above).  The impact will depend on the type of the
+                      affected object(s) and is thus discussed in the
+                      relevant section(s) for each object type.
+
+2.3.  Certificate Revocation List
+
+   Each publication point contains a CRL that enumerates revoked (not
+   yet expired) certificates issued by the CA associated with the
+   publication point [RFC6481].
+
+   Adverse actions against a CRL can cause the following errors:
+
+      A-3.1  Deletion
+
+             A-3.1.1  If a CRL is deleted, RPs will continue to use an
+                      older, previously fetched Certificate Revocation
+                      List.  As a result, they will not be informed of
+                      any changes in revocation status of subordinate CA
+                      or router certificates or the EE certificates of
+                      signed objects, e.g., ROAs.  This action is
+                      equivalent to corruption of a CRL, since a
+                      corrupted CRL will not be accepted by an RP.
+
+             A-3.1.2  Deletion of a CRL could cause an RP to continue to
+                      accept a ROA that no longer expresses the intent
+                      of an INR holder.  As a result, an announcement
+                      for the affected prefixes would be viewed as
+                      Valid, instead of NotFound or Invalid.  In this
+                      case, the effect is analogous to A-5.2.
+
+             A-3.1.3  If a router certificate were revoked and the CRL
+                      were deleted, RPs would not be aware of the
+                      revocation.  They might continue to accept the
+                      old, revoked router certificate.  If the
+                      certificate had been revoked due to a compromise
+                      of the router's private key, RPs would be
+                      vulnerable to accepting routes signed by an
+                      unauthorized entity.
+
+
+
+
+
+
+
+
+Kent & Ma                     Informational                    [Page 12]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+             A-3.1.4  If a subordinate CA certificate were revoked on
+                      the deleted CRL, the revocation would not take
+                      effect.  This could interfere with a transfer of
+                      address space from the subordinate CA, adversely
+                      affecting routing to the new holder of the space.
+
+      A-3.2  Suppression
+
+             A-3.2.1  If publication of the most recent CRL is
+                      suppressed, an RP will not be informed of the most
+                      recent revocation status of a subordinate CA or
+                      router certificates or the EE certificates of
+                      signed objects.  If an EE certificate has been
+                      revoked and the associated signed object is still
+                      present in the publication point, an RP might
+                      mistakenly treat that object as valid.  (This
+                      would happen if the object is still in the
+                      manifest or if the RP is configured to process
+                      valid objects that are not on the manifest.)  This
+                      type of action is of special concern if the
+                      affected object is a ROA, a router certificate, or
+                      a subordinate CA certificate.  The effects here
+                      are equivalent to CRL deletion (A-3.1), but
+                      suppression of a new CRL may not even be reported
+                      as an error, i.e., if the suppressed CRL were
+                      issued before the NextUpdate time (of the previous
+                      CRL).
+
+      A-3.3  Corruption
+
+             A-3.3.1  If a CRL is corrupted, an RP will reject it.  If a
+                      prior CRL has not yet exceeded its NextUpdate
+                      time, an RP will continue to use the prior CRL.
+                      Even if the prior CRL has passed the NextUpdate
+                      time, an RP may choose to continue to rely on the
+                      prior CRL.  The effects are essentially equivalent
+                      to suppression or deletion of a CRL (A-3.1 and
+                      A-3.2).
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kent & Ma                     Informational                    [Page 13]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+      A-3.4  Modification
+
+             A-3.4.1  If a CRL is modified to erroneously list a signed
+                      object's EE certificate as revoked, the
+                      corresponding object will be treated as invalid by
+                      RPs, even if it is present in a publication point.
+                      If this object is a ROA, the (legitimate) binding
+                      expressed by the ROA will be ignored by an RP (see
+                      A-5.5).  If a CRL is modified to erroneously list
+                      a router certificate as revoked, a path signature
+                      associated with that certificate will be treated
+                      as Not Valid by RPs (see A-6.5).
+
+             A-3.4.2  If a CRL is modified to erroneously list a CA
+                      certificate as revoked, that CA and all
+                      subordinate signed objects will be treated as
+                      invalid by RPs.  Depending on the location of the
+                      affected CA in the hierarchy, these effects could
+                      be very substantial, causing routes that should be
+                      Valid to be treated as NotFound.
+
+             A-3.4.3  If a CRL is modified to omit a revoked EE, router,
+                      or CA certificate, RPs will likely continue to
+                      accept the revoked, signed object as valid.  This
+                      contravenes the intent of the INR holder.  If an
+                      RP continues to accept a revoked ROA, it may make
+                      routing decisions on now-invalid data.  This could
+                      cause valid routes to be de-preferenced and
+                      invalid routes to continue to be accepted.
+
+      A-3.5  Revocation
+
+             A-3.5.1  A CRL cannot be revoked per se, but it will fail
+                      validation if the CA certificate under which it
+                      was issued is revoked.  See A-1.5 for a discussion
+                      of that action.
+
+      A-3.6  Injection
+
+             A-3.6.1  Insertion of a bogus CRL can have the same effects
+                      as listed above for a modified CRL, depending on
+                      how the inserted CRL differs from the correct CRL.
+
+
+
+
+
+
+
+
+
+Kent & Ma                     Informational                    [Page 14]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+2.4.  ROA
+
+   In addition to the generic RPKI object syntax checks, ROA validation
+   requires that the signature on the ROA can be validated using the
+   public key from the EE certificate embedded in the ROA [RFC6482].  It
+   also requires that the EE certificate be validated consistently with
+   the procedures described in [RFC6482] and [RFC6487].  Adverse actions
+   against a ROA can cause the following errors:
+
+      A-4.1  Deletion
+
+             A-4.1.1  A ROA may be deleted from the indicated
+                      publication point.  The result is to void the
+                      binding between the prefix(es) and the Autonomous
+                      System (AS) number in the ROA.  An RP that
+                      previously viewed this binding as authentic will
+                      now not have any evidence about its validity.  For
+                      origin validation, this means that a legitimate
+                      route will be treated as NotFound (if there are no
+                      other ROAs for the same prefix) or Invalid (if
+                      there is another ROA for the same prefix, but with
+                      a different AS number).
+
+      A-4.2  Suppression
+
+             A-4.2.1  Publication of a newer ROA may be suppressed.  If
+                      the INR holder intended to change the binding
+                      between the prefix(es) and the AS number in the
+                      ROA, this change will not be effected.  As a
+                      result, RPs may continue to believe an old prefix/
+                      ASN binding that is no longer what the INR holder
+                      intended.
+
+             A-4.2.2  If an INR holder intends to issue and publish two
+                      (or more) new ROAs for the same address space, one
+                      (or more) of the new ROAs may be suppressed while
+                      the other is published.  In this case, RPs will
+                      de-preference the suppressed prefix/ASN binding.
+                      Suppression of the new ROA might cause traffic to
+                      flow to an ASN other than the one(s) intended by
+                      the INR holder.
+
+
+
+
+
+
+
+
+
+
+Kent & Ma                     Informational                    [Page 15]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+             A-4.2.3  If an INR holder intends to delete all ROAs for
+                      the same address space, some of them may be
+                      retained while the others are deleted.  Preventing
+                      the deletion of some ROAs can cause traffic to
+                      continue to be delivered to the ASNs that were
+                      advertised by these ROAs.  Deletion of all ROAs is
+                      consistent with a transfer of address space to a
+                      different INR holder in a phased fashion.  Thus,
+                      this sort of attack could interfere with the
+                      successful transfer of the affected address space
+                      (until such time as the prefixes are removed from
+                      the previous INR holder's CA certificate).
+
+      A-4.3  Corruption
+
+             A-4.3.1  A ROA may be corrupted.  A corrupted ROA will be
+                      ignored by an RP, so the effect is essentially the
+                      same as for A-4.1 and A-4.5.  A possible
+                      difference is that an RP may be alerted to the
+                      fact that the ROA was corrupted, which might
+                      attract attention to the attack.
+
+      A-4.4  Modification
+
+             A-4.4.1  A ROA may be modified so that the Autonomous
+                      System Number (ASN) or one or more of the address
+                      blocks in a ROA is different from the values the
+                      INR holder intended for this ROA.  (This action
+                      assumes that the modified ROA's ASN and address
+                      ranges are authorized for use by the INR holder.)
+                      This attack will cause RPs to de-preference the
+                      legitimate prefix/ASN binding intended by the INR
+                      holder.
+
+      A-4.5  Revocation
+
+             A-4.5.1  A ROA may be revoked (by placing its EE
+                      certificate on the CRL for the publication point).
+                      This has the same effect as A-4.1.
+
+
+
+
+
+
+
+
+
+
+
+
+Kent & Ma                     Informational                    [Page 16]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+      A-4.6  Injection
+
+             A-4.6.1  A ROA expressing different bindings than those
+                      published by the INR holder may be injected into a
+                      publication point.  This action could authorize an
+                      additional ASN to advertise the specified prefix,
+                      allowing that ASN to originate routes for the
+                      prefix, thus enabling route origin spoofing.  In
+                      this case, the injected ROA is considered to be in
+                      competition with any existing authorized ROAs for
+                      the specified prefix.
+
+             A-4.6.2  An injected ROA might express a different prefix
+                      for an ASN already authorized to originate a
+                      route, e.g., a longer prefix, which could enable
+                      that ASN to override other advertisements using
+                      shorter prefixes.  If there are other ROAs that
+                      authorize different ASNs to advertise routes to
+                      the injected ROA's prefix, then the injected ROA
+                      is in competition with these ROAs.
+
+2.5.  Ghostbusters Record
+
+   The Ghostbusters Record [RFC6493] is a signed object that may be
+   included at a publication point, at the discretion of the INR holder
+   or publication point operator.  The record is validated according to
+   [RFC6488].  Additionally, the syntax of the record is verified based
+   on the vCard profile from Section 5 of [RFC6493].  Errors in this
+   record do not affect RP processing.  However, if an RP encounters a
+   problem with objects at a publication point, the RP may use
+   information from the record to contact the publication point
+   operator.
+
+   Adverse actions against a Ghostbusters Record can cause the following
+   error:
+
+      A-5.1  Deletion, suppression, corruption, or revocation of a
+             Ghostbusters Record could prevent an RP from contacting the
+             appropriate entity when a problem is detected by the RP.
+             Modification or injection of a Ghostbusters Record could
+             cause an RP to contact the wrong entity, thus delaying
+             remediation of a detected anomaly.  All of these actions
+             are viewed as equivalent from an RP processing perspective;
+             they do not alter RP validation of ROAs or router
+             certificates.  However, these actions can interfere with
+             remediation of a problem when detected by an RP.
+
+
+
+
+
+Kent & Ma                     Informational                    [Page 17]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+2.6.  Router Certificates
+
+   Router certificates are used by RPs to verify signatures on
+   BGPsec_PATH attributes carried in UPDATE messages.
+
+   Each AS is free to determine the granularity at which router
+   certificates are managed [RFC8209].  Each participating AS is
+   represented by one or more router certificates.  During key or
+   algorithm rollover, multiple router certificates will be present in a
+   publication point, even if the AS is normally represented by just one
+   such certificate.
+
+   Adverse actions against router certificates can cause the following
+   errors:
+
+      A-6.1  Deletion
+
+             A-6.1.1  Deletion of a router certificate would cause an RP
+                      to be unable to verify signatures applied to
+                      BGPsec_PATH attributes on behalf of the AS in
+                      question.  In turn, this would cause the route to
+                      be treated with lower preference than competing
+                      routes that have valid BGPsec_PATH attribute
+                      signatures.  (However, if another router
+                      certificate for the affected AS is valid and
+                      contains the same AS number and public key, and it
+                      is in use by that AS, there would be no effect on
+                      routing.  This scenario will arise if a router
+                      certificate is renewed, i.e., issued with a new
+                      validity interval.)
+
+      A-6.2  Suppression
+
+             A-6.2.1  Suppression of a router certificate could have the
+                      same impact as deletion of a certificate of this
+                      type, i.e., if no router certificate was
+                      available, BGPsec attributes that should be
+                      verified using the certificate would fail
+                      validation.  If an older certificate existed and
+                      has not expired, it would be used by RPs.  If the
+                      older certificate contained a different ASN, the
+                      impact would be the same as in A-6.4.
+
+
+
+
+
+
+
+
+
+Kent & Ma                     Informational                    [Page 18]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+      A-6.3  Corruption
+
+             A-6.3.1  Corruption of a router certificate will result in
+                      the certificate being rejected by RPs.  Absent a
+                      valid router certificate, BGPsec_PATH attributes
+                      associated with that certificate will be
+                      unverifiable.  In turn, this would cause the route
+                      to be treated with lower preference than competing
+                      routes that have valid BGPsec_PATH attribute
+                      signatures.
+
+      A-6.4  Modification
+
+             A-6.4.1  If a router certificate is modified to represent a
+                      different ASN, but it still passes syntax checks,
+                      then this action could cause signatures on
+                      BGPsec_PATH attributes to be associated with the
+                      wrong AS.  This could cause signed routes to be
+                      inconsistent with the intent of the INR holder,
+                      e.g., traffic might be routed via a different AS
+                      than intended.
+
+      A-6.5  Revocation
+
+             A-6.5.1  If a router certificate were revoked, BGPsec_PATH
+                      attributes verifiable using that certificate would
+                      no longer be considered valid.  The impact would
+                      be the same as for a deleted certificate, as
+                      described in A-6.1.
+
+      A-6.6  Injection
+
+             A-6.6.1  Insertion of a router certificate could authorize
+                      additional routers to sign BGPsec traffic for the
+                      targeted ASN, and thus undermine fundamental
+                      BGPsec security guarantees.  If there are
+                      existing, authorized router certificates for the
+                      same ASN, then the injected router certificate is
+                      in competition with these existing certificates.
+
+3.  Analysis of Actions Relative to Scenarios
+
+   This section examines the types of problems that can arise in four
+   scenarios described below.  We consider mistakes, (successful)
+   attacks against a CA or a publication point, and situations in which
+   a CA or publication point manager is compelled to take action by a
+   law enforcement authority.
+
+
+
+
+Kent & Ma                     Informational                    [Page 19]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+   We explore the following four scenarios:
+
+      A.  An INR holder operates its own CA and manages its own
+          repository publication point.
+
+      B.  An INR holder operates its own CA, but outsources management
+          of its repository publication point to its parent or another
+          entity.
+
+      C.  An INR holder outsources management of its CA to its parent,
+          but manages its own repository publication point.
+
+      D.  An INR holder outsources management of its CA and its
+          publication point to its parent.
+
+   Note that these scenarios focus on the affected INR holder as the
+   party directly affected by an adverse action.  The most serious cases
+   arise when the INR holder appears as a high-tier CA in the RPKI
+   hierarchy; in such situations, subordinate INR holders may be
+   affected as a result of an action.  A mistake by or an attack against
+   a "leaf" has more limited impact because all of the affected INRs
+   belong to the INR holder itself.
+
+   In Scenario A, actions by the INR holder can adversely affect all of
+   its resources and, transitively, resources of any subordinate CAs.
+   (If the CA is a "leaf" in the RPKI, then it has no subordinate CAs
+   and the damage is limited to its own INRs.)
+
+   In Scenario B, actions by the (outsourced) repository operator can
+   also adversely affect the resources of the INR holder and those of
+   any subordinates CAs.  (If the CA is a "leaf" in the RPKI, then it
+   has no subordinate CAs and the damage is limited, as in Scenario A.)
+   The range of adverse effects here includes those in Scenario A and
+   adds a new potential source of adverse actions, i.e., the outsourced
+   repository operator.
+
+   In Scenario C, all signed objects associated with the INR holder are
+   generated by the parent CA but are self-hosted.  (We expect this
+   scenario to be rare, because an INR holder that elects to outsource
+   CA operation seems unlikely to manage its own repository publication
+   point.)  Because that CA has the private key used to sign them, it
+   can generate alternative signed objects -- ones not authorized by the
+   INR holder.  However, erroneous objects created by the parent CA will
+   not be published by the INR holder IF the holder checks them first.
+   Because the parent CA is acting on behalf of the INR holder, mistakes
+   by or attacks against that entity are equivalent to ones effected by
+   the INR holder in Scenario A.
+
+
+
+
+Kent & Ma                     Informational                    [Page 20]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+   The INR holder is most vulnerable in Scenario D.  Actions by the
+   parent CA, acting on behalf of the INR holder, can adversely affect
+   all signed objects associated with that INR holder, including any
+   subordinate CA certificates.  These actions will presumably translate
+   directly into publication point changes because the parent CA is
+   managing the publication point for the INR holder.  The range of
+   adverse effects here includes those in Scenarios A, B, and C.
+
+3.1.  Scenario A
+
+   In this scenario, the INR holder acts as its own CA and it manages
+   its own publication point.  Actions by the INR holder can adversely
+   affect all of its resources and, transitively, resources of any
+   subordinate CAs.  (If the CA is a "leaf" in the RPKI, then it has no
+   subordinate CAs and the damage is limited to its own INRs.)  Mistakes
+   by the INR holder can cause any of the actions noted in Section 2.  A
+   successful attack against this CA can effect all of the modification,
+   revocation, or injection actions noted in that section.  (We assume
+   that objects generated by the CA are automatically published).  An
+   attack against the publication point can effect all of the deletion,
+   suppression, or corruption actions noted in that section.
+
+3.2.  Scenario B
+
+   In this scenario, the INR holder acts as its own CA but it delegates
+   management of it own publication point to a third party.  Mistakes by
+   the INR holder can cause any of the modification, revocation, or
+   injection actions described in Section 2.  Actions by the repository
+   operator can adversely affect the resources of the INR holder, and
+   those of any subordinate CAs.  (If the CA is a "leaf" in the RPKI,
+   then it has no subordinate CAs and the damage is limited, as in
+   Scenario A.)  The range of adverse effects here includes those in
+   Scenario A, and adds a new potential source of adverse actions, i.e.,
+   the third party repository operator.  A successful attack against the
+   CA can effect all of the modification, revocation, or injection
+   actions noted in that section (assuming that objects generated by the
+   CA are automatically published).  Here, actions by the publication
+   point manager (or attacks against that entity) can effect all of the
+   deletion, suppression, or corruption actions noted in Section 2.
+
+3.3.  Scenario C
+
+   In this scenario, the INR holder outsources management of its CA to
+   its parent, but manages its own repository publication point.  All
+   signed objects associated with the INR holder are generated by the
+   parent CA but are self-hosted.  (We expect this scenario to be rare,
+   because an INR holder that elects to outsource CA operation seems
+   unlikely to manage its own repository publication point.)  Because
+
+
+
+Kent & Ma                     Informational                    [Page 21]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+   that CA has the private key used to sign them, it can generate
+   alternative signed objects -- ones not authorized by the INR holder.
+   However, erroneous objects created by the parent CA will not be
+   published by the INR holder IF the holder checks them first.  Because
+   the parent CA is acting on behalf of the INR holder, mistakes by or
+   attacks against that entity are equivalent to ones effected by the
+   INR holder in Scenario A.  Mistakes by the INR holder, acted upon by
+   the parent CA, can cause any of the actions noted in Section 2.
+   Actions unilaterally undertaken by the parent CA also can have the
+   same effect, unless the INR holder checks the signed objects before
+   publishing them.  A successful attack against the parent CA can
+   effect all of the modification, revocation, or injection actions
+   noted in Section 2, unless the INR holder checks the signed objects
+   before publishing them.  An attack against the INR holder (in its
+   role as repository operator) can effect all of the deletion,
+   suppression, or corruption actions noted in Section 2 (because the
+   INR holder is managing its publication point), unless the INR holder
+   checks the signed objects before publishing them.  (An attack against
+   the INR holder implies that the path it uses to direct the parent CA
+   to issue and publish objects has been compromised.)
+
+3.4.  Scenario D
+
+   In this scenario, an INR holder outsources management of both its CA
+   and its publication point to its parent.  The INR holder is most
+   vulnerable in this scenario.  Actions by the parent CA, acting on
+   behalf of the INR holder, can adversely affect all signed objects
+   associated with that INR holder, including any subordinate CA
+   certificates.  These actions will presumably translate directly into
+   publication point changes, because the parent CA is managing the
+   publication point for the INR holder.  The range of adverse effects
+   here includes those in Scenarios A, B, and C.  Mistakes by the INR
+   holder, acted upon by the parent CA, can cause any of the actions
+   noted in Section 2.  Actions unilaterally undertaken by the parent CA
+   also can have the same effect.  A successful attack against the
+   parent CA can effect all of the modification, revocation, or
+   injection actions noted in Section 2.  An attack against the parent
+   CA can also effect all of the deletion, suppression, or corruption
+   actions noted in Section 2 (because the parent CA is managing the INR
+   holder's publication point).
+
+4.  Security Considerations
+
+   This informational document describes a threat model for the RPKI,
+   focusing on mistakes by or attacks against CAs and independent
+   repository managers.  It is intended to provide a basis for the
+   design of future RPKI security mechanisms that seek to address the
+   concerns associated with such actions.
+
+
+
+Kent & Ma                     Informational                    [Page 22]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+   The analysis in this document identifies a number of circumstances in
+   which attacks or errors can have significant impacts on routing.  One
+   ought not interpret this as a condemnation of the RPKI.  It is only
+   an attempt to document the implications of a wide range of attacks
+   and errors in the context of the RPKI.  The primary alternative
+   mechanism for disseminating routing information is Internet Routing
+   Registry (IRR) technology [RFC2650] [RFC2725], which uses the Routing
+   Policy Specification Language (RPSL) [RFC2622].  IRR technology
+   exhibits its own set of security problems, which are discussed in
+   [RFC7682].
+
+5.  IANA Considerations
+
+   This document does not require any IANA actions.
+
+6.  References
+
+6.1.  Normative References
+
+   [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,
+              <https://www.rfc-editor.org/info/rfc3779>.
+
+   [RFC6480]  Lepinski, M. and S. Kent, "An Infrastructure to Support
+              Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
+              February 2012, <https://www.rfc-editor.org/info/rfc6480>.
+
+   [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>.
+
+   [RFC6482]  Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
+              Origin Authorizations (ROAs)", RFC 6482,
+              DOI 10.17487/RFC6482, February 2012,
+              <https://www.rfc-editor.org/info/rfc6482>.
+
+   [RFC6483]  Huston, G. and G. Michaelson, "Validation of Route
+              Origination Using the Resource Certificate Public Key
+              Infrastructure (PKI) and Route Origin Authorizations
+              (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012,
+              <https://www.rfc-editor.org/info/rfc6483>.
+
+   [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,
+              <https://www.rfc-editor.org/info/rfc6486>.
+
+
+
+Kent & Ma                     Informational                    [Page 23]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+   [RFC6487]  Huston, G., Michaelson, G., and R. Loomans, "A Profile for
+              X.509 PKIX Resource Certificates", RFC 6487,
+              DOI 10.17487/RFC6487, February 2012,
+              <https://www.rfc-editor.org/info/rfc6487>.
+
+   [RFC6488]  Lepinski, M., Chi, A., and S. Kent, "Signed Object
+              Template for the Resource Public Key Infrastructure
+              (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
+              <https://www.rfc-editor.org/info/rfc6488>.
+
+   [RFC6489]  Huston, G., Michaelson, G., and S. Kent, "Certification
+              Authority (CA) Key Rollover in the Resource Public Key
+              Infrastructure (RPKI)", BCP 174, RFC 6489,
+              DOI 10.17487/RFC6489, February 2012,
+              <https://www.rfc-editor.org/info/rfc6489>.
+
+   [RFC6493]  Bush, R., "The Resource Public Key Infrastructure (RPKI)
+              Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493,
+              February 2012, <https://www.rfc-editor.org/info/rfc6493>.
+
+   [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, <https://www.rfc-editor.org/info/rfc6916>.
+
+   [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, <https://www.rfc-editor.org/info/rfc7935>.
+
+   [RFC8205]  Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
+              Specification", RFC 8205, DOI 10.17487/RFC8205, September
+              2017, <https://www.rfc-editor.org/info/rfc8205>.
+
+   [RFC8209]  Reynolds, M., Turner, S., and S. Kent, "A Profile for
+              BGPsec Router Certificates, Certificate Revocation Lists,
+              and Certification Requests", RFC 8209,
+              DOI 10.17487/RFC8209, September 2017,
+              <https://www.rfc-editor.org/info/rfc8209>.
+
+
+
+
+
+
+
+
+
+
+
+
+Kent & Ma                     Informational                    [Page 24]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+6.2.  Informative References
+
+   [RFC2622]  Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
+              Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
+              "Routing Policy Specification Language (RPSL)", RFC 2622,
+              DOI 10.17487/RFC2622, June 1999,
+              <https://www.rfc-editor.org/info/rfc2622>.
+
+   [RFC2650]  Meyer, D., Schmitz, J., Orange, C., Prior, M., and C.
+              Alaettinoglu, "Using RPSL in Practice", RFC 2650,
+              DOI 10.17487/RFC2650, August 1999,
+              <https://www.rfc-editor.org/info/rfc2650>.
+
+   [RFC2725]  Villamizar, C., Alaettinoglu, C., Meyer, D., and S.
+              Murphy, "Routing Policy System Security", RFC 2725,
+              DOI 10.17487/RFC2725, December 1999,
+              <https://www.rfc-editor.org/info/rfc2725>.
+
+   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
+              RFC 5652, DOI 10.17487/RFC5652, September 2009,
+              <https://www.rfc-editor.org/info/rfc5652>.
+
+   [RFC7132]  Kent, S. and A. Chi, "Threat Model for BGP Path Security",
+              RFC 7132, DOI 10.17487/RFC7132, February 2014,
+              <https://www.rfc-editor.org/info/rfc7132>.
+
+   [RFC7682]  McPherson, D., Amante, S., Osterweil, E., Blunk, L., and
+              D. Mitchell, "Considerations for Internet Routing
+              Registries (IRRs) and Routing Policy Configuration",
+              RFC 7682, DOI 10.17487/RFC7682, December 2015,
+              <https://www.rfc-editor.org/info/rfc7682>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kent & Ma                     Informational                    [Page 25]
+
+RFC 8211                 RPKI Adverse CA Actions          September 2017
+
+
+Acknowledgements
+
+   The authors thank Richard Hansen and David Mandelberg for their
+   extensive review, feedback, and editorial assistance.  Thanks also go
+   to Daiming Li for her editorial assistance.
+
+Authors' Addresses
+
+   Stephen Kent
+   BBN Technologies
+   10 Moulton St
+   Cambridge, MA  02138-1119
+   United States of America
+
+   Email: kent@alum.mit.edu
+
+
+   Di Ma
+   ZDNS
+   4 South 4th St. Zhongguancun
+   Haidian, Beijing  100190
+   China
+
+   Email: madi@zdns.cn
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kent & Ma                     Informational                    [Page 26]
+