Network Working Group                                     T. Bruijnzeels
Internet-Draft                                                NLnet Labs
Intended status: Best Current Practice Standards Track                             C. Martinez
Expires: December 10, 2018 April 19, 2019                                           LACNIC
                                                            June 8,
                                                              R. Austein
                                                    Dragon Research Labs
                                                        October 16, 2018

                RPKI signed object Signed Object for TAL
                    draft-ietf-sidrops-signed-tal-01 Trust Anchor Keys
                    draft-ietf-sidrops-signed-tal-02

Abstract

   Trust Anchor Locators (TALs) [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) Keys (TAK), that can be used by Trust
   Anchors to perform a planned migration signal their set of current keys and the location(s) of
   the accompanying CA certiifcates to a new key,
   allowing Relying Parties Parties, as well as
   changes to discover this set in the form of revoked keys and new key up keys, in
   order to one year after
   the migration occurred. support both planned and unplanned key rolls without
   impacting RPKI validation.

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 December 10, 2018. April 19, 2019.

Copyright Notice

   Copyright (c) 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   3
   2.  Introduction  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Signed TAL  TAK Object definition . . . . . . . . . . . . . . . . . . . .   3   4
     3.1.  The Signed TAL TAK Object Content Type . . . . . . . . . . . . . . .   4   5
     3.2.  The Signed TAL TAK Object eContent . . . . . . . . . . . . . . . . .   4   5
       3.2.1.  version . . . . . . . . . . . . . . . . . . . . . . .   4   5
       3.2.2.  activationTime  current . . . . . . . . . . . . . . . . . . .   4
       3.2.3.  certificateURIs . . . .   5
       3.2.3.  revoked . . . . . . . . . . . . . . .   4
       3.2.4.  subjectPublicKeyInfo . . . . . . . .   6
     3.3.  TAK Object Validation . . . . . . . .   4
     3.3.  Signed TAL Validation . . . . . . . . . .   6
   4.  Maintaining multiple TA keys  . . . . . . . .   5
   4.  Signed TAL Generation . . . . . . . .   7
     4.1.  Prepare a new TA key  . . . . . . . . . . . .   5
   5.  Signed TAL Publication . . . . . .   7
     4.2.  Publishing for Multiple TA Keys . . . . . . . . . . . . .   6
   6.  Performing a planned Key Roll as a Trust Anchor   7
   5.  TAK Object Generation and Publication . . . . . . .   6
     6.1.  Prepare a new Trust Anchor key and CA certificate . . . .   7
     6.2.  Publish the new CA certificate .   8
   6.  Performing TA Key Rolls . . . . . . . . . . . .   7
     6.3.  Verify the validity of the new CA certificate . . . . . .   7
     6.4.  Publish the objects under the current key under the new
           key .   9
     6.1.  Opting in to Key Rolls  . . . . . . . . . . . . . . . . .  10
       6.1.1.  Trust Anchor  . . . . . . . . .   7
     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 . . . . . . . . .  10
       6.1.2.  Relying Parties . . . . . . . . . . . . . . . . . .   8
     6.7.  Delete the current key .  12
     6.2.  Pre-stage a New Key . . . . . . . . . . . . . . . .   8
   7.  Relying Party Use . . .  12
       6.2.1.  Trust Anchor  . . . . . . . . . . . . . . . . . . .   8
   8.  Deployment Considerations .  12
       6.2.2.  Relying Parties . . . . . . . . . . . . . . . . .   8
   9.  Unplanned . .  14
     6.3.  Planned Key Roll operations Revocation  . . . . . . . . . . . . . . . .   9
   10. Changing a .  14
       6.3.1.  Trust Anchor Certificate URIs  . . . . . . . . . .   9
   11. IANA Considerations . . . . . . . . . .  14
       6.3.2.  Relying Parties . . . . . . . . . . .   9
     11.1.  OID . . . . . . . .  17
     6.4.  Unplanned revocation  . . . . . . . . . . . . . . . . . .   9
     11.2.  17
       6.4.1.  Trust Anchor  . . . . . . . . . . . . . . . . . . . .  17
   7.  Deployment Considerations . . . . . . . . . . . . . . . . . .  18
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
     8.1.  OID . . . . . . . . . . . . . . . . . . . . . . . . . . .  18
     8.2.  File Extension  . . . . . . . . . . . . . . . . . . . . .  10
   12.  19
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   13.  19
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   14.  19
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     14.1.  19
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     14.2.  19
     11.2.  Informative References . . . . . . . . . . . . . . . . .  11  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11  21

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 BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Introduction  Overview

   Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] are used by
   Relying Parties in the RPKI to locate and validate Trust Anchor (TA)
   certificates used in RPKI validation.  However, until now there has
   been no formal way of notifying Relying Parties (RP) of updates to a
   TAL.  Such updates may be needed in particular in case a Trust Anchor
   needs to perform a planned, or unplanned, key roll.

   This document defines an a new RPKI signed object [RFC6488] for a Trust Anchor Locator (TAL) that can be used by Trust Anchors to perform a planned migration to a new key,
   allowing Relying Parties to discover the new key up to one year after
   document the migration occurred.  (Note "one year" is arbitrary, current set of keys and may be
   changed in a future version the loctaion(s) of the
   accompanying CA certificates, as well as any changes to this document)

   Note that [RFC5011] describes Automated Updates set.
   This allows RPs to be notified automatically of DNS Security
   (DNSSEC) such changes, and
   enables Trust Anchors and can provide some useful insight here as
   well.  However, concepts like to pre-stage a set number of Trust Anchors, standby Trust
   Anchors, operational keys so
   that planned and TTLs are not applicable to unplanned key rolls can be performed without risking
   the RPKI.  Therefore, an
   alternative approach based on already existing concept invalidation of the Trust
   Anchor Locator [I-D.ietf-sidrops-https-tal], and top-down validation
   of an RPKI tree under the TA.  We call this object
   the Trust Anchor certificate tree, where objects Keys (TAK) object.

   When Relying Parties (RPs) are retrieved
   from the RPKI repositories, is appropriate.

