Network Working Group                                     T. Bruijnzeels
Internet-Draft                                                  RIPE NCC                                                NLnet Labs
Intended status: Standards Track Best Current Practice                       C. Martinez
Expires: May 17, December 10, 2018                                        LACNIC
                                                       November 13, 2017
                                                            June 8, 2018

                       RPKI signed object for TAL
                    draft-ietf-sidrops-signed-tal-00
                    draft-ietf-sidrops-signed-tal-01

Abstract

   Trust Anchor Locators (TALs) [RFC7730] [I-D.ietf-sidrops-https-tal] are used by
   Relying Parties in the RPKI to locate and validate Trust Anchor
   certificates used in RPKI validation.  This document defines an RPKI
   signed object [RFC6488] for a Trust Anchor Locator (TAL) that can be published
   used by Trust Anchor to communicate a new TAL to already deployed Relying
   Parties.  The two primary use cases for this are that 1) a Trust
   Anchor may wish to change the locations where its TA certificate may
   be found, and 2) a Trust Anchor may wish Anchors to perform a planned migration to a new key.  Note that unplanned key,
   allowing Relying Parties to discover the new key rolls are considered
   out of scope for this document. up to one year after
   the migration occurred.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on May 17, December 10, 2018.

Copyright Notice

   Copyright (c) 2017 2018 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.  Requirements notation . . . . . . . . . . . . . . . . . . . .   2
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Signed TAL definition . . . . . . . . . . . . . . . . . . . .   3
     3.1.  The Signed TAL Content Type . . . . . . . . . . . . . . .   4
     3.2.  The Signed TAL eContent . . . . . . . . . . . . . . . . .   4
     3.3.  Signed TAL Validation . .
       3.2.1.  version . . . . . . . . . . . . . . . .   4
   4.  Signed TAL Generation . . . . . . .   4
       3.2.2.  activationTime  . . . . . . . . . . . . .   4
   5.  Signed TAL Publication . . . . . .   4
       3.2.3.  certificateURIs . . . . . . . . . . . . .   5
   6.  Supporting a TA Key Roll . . . . . .   4
       3.2.4.  subjectPublicKeyInfo  . . . . . . . . . . . .   5
     6.1.  Preparing a new TA key . . . .   4
     3.3.  Signed TAL Validation . . . . . . . . . . . . .   6
     6.2.  Staging period - Using both the old and the new TA key .   6
     6.3.  Preserving the Signed TAL . . . .   5
   4.  Signed TAL Generation . . . . . . . . . . . .   6
     6.4.  Retiring the old key . . . . . . . .   5
   5.  Signed TAL Publication  . . . . . . . . . .   7
     6.5.  Relying Party Use . . . . . . . . .   6
   6.  Performing a planned Key Roll as a Trust Anchor . . . . . . .   6
     6.1.  Prepare a new Trust Anchor key and CA certificate . . . .   7
   7.  Supporting changing TA
     6.2.  Publish the new CA certificate publication point(s) .  . .   7
     7.1.  Adding a publication point . . . . . . . . . . .   7
     6.3.  Verify the validity of the new CA certificate . . . .   7
     7.2.  Withdrawing a publication point . .   7
     6.4.  Publish the objects under the current key under the new
           key . . . . . . . . . . .   7
     7.3.  Publishing the Signed TAL . . . . . . . . . . . . . . . .   7
     7.4.  Relying Party Use
     6.5.  Verify that the validity of objects under the new key . .   7
     6.6.  Publish a Signed TAL as the only object under the current
           key . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . .   8
     6.7.  Delete the current key  . . . . . . . . . . . .   8
     8.1.  OID . . . . .   8
   7.  Relying Party Use . . . . . . . . . . . . . . . . . . . . . .   8
     8.2.  File Extension  . . .
   8.  Deployment Considerations . . . . . . . . . . . . . . . . . .   8
   9.  Security Considerations  Unplanned Key Roll operations . . . . . . . . . . . . . . . .   9
   10. Changing a Trust Anchor Certificate URIs  . . .   8
   10. . . . . . . .   9
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     11.1.  OID  . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     11.2.  File Extension . . . . . . . . . . . . . . . . . . . . .  10
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  10
   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   8
   11.  10
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     11.1.  10
     14.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     11.2.  10
     14.2.  Informative References . . . . . . . . . . . . . . . . .   9  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10  11