3.  Signed first bootstrapped, they use any
   current TAL definition

   The Signed TAL makes use to discover a key and location(s) of the template TA
   certificate(s) for RPKI digitally signed
   objects [RFC6488], which defines a Crytopgraphic Message Syntax (CMS)
   [RFC5652] wrapper for TA.  The RP can then retreive and validating the Signed TAL content as well as a generic
   validation procedure for RPKI signed objects.  Therefore, to complete
   TA certificate, and subsequently validate the specification manifest [RFC6486] and
   CRL [section 5 of @!RFC6487].  However, before processing any other
   objects it will then first validate the Signed TAL (see Section 4 TAK object, if present.  All
   enumarated new keys (and locations) are then added to a new list of [RFC6488]),
   current TA keys for this document defines:

   o TA.  The OID defined in Section 3.1 that identifies RP will then recursively fetch and
   validate the signed object
      as being TA certificates, manifest, CRL and TAK objects for each
   of these keys.  As a Signed TAL.  (This OID appears within the eContentType
      in part of this process the encapContentInfo object as well as RP will also compile a
   list of revoked keys enumarated by any of the content-type validly signed
      attribute in TAK
   objects.  As the signerInfo object).

   o  The ASN.1 syntax for final step the Signed TAL eContent defined in
      Section 3.2.  (This is RP will then filter out any revoked
   TA keys from its new set.  This new set now replaces the payload that specifies previous
   set.

   If the AS being
      authorized key used to originate routes as well as start this process is still considered current,
   then validation continues.  But if the prefixes to which key was revoked, then
   validation is restarted using one of the AS may originate routes.)

   o  Additional steps remaining keys in the set.

   This process allows Trust Anchors to operate a set of N current keys,
   where any key can effectively revoke any or all of the validation steps specified in [RFC6488]
      required other keys to validate Signed TALs, defined in Section 3.3.

3.1.  The Signed TAL Content Type
   perform either a planned, or an unplanned, key roll.  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 also
   allows Trust Anchors to produce long lived TAK objects as forward
   pointers to RPs, and retire its old key when doing a key roll.

   While the content-type signed attribute
   in generic process is quite involved, the signerInfo object (see [RFC6488])

3.2.  The Signed TAL eContent

   The content amount of work
   needed to support an envisioned normal key roll is fairly limited.
   Under normal circumstances a Signed TAL TA will typically have two current keys,
   so that is ASN.1 encoded using can perform an emergency roll over in case one of the Distinguished
   Encoding Rules (DER) [X.690], keys
   is lost.  This means that the RP will need to validate two TAK
   objects.  However, typically these files will agree that both keys
   are current and validation continues.

   When a key roll is defined as follows:

      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 executed a TA will remove one old key, and
   introduce one new (back-up) key.  The version number of RP will remove the SignedTAL MUST old key from
   its set, and it will not be 0.

3.2.2.  activationTime

   This field contains queried again, and it will add the time when this TAL is intended to replace any
   previously known TAL for this Trust Anchor.

3.2.3.  certificateURIs

   This field new
   key and its TA certifcate location(s).

   Only in a situation where an RP is equivalent very outdated can it be expected
   that the RP will have to discover several chained TAK object.  But,
   since it will remove the URI section outdated TALs in section 2.1 of
   [I-D.ietf-sidrops-https-tal].  It MUST contain at least this process, this presents
   a 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 time cost only.

   Note that in
   section 2.1 theory a TA can revoke all of [I-D.ietf-sidrops-https-tal].

3.3.  Signed TAL Validation

   To determine whether its keys and make itself
   obsolete.  In practice however, a Signed TAL is valid, the RP MUST perform the
   following steps well operated TA will have measures
   in addition place to those specified in [RFC6488]:

   o  The eContentType OID matches prevent this.  Furthermore they can protect themselves
   against key loss to adversaries through the OID described in Section 3.1

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

   o  This Trust Anchor CA has published only one Signed TAL object in
      its repository, and Hardware Security Module (HSM) to protect keys.  Protecting against
   this object appears mis-operation would incur complexity and guesswork on the Manifest as RPs.
   Therefore it is believed that it is best to keep the
      only entry using process
   straightforward, and offer a solution for the ".tal" extension (see [RFC6481]).  In case more than one Signed TAL object likely issues of
   loss of a key, e.g.  because an HSM or card set is found, all such objects MUST be
      considered invalid.

   o broken, and
   planned key rolls.

3.  TAK Object definition

   The EE certificate TAK object makes use of this Signed TAL describes its Internet
      Number Resources (INRs) using the "inherit" attribute

   o  The decoded TAL template for RPKI digitally signed
   objects [RFC6488], which defines a Crytopgraphic Message Syntax (CMS)
   [RFC5652] wrapper for the Signed TALs content conforms as well as a generic
   validation procedure for RPKI signed objects.  Therefore, to complete
   the format specification of the TAK object (see Section 4 of [RFC6488]),
   this document defines:

   o  The OID defined in Section 3.2.

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

4.  Signed TAL Generation

   A TA MAY choose to generate being a single Singed TAL object to publish TAK.  (This OID appears within the eContentType in
   its TA certificate publication point(s) the
      encapContentInfo object as well as the content-type signed
      attribute in the RPKI. signerInfo object).

   o  The TA MUST
   perform ASN.1 syntax for the following TAK eContent defined in Section 3.2.

   o  Additional steps to generate the Signed TAL:

   o  Generate a key pair for a "one-time-use" EE certificate validation steps specified in [RFC6488]
      required to use for
      the Signed TAL

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

   o TAK, defined in Section 3.3.

3.1.  The TAK Object Content Type

   This EE certificate MUST have an SIA extension access description
      field with document requests an accessMethod OID value of id-ad-signedobject, where
      the associated accessLocation references for TAK objects 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 publication point of eContentType in the Sigend TAL as an
   encapContentInfo object URL.

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

3.2.  The TAK Object eContent

   The content of a
      resource set.

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

   o  This EE certificate MUST have a "notAfter" time that reflects ASN.1 encoded using the
      intended time that this Signed TAL will be published.  If the EE
      certificate for a Signed TAL Distinguished
   Encoding Rules (DER) [X.690], and is expired, it MUST no longer be
      publish, but defined as follows:

      TAK ::= SEQUENCE {
         version   INTEGER DEFAULT 0,
         current   ::= SEQUENCE SIZE (1..MAX) OF CurrentKey,
         revoked   ::= SEQUENCE OF SubjectPublicKeyInfo
      }

      CurrentKey ::= SEQUENCE {
         certificateURIs       SEQUENCE SIZE (1..MAX) OF CertificateURI,
         subjectPublicKeyInfo  SubjectPublicKeyInfo
      }

      CertificateURI ::= IA5String

      SubjectPublicKeyInfo ::= SEQUENCE {
           algorithm            AlgorithmIdentifier,
           subjectPublicKey     BIT STRING
      }

3.2.1.  version

   The version number of course it MAY be replaced by a newly generated
      Signed TAL the TAK 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 be 0.

3.2.2.  current

   This field defines the set of current keys (CurrentKey) according to
   the signer 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 TALs object.

3.2.2.1.  CurrentKey

   This field defines a current TA
   publishes Key, equivalent to [I-D.ietf-sidrops-
   https-tal].  This structure contains a Signed TAL object for its current key and CA certificate
   publication sequence of one or more 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
   and a value
   derived from the public key part of the entity's key pair, using SubjectPublicKeyInfo.

3.2.2.1.1.  certificateURIs

   This field is equivalent to the
   algorithm described for CRLs URI section in section 2.2 of [RFC6481] for
   generation of filenames.  The filename extension 2.1 of ".tal"
   [I-D.ietf-sidrops-https-tal].  It 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 contain at least one
   CertificateURI element.  Each CertificateURI element contains the
   IA5String representation of [RFC6481]