1.  Requirements notation

   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.  Introduction

   Trust Anchor Locator (TAL) files [RFC7730] Locators (TALs) [I-D.ietf-sidrops-https-tal] are used by
   Relying Parties in the Resource
   Public Key Infrastructure (RPKI) RPKI to help Relying Parties locate and
   verify a trust anchor certificate.  A TAL file consists of:

   o  One or more rsync URIs [RFC5781]

   o  A subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded validate Trust Anchor
   certificates used in
      Base64

   The TAL RPKI validation.  This document defines an RPKI
   signed object [RFC6488] for a Trust Anchor Locator (TAL) that can be distributed out-of-band
   used by Trust Anchors to perform a planned migration to a new key,
   allowing Relying Parties (RP), and
   it allows to discover the RP new key up to retrieve one year after
   the most recent migration occurred.  (Note "one year" is arbitrary, and may be
   changed in a future version of the Trust
   Anchor (TA) certificate from the cited location, and verify this document)

   Note that
   public key [RFC5011] describes Automated Updates of this certificate matches the TAL.  This is DNS Security
   (DNSSEC) Trust Anchors and can provide some useful as it
   allows selected data in the trust anchor to change, without needing
   to effect redistribution of the trust anchor per se.  In particular
   the Internet Number Resources (INRs) extension [RFC3779] and the
   publication points defined in the Subject Information Access
   [RFC6487] may be updated this way.

   The assumption is that both the URIs and key of the TA certificate
   remain stable.  However, an organisation operating a TA may wish to
   change either of these properties, because of a need to:

   o  change one or more URIs

   o  perform a planned key roll

   In this document we describe a method for TA operators to publish a
   an updated TAL in a secure a well-defined fashion, so that RPs can be
   alerted about these changes.

   Note that [RFC5011] describes Automated Updates of DNS Security
   (DNSSEC) Trust Anchors and can provide some useful insight here insight here as
   well.  However, concepts like a set of Trust Anchors, standby Trust
   Anchors, and TTLs are not applicable to the RPKI.  Therefore we
   believe that  Therefore, an
   alternative approach based on already existing concept of the Trust
   Anchor Locator [RFC7730] [I-D.ietf-sidrops-https-tal], and top-down validation
   of an RPKI Trust Anchor certificate tree, where objects are retrieved
   from the RPKI repositories, is appropriate.

3.  Signed TAL definition

   A signed

   The Signed TAL is an makes use of the template for RPKI digitally signed object,
   objects [RFC6488], which defines a Crytopgraphic Message Syntax (CMS)
   [RFC5652] wrapper for the Signed TAL content as specified in [RFC6488].
   The well as a generic
   validation procedure for RPKI signed object template requires objects.  Therefore, to complete
   the specification of the
   following data elements Signed TAL (see Section 4 of [RFC6488]),
   this document defines:

   o  The OID defined in Section 3.1 that identifies the context of signed object
      as being a Signed TAL.  (This OID appears within the manifest structure. eContentType
      in the encapContentInfo object as well as the content-type signed
      attribute in the signerInfo object).

   o  The ASN.1 syntax for the Signed TAL eContent defined in
      Section 3.2.  (This is the payload that specifies the AS being
      authorized to originate routes as well as the prefixes to which
      the AS may originate routes.)

   o  Additional steps to the validation steps specified in [RFC6488]
      required to validate Signed TALs, defined in Section 3.3.

3.1.  The Signed TAL Content Type

   This document requests an OID for signed-Tal as follows:

       signed-Tal OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
                  rsadsi(113549) pkcs(1) pkcs9(9) 16 id-smime (1) TBD }

   This OID MUST appear both within the eContentType in the
   encapContentInfo object as well as the content-type signed attribute
   in the signerInfo object (see [RFC6488]). [RFC6488])