6.  Performing a planned Key Roll as either an rsync URI [RFC5781], or an
   HTTPS URI [RFC7230].

3.2.2.1.2.  subjectPublicKeyInfo

   This field contains a Trust Anchor

   A Signed TAL SHOULD SubjectPublicKeyInfo [section 4.1.2.7 or
   @!RFC5280] in DER format [X.690].

3.2.3.  revoked

   This field contains the list of keys, identified by
   SubjectPublicKeyInfo, that are no longer to be used according to communicate a planned key roll by a
   Trust Anchor.  From the Trust Anchor perspective a planned key roll
   consists
   signer of this document.

3.3.  TAK Object Validation

   To determine whether a TAK object is valid, the RP MUST perform the
   following steps: steps in addition to those specified in [RFC6488]:

   o  Prepare  The eContentType OID matches the OID described in Section 3.1

   o  The TAK object appears as the product of a new Trust Anchor key and CA certificate, see Section 6.1
      certificate.

   o  Publish the new  This Trust Anchor CA certificate, see Section 6.2

   o  Verify has published only one TAK object in its
      repository for this key, and this object appears on the validity of Manifest
      as the new CA certificate, see Section 6.3

   o  Publish only entry using the ".tak" extension (see [RFC6481]).  In
      case more than one TAK object is found, all such objects under MUST be
      considered invalid.

   o  The EE certificate of this TAK object describes its Internet
      Number Resources (INRs) using the current key under "inherit" attribute

   o  The decoded TAK content conforms to the new key, see format defined in
      Section 6.4

   o  Verify 3.2.

   If the above procedure indicates that the validity of objects under manifest is invalid, then
   the new key, see
      Section 6.5

   o  Publish a Signed TAL TAK object MUST be discarded and treated as the only though no TAK object under the current key, see
      Section 6.6

   o  Delete the current key, see
   were present.

4.  Maintaining multiple TA keys

   As described in Section 6.7

6.1.  Prepare 6 a new Trust Anchor TA will most likely choose to operate two
   keys at any one time in order to be prepared for an emergency key
   roll.  When a TA operates multiple keys, each key MUST use its own CA
   repository publication point as described in [RFC6481].  The CRL and
   Manifest [RFC6486] for each of these keys will be unique to each key,
   but the TA MUST ensure that equivalent CA certificates and RPKI
   signed objects are issued under each key.  Note that this is similar
   to how such certificates and RPKI signed objects are re-issued as
   part of a lower level CA certificate key roll, described in section 4 of
   [RFC6489].

4.1.  Prepare a new TA key

   The Trust Anchors MUST generate a new key pair and generate a new TA
   Certificate.  For the Subject Information Access (see section 4.8.8.1
   of [RFC6487]) this MUST use URIs that will be used by the new key to
   publish objects.  These URIs 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 current certificate.

6.2.  Publish the new CA certificate

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

6.3.  Verify

   As decribed above, the TA MUST issue and publish equivalent CA
   certificates and RPKI signed objects under this new key.

   It is RECOMMENDED that the TA now generates a new TAL
   [I-D.ietf-sidrops-https-tal] and verifies that the new Trust Anchor
   certificate can be retrieved from all locations, and that it
   generates the same results when it is used for top-down validation
   instead of (any of) the current TA key(s).

   Note that the TA MAY choose to make this TAL available to Relying
   Parties, in particular to those that do not support TAK objects, and
   for inclusion in the distribution of RP software in order to minimise
   the overhead in bootstrapping fresh installations.

4.2.  Publishing for Multiple TA Keys

   If a TA uses a single remote publication server for its keys using
   the RPKI publication protocol [RFC8181], then it MUST include all
   <publish/> and <withdraw/> PDUs for the validity products of each of its keys
   in a single query in order to ensure that they will reflect the same
   content at all times.

   If a TA uses multiple publication servers then it is by definition
   inevitable that the content of different keys will be out of sync at
   times.  In such cases the TA SHOULD ensure that the duration of these
   moments are limited to the shortest possible time.  Furthermore the
   following should be observed:

   o  It is strongly RECOMMENDED that TAs do not issue any RPKI Signed
      Objects, such as ROAs [RFC6482], but limit their operations to
      maintaining a CRL, Manifest and CA certificates only.  If an
      organisation maintaining a TA has an operational need for such
      objects then it is strongly RECOMMENDED that they operate a
      separate non-TA CA as a child of their TA for these operations.
      If this approach is used the remaining issues regarding temporary
      inconsistencies between multiple TA key repository publication
      points is greatly reduced.

   o  In cases where a CA certificate is revoked completely, or replaced
      by a certifcate with a reduced set of resources, these changes
      will not take effect fully until all the TA keys repository
      publication points have been updated.  Given that TA key
      operations are normally performed infrequently we don't expect
      that this is a problem.  I.e. if the revocation or shrinking of an
      issued CA certificate is staged for days, or weeks anyway, then
      experiencing a delay of several minutes for the repository
      publication points to all be updated is fairly insignificant.

   o  In cases where a CA certificate is replaced by a certifcate with
      an extend set of resources the TA MUST inform the receiving CA
      only after all its repository publication points have been
      updated.  This ensures that the receiveing CA will not issue any
      products that could be invalid if an RP uses a TA key just before
      the CA certificate was due to be updated.

5.  TAK Object Generation and Publication

   A TA MAY choose to use TAK objects to communicate its set of current,
   and revoked keys.  If a TA chooses to use TAK objects, then it SHOULD
   generate and publish TAK objects under each of its current keys.  An
   exception to this rule exists when a TA has lost permanent access to
   one of its keys or the accompanying repository publication point.  In
   such cases however, the key in question MUST be revoked as described
   below in Section 6.

   A non-normative guideline for naming this object is that the filename
   chosen for the Signed TAL Object 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 ".tak" MUST
   be used to denote the object as a TAK.  Note that this is in-line
   with filename extensions defined in section 7.2 of [RFC6481]

   In order to generate the TAK Objects, the TA MUST perform the
   following actions:

   o  The TA MUST generate a key pair for a "one-time-use" EE
      certificate to use for the TAK

   o  The TA MUST generate a one-time-use EE certificate for the TAK

   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 TAK 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 matches, or
      predates the moment that the TAK will be published.

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

   o  The same set of current keys (see Section 3.2.2) MUST be included
      on each TAK object for each current key.

   o  The TAK object MUST include all revoked keys (see Section 3.2.3)
      that became revoked while the key signing the TAK in question was
      current.

6.  Performing TA Key Rolls
6.1.  Opting in to Key Rolls

6.1.1.  Trust Anchor

   For simplicitly let's start with a situation where a TA has only one
   key.  The TA wants to start using TAK objects to perform key rolls in
   future, so it introduces a TAK object under its single key 'A'.  The
   repository structure looks as follows (irrelevant details omitted):

                          +--------------------+
                          |        A.MFT       |
                          +--------------------+
                          | A.CRL      <hash>  |
                          | A.TAK      <hash>  |
                          | C1-A.CER   <hash>  |
                          | C2-A.CER   <hash>  |
                          +--------------------+

                          +--------------------+
                          |        A.CRL       |
                          +--------------------+
                          | revocations..      |
                          +--------------------+

                          +--------------------+
                          |        A.TAK       |
                          +--------------------+
                          | current: A         |
                          | revoked: none      |
                          +--------------------+

                          +--------------------+
                          |      C1-A.CER      |
                          +--------------------+
                          | resources: C1 res  |
                          | subject:   C1 name |
                          | pub key:   C1 key  |
                          | SIA:       C1 SIAs |
                          | AKI:       A       |
                          +--------------------+

                          +--------------------+
                          |      C2-A.CER      |
                          +--------------------+
                          | resources: C2 res  |
                          | subject:   C2 name |
                          | pub key:   C2 key  |
                          | SIA:       C2 SIAs |
                          | AKI:       A       |
                          +--------------------+

   So, the TA publishes a CRL and MFT under its key A, listing a TAK
   object and in this case two certificates issued to children 'C1' and
   'C2' signed using key A.  The TAK object lists key 'A' as the only
   current key, and has no revoked keys.

6.1.2.  Relying Parties

   Relying Parties who have a TAL for key 'A' configured will discover
   the TAK object.  If the RP does not support this object, it will
   reject this object but continue to validate the remaining RPKI tree
   as usual.  If the RP does support TAK objects it will conclude that
   key 'A' is the one and only current key, and will proceed to validate
   the remaining RPKI tree as usual.

6.2.  Pre-stage a New Key