3.2.  The Signed TAL eContent

   The content of a Signed TAL is ASN.1 encoded using the Distinguished
   Encoding Rules (DER) [X.690], and is defined as follows:

   SignedTalContent

      SignedTAL ::= SEQUENCE {
         version           [0] INTEGER DEFAULT 0,
         activationTime        GeneralizedTime,
         certificateURIs       SEQUENCE SIZE (1..MAX) OF CertificateURI,
         subjectPublicKeyInfo  SubjectPublicKeyInfo }

      CertificateURI ::= IA5String

      SubjectPublicKeyInfo ::= IA5String

3.2.1.  version

   The "SignedTalContent" contains the content version number of the new TAL encoded in
   Base64 [RFC4648].

3.3.  Signed SignedTAL MUST be 0.

3.2.2.  activationTime

   This field contains the time when this TAL Validation

   Before a Relying Party can use a Signed TAL, is intended to replace any
   previously known TAL for this Trust Anchor.

3.2.3.  certificateURIs

   This field is equivalent to the relying party URI section in section 2.1 of
   [I-D.ietf-sidrops-https-tal].  It MUST
   first validate contain at least one
   CertificateURI element.  Each CertificateURI element contains the
   IA5String representation of either an rsync URI [RFC5781], or an
   HTTPS URI [RFC7230].

3.2.4.  subjectPublicKeyInfo

   This field is equivalent to the subjectPublicKeyInfo section in
   section 2.1 of [I-D.ietf-sidrops-https-tal].

3.3.  Signed TAL. TAL Validation

   To validate determine whether a Signed TAL, TAL is valid, the relying
   party RP MUST perform all the validation checks
   following steps in addition to those specified in [RFC6488]
   as well as the following additional specific validation step. [RFC6488]:

   o  The eContentType OID matches the OID described in Section 3.1

   o  The Signed TAL appears as the EncapsulatedContentInfo product of a Trust Anchor CA
      certificate.

   o  This Trust Anchor CA has OID
      1.2.840.113549.1.9.16.1.TBD. published only one Signed TAL object in
      its repository, and this object appears on the Manifest as the
      only entry using the ".tal" extension (see [RFC6481]).  In case
      more than one Signed TAL object is found, all such objects MUST be
      considered invalid.

   o  The EE certificate of this Signed TAL is signed by a known Trust
      Anchor describes its Internet
      Number Resources (INRs) using the "inherit" attribute

   o  The decoded TAL content conforms to the format defined in
      [RFC7730]
      Section 3.2.

   If the above procedure indicates that the manifest is invalid, then
   the Signed TAL MUST be discarded and treated as though no Signed TAL
   were present.

4.  Signed TAL Generation

   A TA MAY choose to generate a single Singed TAL object to publish in
   its TA certificate publication point(s) in the RPKI.  The TA MUST
   perform the following steps to generate the Signed TAL:

   o  Generate a key pair for a "one-time-use" EE certificate to use for
      the Signed TAL

   o  Generate a one-time-use EE certificate for the Signed TAL

   o  This EE certificate MUST have an SIA extension access description
      field with an accessMethod OID value of id-ad-signedobject, where
      the associated accessLocation references the publication point of
      the Sigend TAL as an object URL.

   o  As described in [RFC6487], an [RFC3779] extension is required in
      the EE certificate used for this object.  However, because the
      resource set is irrelevant to this object type, this certificate
      MUST describe its Internet Number Resources (INRs) using the
      "inherit" attribute, rather than explicit description of a
      resource set.

   o  This EE certificate MUST have a "notBefore" time that is before
      the moment that the Signed TAL will be published.

   o  This EE certificate MUST have a "notAfter" time that reflects the
      intended time that this Signed TAL will be published.  If the EE
      certificate for a Signed TAL is expired, it MUST no longer be
      publish, but of course it MAY be replaced by a newly generated
      Signed TAL object with similar content and an updated "notAfter"
      time.

   o  The Signed TAL MUST have an "activationTime" that reflects when
      Relying Parties MUST use use this new TAL in place of any
      previously known TAL for this Trust Anchor.

5.  Signed TAL Publication

   A TA MAY publish a single Signed TAL object directly under its CA
   repository publication points.  The TA MUST NOT publish multiple
   Signed TAL objects at any time.  It is RECOMMENDED that a TA
   publishes a Signed TAL object for its current key and CA certificate
   publication URIs at all times.

   A non-normative guideline for naming this object is that the filename
   chosen for the signed TAL in the publication repository be a value
   derived from the public key part of the entity's key pair, using the
   algorithm described for CRLs in section 2.2 of [RFC6481] for
   generation of filenames.  The filename extension of ".tal" MUST be
   used to denote the object as a signed TAL.  Note that this is in-line
   with filename extensions defined in section 7.2 of [RFC6481]. [RFC6481]

6.  Supporting  Performing a TA planned Key Roll as a Trust Anchor

   A Signed TAL MAY SHOULD be used to communicate a planned key roll for by a
   Trust Anchor.  From the
   TA.

6.1.  Preparing Trust Anchor perspective a new TA planned key

   Prior to publishing the Signed TAL for roll
   consists of the following steps:

   o  Prepare a new key the TA MUST
   perform Trust Anchor key and CA certificate, see Section 6.1

   o  Publish the following steps: new CA certificate, see Section 6.2

   o  Generate a  Verify the validity of the new CA certificate, see Section 6.3

   o  Publish the objects under the current key pair for under the new TA certificate key, see
      Section 6.4

   o  Generate  Verify that the validity of objects under the new key, see
      Section 6.5

   o  Publish a Signed TAL as the only object under the current key, see
      Section 6.6

   o  Delete the current key, see Section 6.7

6.1.  Prepare a new TA Certificate, using Trust Anchor key and CA certificate

   The Trust Anchors MUST a new key pair and generate a new TA
   Certificate.  For the Subject Information Access
      for CA certificates (see section 4.8.8.1
   of [RFC6487]) that
      references the this MUST use URIs that will be used by the new key to
   publish
      objects, that are different from the objects.  These URIs used MUST be uniqe for use by this new key
   only.  The Internet Number Resources on this new certificate MUST be
   equivalent to those found on the TA current certificate.

6.2.  Publish the new CA certificate

   The new CA certificate MUST be published under one or more new
   Certificate URIs for use by this new key only.

6.3.  Verify the validity of the new CA certificate

   The Trust Anchor MUST generate a new (unsigned) TAL file
   [I-D.ietf-sidrops-https-tal] and verify with RP software that the new
   Trust Anchor certificate can be retrieved from all locations and that
   it matches the subjectPublicKeyInfo

6.4.  Publish the objects under the current key.

   o key under the new key

   ALL current signed certificates and other objects, with the exception
   of the old CRL, Manifest and existing Signed TAL, must be re-
      issued re-issued by
   the new key and published under the new publication point(s).

   o  The new TA certificate itself MUST be published in a (number of)
      new location(s) that are different from where the TA certificate
      for the current key

   It is published.

   After these steps are performed RECOMMENDED that a new Signed TAL MUST be object is generated as
   described in Section 4, and published as described in Section 5.

6.2.  Staging period - Using both the old and
   published, listing the Certificate URIs for this new TA key

   The staging period is initiated by key, the initial publication
   subjectPublicKeyInfo of a
   Signed TAL for the this new key key, and must be last at least 24 HOURS.
   During the staging period using an "activationTime"
   that is effective immediately.  Note that Relying Parties will not
   discover this new Signed TAL object until they have effectively
   switched over from the TA MUST continue to operate both current key.

6.5.  Verify that the
   old and validity of objects under the new TA key.  Note key

   The Trust Anchor MUST verify that this is validation using the same staging period
   used for key roll of normal CAs new TAL file
   generated in the RPKI, described Section 6.3 results in [RFC6489].