6.2.1.  Trust Anchor

   Now the TA prestages a new key 'B' and produces equivalent CA
   certificates for children 'C1' and 'C2', i.e. the resources, subject
   name, public key and SIA etc are all equivalent, but these
   certificates are signed under key 'B'.  (See Section 4 for a more
   thorough description of this).  The TAK object for key 'B' recognises
   both keys 'A' and 'B' as current.

   The repostory structure and TAK object for key B are then as follows:

                          +--------------------+
                          |        B.MFT       |
                          +--------------------+
                          | B.CRL      <hash>  |
                          | B.TAK      <hash>  |
                          | C1-B.CER   <hash>  |
                          | C2-B.CER   <hash>  |
                          +--------------------+

                          +--------------------+
                          |        B.CRL       |
                          +--------------------+
                          | revocations..      |
                          +--------------------+

                          +--------------------+
                          |        B.TAK       |
                          +--------------------+
                          | current: A, B      |
                          | revoked: none      |
                          +--------------------+

                          +--------------------+
                          |      C1-B.CER      |
                          +--------------------+
                          | resources: C1 res  |
                          | subject:   C1 name |
                          | pub key:   C1 key  |
                          | SIA:       C1 SIAs |
                          | AKI:       B       |
                          +--------------------+

                          +--------------------+
                          |      C2-B.CER      |
                          +--------------------+
                          | resources: C2 res  |
                          | subject:   C2 name |
                          | pub key:   C2 key  |
                          | SIA:       C2 SIAs |
                          | AKI:       B       |
                          +--------------------+

   When the TA is certain that the content for key 'B' is correct, it
   can also update the TAK object for key 'A' to include 'B':

                          +--------------------+
                          |        A.TAK       |
                          +--------------------+
                          | current: A, B      |
                          | revoked: none      |
                          +--------------------+

   One way to do this is by generating a TAL
   [I-D.ietf-sidrops-https-tal] for key B and verifying that validation
   using this yields the same results as validation using the TAL for
   key A would.  However, note, that it is preferred that this is done
   as part of an automated process that is sufficiently well tested, and
   that the contents of the repositories for keys 'A' and 'B' are
   updated as a single delta if the publication protocol [RFC8181] is
   used (see also: Section 5).

6.2.2.  Relying Parties

   Relying Parties who have a TAL for key 'A' configured will discover
   the TAK object.  If the RP does not support this object, it will
   reject this object but continue to validate the remaining RPKI tree
   as usual.  If the RP does support TAK objects it will conclude that
   there are now two keys 'A' and 'B', and no revoked keys that it
   should be aware of.  Since key 'A' is still current, the RP will
   continue to validate the RPKI tree structure using the repository for
   key 'A', ignoring the non-TAK objects in the repository for key 'B'.

   The result will be the same for Relying Parties who have a TAL for
   key 'B' configured, because both keys are equivalent at this time.

6.3.  Planned Key Revocation

6.3.1.  Trust Anchor

   The TA has now decided that key 'A' must be revoked.  It still has
   access to this key and the repository, so it can perform a planned
   key roll.  In addition to revoking key 'A', the TA will also generate
   new key 'C' to ensure that it has at least two current keys at all
   times for redundancy.

   Keys 'B' and 'C' will become current keys on the TAK objects for all
   keys: 'A', 'B' and 'C'.  Key 'A' will become part of the revoked keys
   on the TAK objects for keys 'A' and 'B'.  Note that it is not needed
   to list key 'A' as revoked on the TAK file for key 'C', because RPs
   will only learn about key 'C' at the same time as learning about the
   revocation of key 'A' (see also below).

   The TA will publish a long-lived TAK file and MFT and CRL only for
   key 'A' and publish these objects as waypointers for RPs that have a
   TAL pointing at key 'A' before destroying key 'A'.

   The resulting structure for key 'A' will be as follows:

                          +--------------------+
                          |        A.MFT       |
                          +--------------------+
                          | A.CRL      <hash>  |
                          | A.TAK      <hash>  |
                          +--------------------+

                          +--------------------+
                          |        A.CRL       |
                          +--------------------+
                          | revocations..      |
                          +--------------------+

                          +--------------------+
                          |        A.TAK       |
                          +--------------------+
                          | current: B, C      |
                          | revoked: A         |
                          +--------------------+

   The resulting structures for keys 'B' and 'C' will be as follows:

           +--------------------+         +--------------------+
           |        B.MFT       |         |        C.MFT       |
           +--------------------+         +--------------------+
           | B.CRL      <hash>  |         | B.CRL      <hash>  |
           | B.TAK      <hash>  |         | B.TAK      <hash>  |
           | C1-B.CER   <hash>  |         | C1-C.CER   <hash>  |
           | C2-B.CER   <hash>  |         | C2-C.CER   <hash>  |
           +--------------------+         +--------------------+

           +--------------------+         +--------------------+
           |        B.CRL       |         |        C.CRL       |
           +--------------------+         +--------------------+
           | revocations..      |         | revocations..      |
           +--------------------+         +--------------------+

           +--------------------+         +--------------------+
           |        B.TAK       |         |        C.TAK       |
           +--------------------+         +--------------------+
           | current: B, C      |         | current: B, C      |
           | revoked: A         |         | revoked: <none>    |
           +--------------------+         +--------------------+

           +--------------------+         +--------------------+
           |      C1-B.CER      |         |      C1-C.CER      |
           +--------------------+         +--------------------+
           | resources: C1 res  |         | resources: C1 res  |
           | subject:   C1 name |         | subject:   C1 name |
           | pub key:   C1 key  |         | pub key:   C1 key  |
           | SIA:       C1 SIAs |         | SIA:       C1 SIAs |
           | AKI:       B       |         | AKI:       C       |
           +--------------------+         +--------------------+

           +--------------------+         +--------------------+
           |      C2-B.CER      |         |      C2-B.CER      |
           +--------------------+         +--------------------+
           | resources: C2 res  |         | resources: C2 res  |
           | subject:   C2 name |         | subject:   C2 name |
           | pub key:   C2 key  |         | pub key:   C2 key  |
           | SIA:       C2 SIAs |         | SIA:       C2 SIAs |
           | AKI:       B       |         | AKI:       B       |
           +--------------------+         +--------------------+

   In addition to this the TA SHOULD reach out to RP vendors so that
   they can update the new CA certificate

   The Trust Anchor MUST generate a new (unsigned) TAL file
   [I-D.ietf-sidrops-https-tal] and verify with included in the RP software that distribution to
   use key 'B'.

6.3.2.  Relying Parties

   Relying Parties who have a TAL for key 'A' configured will discover
   the new
   Trust Anchor certificate can be retrieved from all locations and that
   it matches TAK object.  If the subjectPublicKeyInfo

6.4.  Publish RP does not support this object, it will
   reject this object but continue to validate the remaining RPKI tree
   as usual.  In this case that means that validation will stop, because
   there are no more objects under the current key under 'A'.  Therefore it is important
   that RPs that do not support TAK files are updated to use the new TAL for
   key

   ALL current signed certificates and 'B' through some other objects, with the exception
   of the CRL, Manifest and existing Signed TAL, must be re-issued by
   the new key and published under process.

   If the new publication point(s).

   It is RECOMMENDED that RP uses a new Signed TAL object is generated and
   published, listing the Certificate URIs for this new key, the
   subjectPublicKeyInfo of this new key, key 'A' and using an "activationTime"
   that is effective immediately.  Note that Relying Parties it supports TAK objects, it will not
   discover this new Signed that the TAL object until they have effectively
   switched over from for key 'A' has keys 'B' and 'C' as current,
   and revokes itself.  It will then proceed to process keys 'B' and 'C'
   and find TALs which list the same current key.

6.5.  Verify that the validity keys.  So, it will now
   replace its notion of objects under the new current key

   The Trust Anchor MUST verify set for this TA based on its
   TAL (key 'A') with what it learned.  To keep things simple the RP
   will now conclude that it should re-start validation using the new TAL file
   generated in Section 6.3 results a
   remaining current key, in this case key either 'B' or 'C' may be
   used.

   If the RP already had a TAL for key 'B' and it supports TAK objects,
   or it simply started with key 'B' because it added it to its set of valid objects as when
   the
   current TAL file keys when this key was pre-staged (see Section 6.2), it will
   learn that key 'A' is used.

6.6.  Publish a Signed TAL as the only object under revoked and therefore will not attempt to
   verify the current TAK file for key

   The Trust Anchor MUST publish a new Signed 'A'.  It will also learn about key 'C'
   and inspect this key's TAL, CRL and Manifest as
   the discover that only objects under the current, to be deleted, key.  The
   "nextUpdate" values of the Manifest keys 'B' and CRL objects SHOULD use 'C'
   are considered current.  Since it started the validation process with
   a date key that is set at least one year into the future. (arbitrary value, open still current, it can proceed to suggestions).  The "notValidAfter" date on validate the Manifest and Signed
   TAL EE certificate SHOULD use this same date.  The RPKI tree
   using the repository under key 'B'.

6.4.  Unplanned revocation

6.4.1.  Trust Anchor MUST
   ensure that this Signed TAL, CRL

   Now keys 'B' and Manifest remain available for
   download for this full period.  Note that this is done 'C' are current.  The TA may have intended to give RPs
   the opportunity revoke
   key 'B', essentially rolling over to discover the key 'C' and a new key up to one year after 'D', but
   let us suppose that the TA lost access to key
   roll occurred.