6.3.  Preserving the Signed set of valid objects as when
   the current TAL

   The TA SHOULD preserve file is used.

6.6.  Publish a Signed TAL for the old key after the staging
   period as a hint for RPs that missed the only object under the current key roll.

   The following
   process can be used to achieve this:

   o  Produce a new long-lived CRL that revokes all previously signed
      certificates

   o  Produce Trust Anchor MUST publish a new long-lived Signed TAL

   o  Produce TAL, CRL and Manifest as
   the only objects under the current, to be deleted, key.  The
   "nextUpdate" values of the Manifest and CRL objects SHOULD use a new long-lived manifest date
   that includes is set at least one year into the CRL and Signed
      TAL

   o  Publish future. (arbitrary value, open
   to suggestions).  The "notValidAfter" date on the CRL, MFT Manifest and Signed
   TAL
   o  Destroy EE certificate SHOULD use this same date.  The Trust Anchor MUST
   ensure that this Signed TAL, CRL and Manifest remain available for
   download for this full period.  Note that this is done to give RPs
   the old TA opportunity to discover the new key

6.4.  Retiring up to one year after the old key

   The TA
   roll occurred.

6.7.  Delete the current key

   As the final step the current key, which has been replaced now,
   SHOULD retire and delete its old be deleted.  The new key after can now be marked as the staging period
   is over.

6.5. current key.

7.  Relying Party Use

   When an RP discovers a valid Signed TAL signed under a TA, and it
   notices that the contained TAL is different "subjectPublicKeyInfo" has changed and/or the set of
   "Certificate URIs" has changed from its current TAL the values it knew for this TA TA,
   and that the "subjectPublicKeyInfo" has changed, "activationTime" is in the past, then the RP MUST replace the TAL accept
   these new values for this TA with the new TAL, TA, abort the current top-down validation
   operation, and initiate a new top-down validation operation using the
   updated TAL.

   It is RECOMMENDED information.

   Note that the software informs Trust Anchor MUST have verified that all objects are
   available under the operator of this
   event.

7.  Supporting changing TA certificate publication point(s)

   A signed TAL MAY be used to communicate an addition or removal of one
   or more publication locations where new key (Section 6.5) and that that the TA CA
   certificate can be found.

7.1.  Adding a publication point

   When adding a publication point retrieved and validated for a TA certificate, the TA MUST
   publish the certificate all new URIs
   (Section 6.3).

8.  Deployment Considerations

   Including Signed TAL objects while RP tools do not support this
   standard will result in these RPs rejecting these objects.  It is not
   expected that this will result in the new location(s) prior to publication invalidation of the Signed TAL.

7.2.  Withdrawing a publication point

   When removing any other
   object under a publication point for TA certificate, the TA SHOULD
   observe Trust Anchor.

   That said, the flagging mechanism introduced here can only be trusted
   on once a staging period majority of RPs support it.  Defining when that moment
   arrives is by definition something that cannot be established at least 24 Hours. the
   time of writing this document.

   However, once the majority of RPs support this mechanism it would be
   RECOMMENDED that Trust Anchor operators perform key rolls regularly.

   The staging period most assured way to know that such planned rolls will work is
   initiated by the publication
   making them a part of an updated Signed TAL normal operations.

9.  Unplanned Key Roll operations

   The mechanism described in this document is not applicable to
   uplanned key rolls.  Unplanned key rolls could theoretically be
   supported by a mechanism where a new key is introduced before it's
   used, with the
   publication point has been removed.  During power to revoke the staging period current key.  This would have to
   be signalled from the TA
   SHOULD keep new key, as the old publication point up TA may have lost access to date and available.

7.3.  Publishing the Signed TAL

   It is RECOMMENDED that its
   current key.

   However, this introduces a Trust Anchor publishes great amount of operational complexity as
   well as a valid Signed TAL new vulnerability: an adversary would need access to only
   one of these keys in order to compromise a TA.

   With that in mind we believe, for what it believes its current TAL now, that unplanned key rolls
   should not be at all times.