6.7.  Delete 'C'.  In this case the current
   TA will simply revoke key

   As the final step the current key, which has been replaced now,
   SHOULD be deleted.  The 'C' instead, and still introduce a new key can
   'D'.

   The major difference with the process described above for planned
   rolls, is that now the TA will not be marked as able to update the TAK object,
   MFT or CRL for key 'C'.  However, because all TAL objects for current key.

7.  Relying Party Use

   When
   keys are evaluated before tree validation is performed, it is safe to
   leave these objects in a repository.  Keys 'B' and 'D' will simply
   mark key 'C' as being revoked.

   If an RP discovers still has a valid Signed TAL signed under a TA, and pointing at key 'C' it
   notices will discover that the "subjectPublicKeyInfo" has changed and/or the set of
   "Certificate URIs"
   key 'D' is added, and that key 'B' has changed from been revoked through the values it knew TAK
   object published for this TA, keys 'B' and 'D'.  At least, as long as the "activationTime" is in the past, then the RP MUST accept
   these new values for this TA, abort
   MFT and TAK EE certificates have not expired, and the current top-down validation
   operation, CRL and initiate a new top-down validation operation using MFT are
   not stale.

   If the
   updated information.

   Note TA is absolutely sure that the Trust Anchor MUST have verified that all objects are
   available under TAL for key 'C' never shipped
   with any RP distribution, then it would also be safe to delete the new
   repository key (Section 6.5) and that 'C' altogether.  RPs will learn that 'C' is revoked,
   and therefore will not even attempt to download the TA CA
   certificate can TAK object.
   However, it is hard to be retrieved certain of this and validated for all new URIs
   (Section 6.3).

8. there this is NOT
   RECOMMENDED.

7.  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 invalidation of any other
   object under a Trust Anchor.

   That said, the flagging mechanism introduced here can only be trusted relied
   on once a majority of RPs support it.  Defining when that moment
   arrives is by definition something that cannot be established at 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 most assured way to know that such planned rolls will work is by
   making them a part of 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 power to revoke the current key.  This would have to
   be signalled from the new key, as the TA may have lost access to its
   current key.

   However, this introduces a great amount of operational complexity as
   well as a 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 now, that unplanned key rolls
   should not be covered here, and would need to that cannot be communicated to
   Relying Parties in some other out-of-band fashion.

10.  Changing a Trust Anchor Certificate URIs

   Earlier versions established at the
   time of writing this document included a description of how
   Signed document.  Until such time, TAs SHOULD continue
   to generate unsigned TAL objects could files [I-D.ietf-sidrops-https-tal], and
   indicate which should be used considered their current TAL, and
   communicate them to signal RPs through other means.

   However, once a change majority of Certificate
   URIs only; i.e. where the key is not changed.

   However, Relying Parties that do not RPs support the mechanism described
   in this document mechanism it would not be able
   RECOMMENDED that Trust Anchor operators perform key rolls regularly.
   The most assured way to learn about the changes in
   URIs.  While for RPs know that do support this mechanism a planned such key
   roll rolls will be work is by
   making them a normal part of RPKI validation.

   Therefore we believe that a planned key roll should be used in cases
   like this, and that the set normal operations.  Determining when this
   moment arrives is by definition out of Certificate URIs scope for any given key
   must never this document, as it
   should be changed.

11. based on operational experience.

8.  IANA Considerations

11.1.

8.1.  OID

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

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

11.2.

8.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              | References
          -----------+-------------------------------------------
           .tal
           .tak      |   Signed TAL   Trust Anchor Keys        | [this document]

12.

9.  Security Considerations

   TBD

13.

10.  Acknowledgements

   TBD

14.

   The authors wish to thank Martin Hoffmann for a thourough review of
   this document.

11.  References

14.1.

11.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 draft-ietf-sidrops-https-tal-05
              (work in progress), June October 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>.

   [RFC5011]  StJohns, M., "Automated Updates of DNS Security (DNSSEC)
              Trust Anchors", STD 74, RFC 5011, DOI 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>.

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

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

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

   [RFC7230]  Fielding, R., Ed. and 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 Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8181]  Weiler, S., Sonalker, A., and R. Austein, "A Publication
              Protocol for the Resource Public Key Infrastructure
              (RPKI)", RFC 8181, DOI 10.17487/RFC8181, July 2017,
              <https://www.rfc-editor.org/info/rfc8181>.

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

14.2.

11.2.  Informative References

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

Authors' Addresses

   Tim Bruijnzeels
   NLnet Labs

   Email: tim@nlnetlabs.nl
   URI:   https://www.nlnetlabs.nl/

   Carlos Martinez
   LACNIC

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

   Rob Austein
   Dragon Research Labs

   Email: sra@hactrn.net