7.4. covered here, and would need to be communicated to
   Relying Party Use

   When an RP discovers Parties in some other out-of-band fashion.

10.  Changing a Trust Anchor Certificate URIs

   Earlier versions of this document included a valid description of how
   Signed TAL signed under objects could be used to signal a TA, and it
   notices that change of Certificate
   URIs only; i.e. where the contained TAL key is different from its current TAL for
   this TA and not changed.

   However, Relying Parties that the "subjectPublicKeyInfo" has do not changed, then the
   RP MUST replace support the TAL for mechanism described
   in this TA with document would not be able to learn about the new TAL changes in
   URIs.  While for future use,
   but can continue the current top-down validation operation.

   It is RECOMMENDED RPs that do support this mechanism a planned key
   roll will be a normal part of RPKI validation.

   Therefore we believe that a planned key roll should be used in cases
   like this, and that the software informs the operator set of this
   event.

8. Certificate URIs for any given key
   must never be changed.

11.  IANA Considerations

8.1.

11.1.  OID

   IANA is to add the following to the "RPKI Signed Objects" registry:

          Decimal | Description                    | References
          --------+--------------------------------+---------------
          TBD     | signed-Tal                     | [section 3.1]

8.2.

11.2.  File Extension

   IANA is to add an item for the Signed TAL file extension to the "RPKI
   Repository Name Scheme" created by [RFC6481] as follows:

          Extension  |   RPKI Object           Reference
         -------------------------------------------------------              | References
          -----------+-------------------------------------------
           .tal      |   Signed TAL               | [this document]

9.

12.  Security Considerations

   TBD

10.

13.  Acknowledgements

   TBD

11.

14.  References

11.1.

14.1.  Normative References

   [I-D.ietf-sidrops-https-tal]
              Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
              Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
              Trust Anchor Locator", draft-ietf-sidrops-https-tal-03
              (work in progress), June 2018.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <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,
              <https://www.rfc-editor.org/info/rfc3779>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [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",

   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
              Trust Anchors", STD 74, RFC 5280, 5011, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>. 10.17487/RFC5011,
              September 2007, <https://www.rfc-editor.org/info/rfc5011>.

   [RFC5781]  Weiler, S., Ward, D., and R. Housley, "The rsync URI
              Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010,
              <https://www.rfc-editor.org/info/rfc5781>.

   [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>.

   [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>.

   [RFC7730]  Huston, G., Weiler, S., Michaelson, G.,

   [RFC7230]  Fielding, R., Ed. and S. Kent,
              "Resource Public J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <https://www.rfc-editor.org/info/rfc7230>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Infrastructure (RPKI) Trust Anchor
              Locator", Words", BCP 14, RFC 7730, 8174, DOI 10.17487/RFC7730, January 2016,
              <https://www.rfc-editor.org/info/rfc7730>.

   [X.509]    ITU-T Recommendation X.509 (2000), "Recommendation X.509:
              The Directory - Authentication Framework", 2000. 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [X.690]    ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
              "Information technology - ASN.1 encoding rules:
              Specification of Basic Encoding Rules (BER), Canonical
              Encoding Rules (CER) and Distinguished Encoding Rules
              (DER)", 2002.

11.2.

14.2.  Informative References

   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
              Trust Anchors",

   [RFC5652]  Housley, R., "Cryptographic Message Syntax (CMS)", STD 74, 70,
              RFC 5011, 5652, DOI 10.17487/RFC5011, 10.17487/RFC5652, September 2007, <https://www.rfc-editor.org/info/rfc5011>.

   [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>. 2009,
              <https://www.rfc-editor.org/info/rfc5652>.

Authors' Addresses

   Tim Bruijnzeels
   RIPE NCC
   NLnet Labs

   Email: tim@ripe.net tim@nlnetlabs.nl
   URI:   https://www.nlnetlabs.nl/
   Carlos Martinez
   LACNIC

   Email: carlos@lacnic.net
   URI:   https://www.lacnic.net/