Date: Thu, 16 May 2024 14:00:29 +1000
From: Tom Harrison <tomh@apnic.net>
To: John Scudder <jgs@juniper.net>
Message-ID: <ZkWE3Vt9NIX5OQ5O@TomH-498551.lan>
Mail-Followup-To: John Scudder <jgs@juniper.net>, The IESG <iesg@ietf.org>,
	draft-ietf-sidrops-signed-tal@ietf.org, sidrops-chairs@ietf.org,
	sidrops@ietf.org, keyur@arrcus.com, housley@vigilsec.com
References: <171579652168.58708.10062785636959401163@ietfa.amsl.com>
Content-Type: multipart/mixed; boundary="rQbEyiJe6XyvY2Db"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <171579652168.58708.10062785636959401163@ietfa.amsl.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?utf-8?B?NTl5K25KelpMUUNPRjR0bmZQeUtxNzgwY0I2akF0OGoxM0JOamk2blF5cVpX?=
 =?utf-8?B?Y0hNLzFTMzFLbkIrZGxCby9FMnJRcHE4RGFoL2NMdytkcEpIZ2xXdDk1d09I?=
 =?utf-8?B?V242VlI4Q0pTcTN2UUYwcXZwekFwMXc0aHVJZnB2U2lwMlMxZTVudHNpY0FJ?=
 =?utf-8?B?UGxoZ2k2cWdsVmRjQTZiUlFHUDFTZXJiT3pQWUUrZFpOTVpYYm9qYzVEc1RW?=
 =?utf-8?B?YjhRZ0dpNHJCMkJZMklrZGlCTCtWRHdSYmxVZjVIamxpMzNzK3J1a3B5QVAx?=
 =?utf-8?B?NkMyOTdJdEVMdnRkWWYxb1hIRG9obnZBeTJtQUlSWm1TUHdUNXJpdDVQRlZ1?=
 =?utf-8?B?a2ZydjlSWGx2QjVTRW84ZjNtankxbFJhVm1XSGo4NTAvUHdSeXlZNTc4d2pI?=
 =?utf-8?B?M3JXQUxtNnNrUmF6alhCSnVRbmRCRVJ0Sjc4TDVkMXR4NEtLdzFSdUxjSnV4?=
 =?utf-8?B?UWFnbGZFOFlveFk4dTNpMXNQVG1Uak1ZV2pyZVN1aytaeXVXVU94NERubEg4?=
 =?utf-8?B?RVNQeFlrZ2h4Rk5nekRQVG43Q24vdEZDTUdRaURmRGR6ME8yZEFuM0M1RTFt?=
 =?utf-8?B?WnkyeVBCVVplSC8wUHpkMElsTXZJd1dkRkZaMzB2Z2VBU2lVSmI4V3BYTm9v?=
 =?utf-8?B?ejk5V0FHUnczTFRIUXd3K0RUMktYOER0T0lwOHliSVo1T1lMMEZxYVNuUE44?=
 =?utf-8?B?bm1ueHg3Y2xjaXJnVHpUMmlXOXJjc1JKM2JSSFZEUys1ZGJPOVdBcXYwUEUw?=
 =?utf-8?B?RlVrellRYml0OWU4RlB1S3hnUFJ2cWloSEM0UzJrVE93ZGRkazEyTzJZUVdu?=
 =?utf-8?B?UlJXN1VZNEc3ajlJWVFuZ0luRG9qbml1N3pRK3FkQXNERlNodUY0QWFFSXZj?=
 =?utf-8?B?cHRsdGZNazg3YW8xSUpoYndVVEdOQlpESmRKN3RkemFjMDgxdTZoaDl6NWxE?=
 =?utf-8?B?Zm92czRObU1NUzI2bkpuUkxpeENBMERQN3kvb0VZQzhENTNoMmtyNnU0dmd4?=
 =?utf-8?B?SFF4V0dhNkRtRDdIMThEWVhSdG9WNnNheGJadXJzYkNkYzA2VHlBY2NBZGR2?=
 =?utf-8?B?cmJSVXUxZTFxRWEyN2ZkQllRRmw0Rk82T3h5REJORHorRUNCUGxOalRrT1hx?=
 =?utf-8?B?RFNuSUU5WnVaZzdBVi90LzZ0d2NySXhOOWV6L2IyRXkxM3VWZC9nNnV2RGJU?=
 =?utf-8?B?UCt0SStjMzF6NUVCNVMrWXhMaG9DaURnUEJQZSticzA0cXA2OFpsSk1tREsw?=
 =?utf-8?B?bUhFdUNIazBrQVVBT1VFTkRVejZRZDcyR0l6VTRYR0pjOXg4QUVnOFAyUXRq?=
 =?utf-8?B?T1F3UGYwMmtsUmtoMGpMdDZaV0VTZkJtbDdKbnBiN1VCSUNSVDFIUkFnV3lO?=
 =?utf-8?B?aHA0Y0VYZ0pRN2VuK2NjUHVtb0x1Y1hTN2VNK1MxSHBpeWFpUmszYXFJdGdU?=
 =?utf-8?B?TkFJeFRxK3A4RTJVTkovOXZBUUpDbWlwQXBwNjRiZ3NqK0laODJycTF3ZDhl?=
 =?utf-8?B?TlhzVHZsQlkxUDRVcEhQRmlJbm9RdllBb21VZERxcVVOVDhaNHI1V29sUTdB?=
 =?utf-8?B?dWF0Yi9KWXR6MlRUOWtJc1BzU25reHhhcFpsNGV5bUhNc3l5MzdKdUJydGJl?=
 =?utf-8?B?T3JDQ3B2NEhoc0JjTnQxR1JLL01yTlZhdFFuUkxmL3ZZK3RjOGJYUTB4dUZY?=
 =?utf-8?B?dHFrc1JFdy9yVFNVTFE2aStjRnZNc2lsUjNML1c2WXRsRjJ3NUVJVGVGZE5U?=
 =?utf-8?B?QmR1NFdVRjJma2NVUmRWZjJMcEg4ajZpbWJCR0dtaGFrTHZGMzY5WFlrRGN2?=
 =?utf-8?B?OFovd0VCTHFZa09ZR3JLc1VUZGNlV09NcnpqcURuemRycCs3YVhpMGE0RjFx?=
 =?utf-8?B?cWpZNmRwekl1UUdSQjM4dHZ0dTkwbGh5T0RXT3VpMmtibTZ0eHk0OXkyZmZQ?=
 =?utf-8?B?Y1hSRDBTalZXdE5hRlgycS9WcWFBZW50bjJGVENueU93VFJzSHBwQjVJU1ND?=
 =?utf-8?B?aHBPcWp1OGZlYlZDK0FoZFQ2YkFhTGFJbVh6Wkhmd1Y4TVF2VmVBWThyQ2hO?=
 =?utf-8?B?ditXNm9VVWplUWlzamZ1THVRU3g1UXFmV2theXhYWWtHUkNCRWszdGtWbmpS?=
 =?utf-8?B?M1AwaERkWjFCT21jSk9ubnFNNzZVM1dlOUtOZUQ2SCtVb2RqeUQvWi9lbkoy?=
 =?utf-8?Q?N/59A1Ln4CYASdDKefrdNVz5ozcc4DI16ojnwgetUCCA?=
X-OriginatorOrg: apnic.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 
 0042dea0-650a-42ad-aa5d-08dc755cb983
X-MS-Exchange-CrossTenant-AuthSource: SY7P282MB4761.AUSP282.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 May 2024 04:00:29.6776
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 127d8d0d-7ccf-473d-ab09-6e44ad752ded
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 
 Um3ZoefhtofboQDjcfEUgrjjOkdxjZhWOcSEQ5kmE4KBdCU5o/nRUQByRozlkwAV
X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME0P282MB4833
Message-ID-Hash: JFBSUF3LBTNFAEITILWAIIQML62YT74M
X-Message-ID-Hash: JFBSUF3LBTNFAEITILWAIIQML62YT74M
X-MailFrom: tomh@apnic.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency;
 loop; banned-address; member-moderation; header-match-sidrops.ietf.org-0;
 nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size;
 news-moderation; no-subject; digests; suspicious-header
CC: The IESG <iesg@ietf.org>, draft-ietf-sidrops-signed-tal@ietf.org,
 sidrops-chairs@ietf.org, sidrops@ietf.org, keyur@arrcus.com,
 housley@vigilsec.com
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: =?utf-8?q?=5BSidrops=5D_Re=3A_John_Scudder=27s_No_Objection_on_draft-ietf-si?=
 =?utf-8?q?drops-signed-tal-15=3A_=28with_COMMENT=29?=
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/sidrops/dJWZhfGvR98kxjb0tooLW93O18s>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Owner: <mailto:sidrops-owner@ietf.org>
List-Post: <mailto:sidrops@ietf.org>
List-Subscribe: <mailto:sidrops-join@ietf.org>
List-Unsubscribe: <mailto:sidrops-leave@ietf.org>

--rQbEyiJe6XyvY2Db
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit

Hi John,

Thanks for your review.

On Wed, May 15, 2024 at 11:08:41AM -0700, John Scudder via Datatracker wrote:
> ### Section 3.2.1.1, octothorpe, equivalence
> 
>    This field is equivalent to the comment section defined in section
>    2.2 of [RFC8630].  Each comment is human-readable informational UTF-8
>    text [RFC3629], conforming to the restrictions defined in Section 2
>    of [RFC5198].  The leading "#" character is omitted.
> 
> What does the final sentence, about the omission of the octothorpe
> character, mean? Do you mean that the comment section varies from
> the referenced definition in RFC 8630, in that the octothorpe is not
> required? Do you mean something different? Maybe rephrase this to
> make it less ambiguous.

The current state of the document after the other IESG reviews has the
following:

   *  comments: This field is equivalent to the comment section defined
      in section 2.2 of [RFC8630].  Each comment is human-readable
      informational UTF-8 text [RFC3629], conforming to the restrictions
      defined in Section 2 of [RFC5198].  The leading "#" character that
      is used to denote a comment in [RFC8630] is omitted here.

Does that help to clarify the meaning?

> Also, when you write “is equivalent to”, do you mean semantically
> equivalent?  Do you mean syntactically identical?  The same question
> applies to section 3.2.1.2.

I think in both cases it's both syntactically and semantically
equivalent, putting aside the translation from plain text to ASN.1,
but since the syntax is defined here anyway, both instances have been
updated from 'equivalent' to 'semantically equivalent'.

> ### Section 3.2.2.4. successor
> 
>    This field contains the TA key to be used in place of the current
>    key, after expiry of the relevant acceptance timer.
> 
> Shouldn’t this be “if applicable“, as in 3.2.2.3? Section 7.2
> implies it's optional, “It also issues a TAK object under key 'B',
> with key 'B' as the current key for that object, key 'A' as the
> predecessor key, **and no successor key**.” (emphasis added) What's
> more, it’s marked “optional” in the ASN.1.

Yep, that's right.  The relevant text here has been updated like so:

    successor: This field contains the TA public key to be used in
    place of the current public key, if applicable, after expiry of
    the relevant acceptance timer.
 
> ### Section 6
> 
> This section includes language such as “... ensure that they will
> reflect the same content at all times.” The clause “at all times”
> appears to offer a strong consistency guarantee, forbidding even
> vanishingly short windows of inconsistency during the staging of new
> content. Is it the authors' intent that even low-probability race
> conditions should be precluded? Is it the case that existing
> implementations already take whatever steps are necessary to prevent
> these?
> 
> (In light of the “multiple publication servers“ paragraph, I suspect
> the answer is "no".)

Yep, you are right.  The text has been updated like so:

    If a TA uses a single remote publication server for its key pairs,
    per [RFC8181], then it MUST include all <publish/> and <withdraw/>
    Protocol Data Units (PDUs) for the products of each of its key
    pairs in a single query, in order to reduce the risk of RPs seeing
    inconsistent data in the TA's RPKI repositories.

An updated version of the document is attached for reference (includes
updates from secdir review and other IESG review), along with a diff
from the previous version (-15).

-Tom

--rQbEyiJe6XyvY2Db
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
	filename="draft-ietf-sidrops-signed-tal-16.txt"





Network Working Group                                        C. Martinez
Internet-Draft                                                    LACNIC
Intended status: Standards Track                           G. Michaelson
Expires: 17 November 2024                                    T. Harrison
                                                                   APNIC
                                                          T. Bruijnzeels
                                                                RIPE NCC
                                                              R. Austein
                                                    Dragon Research Labs
                                                             16 May 2024


                RPKI Signed Object for Trust Anchor Key
                    draft-ietf-sidrops-signed-tal-16

Abstract

   A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the
   Resource Public Key Infrastructure (RPKI) to locate and validate a
   Trust Anchor (TA) Certification Authority (CA) certificate used in
   RPKI validation.  This document defines an RPKI signed object for a
   Trust Anchor Key (TAK), that can be used by a TA to signal the
   location(s) of the accompanying CA certificate for the current public
   key to RPs, as well as the successor public key and the location(s)
   of its CA certificate.  This object helps to support planned key
   rollovers 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 17 November 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Martinez, et al.        Expires 17 November 2024                [Page 1]

Internet-Draft         RPKI signed object for TAL               May 2024


   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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   3
   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  TAK Object Definition . . . . . . . . . . . . . . . . . . . .   4
     3.1.  The TAK Object Content Type . . . . . . . . . . . . . . .   4
     3.2.  The TAK Object eContent . . . . . . . . . . . . . . . . .   4
       3.2.1.  TAKey . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.2.  TAK . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  TAK Object Validation . . . . . . . . . . . . . . . . . .   5
   4.  TAK Object Generation and Publication . . . . . . . . . . . .   6
   5.  Relying Party Use . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Manual update of TA public key details  . . . . . . . . .   9
   6.  Maintaining Multiple TA Key Pairs . . . . . . . . . . . . . .   9
   7.  Performing TA Key Rolls . . . . . . . . . . . . . . . . . . .  11
     7.1.  Phase 1: Add a TAK for Key Pair 'A' . . . . . . . . . . .  11
     7.2.  Phase 2: Add a Key Pair 'B' . . . . . . . . . . . . . . .  11
     7.3.  Phase 3: Update TAL to point to 'B' . . . . . . . . . . .  11
     7.4.  Phase 4: Remove Key Pair 'A'  . . . . . . . . . . . . . .  12
   8.  Using TAK objects to distribute TAL data  . . . . . . . . . .  12
   9.  Deployment Considerations . . . . . . . . . . . . . . . . . .  13
     9.1.  Relying Party Support . . . . . . . . . . . . . . . . . .  13
     9.2.  Alternate Transition Models . . . . . . . . . . . . . . .  13
   10. Operational Considerations  . . . . . . . . . . . . . . . . .  14
     10.1.  Acceptance Timers  . . . . . . . . . . . . . . . . . . .  14
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  14
     11.1.  Previous Keys  . . . . . . . . . . . . . . . . . . . . .  14
     11.2.  TA Compromise  . . . . . . . . . . . . . . . . . . . . .  15
     11.3.  Alternate Transition Models  . . . . . . . . . . . . . .  15
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
     12.1.  Content Type . . . . . . . . . . . . . . . . . . . . . .  16
     12.2.  Signed Object  . . . . . . . . . . . . . . . . . . . . .  16
     12.3.  File Extension . . . . . . . . . . . . . . . . . . . . .  16
     12.4.  Module Identifier  . . . . . . . . . . . . . . . . . . .  16
     12.5.  Registration of Media Type application/
            rpki-signed-tal  . . . . . . . . . . . . . . . . . . . .  17
   13. Implementation Status . . . . . . . . . . . . . . . . . . . .  18
     13.1.  APNIC  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     13.2.  rpki-client  . . . . . . . . . . . . . . . . . . . . . .  19



Martinez, et al.        Expires 17 November 2024                [Page 2]

Internet-Draft         RPKI signed object for TAL               May 2024


     13.3.  rpki-rs  . . . . . . . . . . . . . . . . . . . . . . . .  19
   14. Revision History  . . . . . . . . . . . . . . . . . . . . . .  19
   15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  20
   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20
     16.1.  Normative References . . . . . . . . . . . . . . . . . .  20
     16.2.  Informative References . . . . . . . . . . . . . . . . .  22
   Appendix A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23

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.  Overview

   A Trust Anchor Locator (TAL) [RFC8630] is used by Relying Parties
   (RPs) in the Resource Public Key Infrastructure (RPKI) to locate and
   validate Trust Anchor (TA) Certification Authority (CA) certificates
   used in RPKI validation.  However, until now, there has been no in-
   band way of notifying RPs of updates to a TAL.  In-band notification
   means that TA operators can be more confident of RPs being aware of
   key rollover operations.

   This document defines a new RPKI signed object that can be used to
   document the location(s) of the TA CA certificate for the current TA
   public key, as well as the value of the successor public key and the
   location(s) of its TA CA certificate.  This allows RPs to be notified
   automatically of such changes, and enables TAs to stage a successor
   public key so that planned key rollovers can be performed without
   risking the invalidation of the RPKI tree under the TA.  We call this
   object the Trust Anchor Key (TAK) object.

   When RPs are first bootstrapped, they use a TAL to discover the
   public key and location(s) of the CA certificate for a TA.  The RP
   can then retrieve and validate the CA certificate, and subsequently
   validate the manifest [RFC9286] and Certificate Revocation List (CRL)
   published by that TA (section 5 of [RFC6487]).  However, before
   processing any other objects, it will first validate the TAK object,
   if present.  If the TAK object lists only the current public key,
   then the RP continues processing as it would in the absence of a TAK
   object.  If the TAK object includes a successor public key, the RP
   starts a 30-day acceptance timer for that key, and then continues
   standard top-down validation with the current public key.  If, during
   the following validation runs up until the expiry of the acceptance



Martinez, et al.        Expires 17 November 2024                [Page 3]

Internet-Draft         RPKI signed object for TAL               May 2024


   timer, the RP has not observed any changes to the public keys and
   certificate URLs listed in the TAK object, then the RP will fetch the
   successor public key, update its local state with that public key and
   its associated certification location(s), and continue processing
   using that public key.

   The primary motivation for this work is being able to migrate from a
   Hardware Security Module (HSM) produced by one vendor to one produced
   by another, where the first vendor does not support exporting private
   keys for use by the second.  There may be other scenarios in which
   key rollover is useful, though.

3.  TAK Object Definition

   The TAK object makes use of the template for RPKI digitally signed
   objects [RFC6488], which defines a Cryptographic Message Syntax (CMS)
   [RFC5652] wrapper for the content as well as a generic validation
   procedure for RPKI signed objects.  Therefore, to complete the
   specification of the TAK object (see Section 4 of [RFC6488]), this
   document defines:

   *  The OID (in Section 3.1) that identifies the signed object as
      being a TAK.  (This OID appears within the eContentType in the
      encapContentInfo object, as well as the content-type signed
      attribute in the signerInfo object.)

   *  The ASN.1 syntax for the TAK eContent, in Section 3.2.

   *  The additional steps required to validate a TAK, in Section 3.3.

3.1.  The TAK Object Content Type

   This document specifies an OID for the TAK object as follows:

      id-ct-signedTAL OBJECT IDENTIFIER ::=
         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
           smime(16) ct(1) 50 }

   This OID MUST appear in both the eContentType in the encapContentInfo
   object and the content-type signed attribute in the signerInfo object
   (see [RFC6488]).

3.2.  The TAK Object eContent

   The content of a TAK object is ASN.1 encoded using the Distinguished
   Encoding Rules (DER) [X.690], and is defined per the module in
   Appendix A.




Martinez, et al.        Expires 17 November 2024                [Page 4]

Internet-Draft         RPKI signed object for TAL               May 2024


3.2.1.  TAKey

   This structure defines a TA public key, similar to that from
   [RFC8630].  It contains a sequence of zero or more comments, one or
   more certificate URIs, and a SubjectPublicKeyInfo.

   *  comments: This field is semantically equivalent to the comment
      section defined in section 2.2 of [RFC8630].  Each comment is
      human-readable informational UTF-8 text [RFC3629], conforming to
      the restrictions defined in Section 2 of [RFC5198].  The leading
      "#" character that is used to denote a comment in [RFC8630] is
      omitted here.

   *  certificateURIs: This field is semantically equivalent to the URI
      section defined in section 2.2 of [RFC8630].  It MUST contain at
      least one CertificateURI element.  Each CertificateURI element
      contains the IA5String representation of either an rsync URI
      [RFC5781], or an HTTPS URI [RFC9110].

   *  subjectPublicKeyInfo: This field contains a SubjectPublicKeyInfo
      (section 4.1.2.7 of [RFC5280]) in DER format [X.690].

3.2.2.  TAK

   *  version: The version number of the TAK object MUST be 0.

   *  current: This field contains the TA public key of the repository
      in which the TAK object is published.

   *  predecessor: This field contains the TA public key that was in use
      for this TA immediately prior to the current TA public key, if
      applicable.

   *  successor: This field contains the TA public key to be used in
      place of the current public key, if applicable, after expiry of
      the relevant acceptance timer.

3.3.  TAK Object Validation

   To determine whether a TAK object is valid, the RP MUST perform the
   following checks in addition to those specified in [RFC6488]:

   *  The eContentType OID matches the OID described in Section 3.1.

   *  The TAK object appears as the product of a TA CA certificate (i.e.
      the TA CA certificate is itself the issuer of the End-Entity (EE)
      certificate of the TAK object).




Martinez, et al.        Expires 17 November 2024                [Page 5]

Internet-Draft         RPKI signed object for TAL               May 2024


   *  The TA CA has published only one TAK object in its repository for
      this public key, and this object appears on the manifest as the
      only entry using the ".tak" extension (see [RFC6481]).

   *  The EE certificate of this TAK object describes its Internet
      Number Resources (INRs) using the "inherit" attribute.

   *  The decoded TAK content conforms to the format defined in
      Section 3.2.

   *  The SubjectPublicKeyInfo value of the current TA public key in the
      TAK object matches that of the TA CA certificate used to issue the
      EE certificate of the TAK object.

   If any of these checks does not succeed, the RP MUST ignore the TAK
   object and proceed as though it were not listed on the manifest.

   The RP is not required to compare its current set of certificateURIs
   for the current public key with those listed in the TAK object.  The
   RP MAY alert the user that these sets of certificateURIs do not
   match, with a view to the user manually updating the set of
   certificateURIs in their configuration.  The RP MUST NOT
   automatically update its configuration to use these certificateURIs
   in the event of inconsistency, though, because the migration of users
   to new certificateURIs should happen by way of the successor public
   key process.

4.  TAK Object Generation and Publication

   A non-normative guideline for naming this object is that the filename
   chosen for the TAK 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.

   In order to generate a TAK object, the TA MUST perform the following
   actions:

   *  The TA MUST generate a one-time-use EE certificate for the TAK.

   *  This EE certificate MUST have a unique key pair.

   *  This EE certificate MUST have a Subject Information Access (SIA)
      [RFC6487] 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.



Martinez, et al.        Expires 17 November 2024                [Page 6]

Internet-Draft         RPKI signed object for TAL               May 2024


   *  As described in [RFC6487], the EE certificate used for this object
      must include an [RFC3779] extension.  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 explicitly describing a resource
      set.

   *  This EE certificate MUST have a "notBefore" time that matches or
      predates the moment that the TAK will be published.

   *  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 TAK object 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.

   *  The current TA public key for the TAK MUST match that of the TA CA
      certificate under which the TAK was issued.

   In distribution contexts that support media types, the "application/
   rpki-signed-tal" media type can be used for TAK objects.

5.  Relying Party Use

   Relying Parties MUST keep a record of the current public key for each
   configured TA, as well as the URI(s) where the CA certificate for
   this public key may be retrieved.  This record is typically
   bootstrapped by the use of a pre-configured (and unsigned) TAL file
   [RFC8630].

   When performing top-down validation, RPs MUST first validate and
   process the TAK object for its current known public key, by
   performing the following steps:

   *  A CA certificate is retrieved and validated from the known URIs as
      described in sections 3 and 4 of [RFC8630].

   *  The manifest and CRL for this certificate are then validated as
      described in [RFC6487] and [RFC9286].

   *  The TAK object, if present, is validated as described in
      Section 3.3.

   If the TAK object includes a successor public key, then the RP must
   verify the successor public key by doing the following:

   *  performing top-down validation using the successor public key, in
      order to validate the TAK object for the successor TA;



Martinez, et al.        Expires 17 November 2024                [Page 7]

Internet-Draft         RPKI signed object for TAL               May 2024


   *  ensuring that a valid TAK object exists for the successor TA;

   *  ensuring that the successor TAK object's current public key
      matches the initial TAK object's successor public key; and

   *  ensuring that the successor TAK object's predecessor public key
      matches the initial TAK object's current public key.

   If any of these steps fails, then the successor public key has failed
   verification.

   If the successor public key passes verification, and the RP has not
   seen that successor public key on the previous successful validation
   run for this TA, then the RP:

   *  sets an acceptance timer of 30 days for this successor public key
      for this TA;

   *  cancels the existing acceptance timer for this TA (if applicable);
      and

   *  continues standard top-down validation as described in [RFC6487]
      using the current public key.

   If the successor public key passes verification, and the RP has seen
   that successor public key on the previous successful validation run
   for this TA:

   *  if the relevant acceptance timer has not expired, the RP continues
      standard top-down validation using the current public key;

   *  otherwise, the RP updates its current known public key details for
      this TA to be those of the successor public key, and then begins
      top-down validation again using the successor public key.

   If the successor public key does not pass verification, or if the TAK
   object does not include a successor public key, the RP cancels the
   existing acceptance timer for this TA (if applicable).

   An RP MUST NOT use a successor public key for top-down validation
   outside of the process described above, except for the purpose of
   testing that the new public key is working correctly.  This allows a
   TA to publish a successor public key for a period of time, allowing
   RPs to test it, while still being able to rely on RPs using the
   current public key for their production RPKI operations.






Martinez, et al.        Expires 17 November 2024                [Page 8]

Internet-Draft         RPKI signed object for TAL               May 2024


   A successor public key may have the same SubjectPublicKeyInfo value
   as the current public key: this will be the case where a TA is
   updating the certificateURIs for that public key.

5.1.  Manual update of TA public key details

   A Relying Party may opt not to support the automatic transition of TA
   public key data, as defined in the previous section.  An alternative
   approach is for the Relying Party to alert the user when a new
   successor public key is seen, and also when the relevant acceptance
   timer has expired.  The user can then manually transition to the new
   TA public key data.  This process ensures that the benefits of the
   acceptance timer period are still realised, as compared with TA
   public key update based on a TAL distributed out-of-band by a TA.

6.  Maintaining Multiple TA Key Pairs

   Although an RP that can process TAK objects will only ever use one
   public key for validation (either the current public key, or the
   successor public key, once the relevant acceptance timer has
   expired), an RP that cannot process TAK objects will continue to use
   the public key details per its TAL (or equivalent manual
   configuration) indefinitely.  As a result, even when a TA is using a
   TAK object in order to migrate clients to a new public key, the TA
   may have to maintain the previous key pair for a period of time
   alongside the new key pair in order to ensure continuity of service
   for older clients.

   For each TA key pair that a TA maintains, the signed material for
   these key pairs MUST be published under different directories in the
   context of the 'id-ad-caRepository' and 'id-ad-rpkiManifest' Subject
   Information Access descriptions contained on the CA certificates
   [RFC6487].  Publishing objects under the same directory is
   potentially confusing for RPs, and could lead to object invalidity in
   the event of file name collisions.

   Also, the CA certificates for each maintained key pair, and the
   content published for each key pair, MUST be equivalent (except for
   the TAK object).  In other words, for the purposes of RPKI
   validation, it MUST NOT make a difference which of the public keys is
   used as a starting point.










Martinez, et al.        Expires 17 November 2024                [Page 9]

Internet-Draft         RPKI signed object for TAL               May 2024


   This means that the IP and Autonomous System (AS) resources contained
   on all current CA certificates for the maintained TA key pairs MUST
   be the same.  Furthermore, for any delegation of IP and AS resources
   to a child, the TA MUST have an equivalent CA certificate published
   under each of its key pairs.  Any updates in delegations MUST be
   reflected under each of its key pairs.  A TA SHOULD NOT publish any
   other objects besides a CRL, a Manifest, a single TAK object, and any
   number of CA certificates for delegation to child CAs.

   If a TA uses a single remote publication server for its key pairs,
   per [RFC8181], then it MUST include all <publish/> and <withdraw/>
   Protocol Data Units (PDUs) for the products of each of its key pairs
   in a single query, in order to reduce the risk of RPs seeing
   inconsistent data in the TA's RPKI repositories.

   If a TA uses multiple publication servers, then the content for
   different key pairs will be out of sync at times.  The TA SHOULD
   ensure that the duration of these moments is limited to the shortest
   possible time.  Furthermore, the following should be observed:

   *  In cases where a CA certificate is revoked, or replaced by a
      certificate with a reduced set of resources, these changes will
      not take effect fully until all the relevant repository
      publication points have been updated.  Given that TA private key
      operations are normally performed infrequently, this is unlikely
      to be a problem: if the revocation or shrinking of an issued CA
      certificate is staged for days/weeks, then experiencing a delay of
      several minutes for the repository publication points to be
      updated is relatively insignificant.

   *  In cases where a CA certificate is replaced by a certificate with
      an extended set of resources, the TA MUST inform the receiving CA
      only after all of its repository publication points have been
      updated.  This ensures that the receiving CA will not issue any
      products that could be invalid if an RP uses a TA public key just
      before the CA certificate was due to be updated.

   Finally, note that the publication locations of CA certificates for
   delegations to child CAs under each key pair will be different, and
   therefore the Authority Information Access 'id-ad-caIssuers' values
   (section 4.8.7 of [RFC6487]) on certificates issued by the child CAs
   may not be as expected when performing top-down validation, depending
   on the TA public key that is used.  However, these values are not
   critical to top-down validation, so RPs performing such validation
   MUST NOT reject a certificate simply because this value is not as
   expected.





Martinez, et al.        Expires 17 November 2024               [Page 10]

Internet-Draft         RPKI signed object for TAL               May 2024


7.  Performing TA Key Rolls

   In this section we describe how present-day RPKI TAs that use only
   one key pair, and that do not use TAK objects, can use a TAK object
   to perform a planned key rollover.

7.1.  Phase 1: Add a TAK for Key Pair 'A'

   Before adding a successor public key, a TA may want to confirm that
   it can maintain a TAK object for its current key pair only.  We will
   refer to this key pair as key pair 'A' throughout this section.

7.2.  Phase 2: Add a Key Pair 'B'

   The TA can now generate a new key pair, called 'B'.  The private key
   of this key pair MUST now be used to create a new CA certificate for
   the associated public key, and to issue equivalent CA certificates
   for delegations to child CAs, as described in Section 6.

   At this point, the TA can also construct a new TAL file [RFC8630] for
   the public key of key pair 'B', and test locally that the validation
   outcome for the new public key is equivalent to that of the other
   current public key(s).

   When the TA is certain that the content for both public keys is
   equivalent, and wants to initiate the migration from 'A' to 'B', it
   issues a new TAK object under key pair 'A', with the public key from
   that key pair as the current public key for that object, the public
   key from key pair 'B' as the successor public key, and no predecessor
   public key.  It also issues a TAK object under key pair 'B', with the
   public key from that key pair as the current public key for that
   object, the public key from key pair 'A' as the predecessor public
   key, and no successor public key.

   Once this has happened, RP clients will start seeing the new public
   key and setting acceptance timers accordingly.

7.3.  Phase 3: Update TAL to point to 'B'

   At about the time that the TA expects clients to start setting the
   public key from key pair 'B' as the current public key, the TA must
   release a new TAL file for that public key.  It SHOULD use a
   different set of URIs in the TAL compared to the TAK file, so that
   the TA can learn the proportion of RPs that can successfully validate
   and use the updated TAK objects.






Martinez, et al.        Expires 17 November 2024               [Page 11]

Internet-Draft         RPKI signed object for TAL               May 2024


   To support RPs that do not take account of TAK objects, the TA should
   continue operating key pair 'A' for a period of time after the
   expected migration of clients to the public key from 'B'.  The length
   of that period of time is a local policy matter for that TA: it might
   operate the key pair until no clients are attempting to validate
   using the associated public key, for example.

7.4.  Phase 4: Remove Key Pair 'A'

   The TA SHOULD now remove all content from the repository used by key
   pair 'A', and destroy the private key for that key pair.  RPs
   attempting to rely on a TAL for the public key from key pair 'A' from
   this point will not be able to perform RPKI validation for the TA,
   and will have to update their local state manually, by way of a new
   TAL file.

8.  Using TAK objects to distribute TAL data

   Relying Parties must be configured with RPKI Trust Anchor data in
   order to function correctly.  This Trust Anchor data is typically
   distributed in the Trust Anchor Locator (TAL) format defined in RFC
   8630.  A TAK object can also serve as a format for distribution of
   this data, though, because the TAKey data stored in the TAK object
   contains the same data that would appear in a TAL for the associated
   Trust Anchor.

   Relying Parties may support conversion of TAK objects into TAL files.
   Relying Parties that support conversion MUST validate the TAK object
   using the process from section 3.3.  One exception to the standard
   validation process in this context is that a Relying Party MAY treat
   a TAK object as valid, even though it is associated with a Trust
   Anchor that the Relying Party is not currently configured to trust.
   If the Relying Party is relying on this exception when converting a
   given TAK object, the Relying Party MUST communicate that fact to the
   user.

   When converting a TAK object, a Relying Party MUST default to
   producing a TAL file based on the 'current' TAKey in the TAK object,
   though it MAY optionally support producing TAL files based on the
   'predecessor' and 'successor' TAKeys.

   When converting a TAK object, a Relying Party MUST include in the TAL
   file any comments from the corresponding TAKey.

   If TAK object validation fails, then the Relying Party MUST NOT
   produce a TAL file based on the TAK object.





Martinez, et al.        Expires 17 November 2024               [Page 12]

Internet-Draft         RPKI signed object for TAL               May 2024


   Users should be aware that TAK objects distributed out-of-band have
   similar security properties to TAL files (i.e. there is no
   authentication).  In particular, TAK objects that are not signed by
   TAs with which the Relying Party is currently configured should only
   be used if the source that distributes them is one the user trusts to
   distribute TAL files.

   If a Relying Party is not transitioning to new Trust Anchor data
   using the automatic process described in section 5 or the partially-
   manual process described in section 5.1, then the user will have to
   rely on an out-of-band mechanism for validating and updating the
   Trust Anchor data for the Relying Party.  Users in this situation
   should take similar care when updating a trust anchor using a TAK
   object file as when using a TAL file to update TA data.

9.  Deployment Considerations

9.1.  Relying Party Support

   Publishing TAK objects while RPs do not support this standard will
   result in those RPs rejecting these objects.  It is not expected that
   this will result in the invalidation of any other object under a
   Trust Anchor.

   Some RPs may purposefully not support this mechanism: for example,
   they may be implemented or configured such that they are unable to
   update local current public key data.  TA operators should take this
   into consideration when planning key rollover.  However, these RPs
   would ideally still notify their operators of planned key rollovers,
   so that the operator could update the relevant configuration
   manually.

9.2.  Alternate Transition Models

   Alternate models of TAL update exist and are complementary to this
   mechanism.  For example, TAs can liaise directly with RP software
   developers to include updated and reissued TAL files in new code
   releases, and use existing code update mechanisms in the RP community
   to distribute the changes.

   Additionally, these non-TA channels for distributing TAL data may
   themselves rely on monitoring for TAK objects and then updating the
   TAL data in their distributions or packages accordingly.  In this
   way, TAK objects may be useful even for RPs that don't implement in-
   band support for the protocol.






Martinez, et al.        Expires 17 November 2024               [Page 13]

Internet-Draft         RPKI signed object for TAL               May 2024


   Non-TA channels for distributing TAL data should ensure, so far as is
   possible, that their update mechanisms take account of any changes
   that a user has made to their local TA public key configuration.  For
   example, if a new public key is published for a TA, but the non-TA
   channel's mechanism is able to detect that a user had removed the
   TA's previous public key from their local TA public key configuration
   such that the user no longer relies on it, then the mechanism should
   not by default add the new public key to the user's TA public key
   configuration.

10.  Operational Considerations

10.1.  Acceptance Timers

   Acceptance timers are used in TAK objects in order to permit RPs to
   test that the new public key is working correctly.  This in turn
   means that the TA operator will be able to gain confidence in the
   correct functioning of the new public key before RPs are relying on
   that in their production RPKI operations.  If a successor public key
   is not working correctly, a TA may remove that public key from the
   current TAK object.

   A TA that removes a successor public key from a TAK object SHOULD NOT
   add the same successor public key back into the TAK object for that
   TA.  This is because there may be an RP that has fetched the TAK
   object while the successor public key was listed in it, and has
   started an acceptance timer accordingly, but has not fetched the TAK
   object during the period when the successor public key was not listed
   in it.  If the unchanged successor public key is added back into the
   TA, such an RP will transition to using the new TA public key more
   quickly than other RPs, which may, in turn, make debugging and
   similar more complicated.  A simple way of addressing this problem in
   a situation where the TA operator doesn't want to reissue the
   SubjectPublicKeyInfo content for the successor public key that was
   withdrawn is to update the URL set for the successor public key,
   since RPs must take that URL set into account for the purposes of
   initiating and cancelling acceptance timers.

11.  Security Considerations

11.1.  Previous Keys

   A TA needs to consider the length of time for which it will maintain
   previously-current key pairs and their associated repositories.  An
   RP that is seeded with old TAL data will run for 30 days using the
   previous public key before migrating to the next public key, due to
   the acceptance timer requirements, and this 30-day delay applies to
   each new key pair that has been issued since the old TAL data was



Martinez, et al.        Expires 17 November 2024               [Page 14]

Internet-Draft         RPKI signed object for TAL               May 2024


   initially published.  It may be better in these instances for the TA
   to send error responses when receiving requests for the old
   publication URLs, so that the RP reports an error to its operator and
   the operator seeds it with up-to-date TAL data immediately.

   Once a TA has decided not to maintain a previously-current key pair
   and its associated repository, the TA SHOULD destroy the associated
   private key.  The TA SHOULD also reuse the TA CA certificate URLs
   from the previous TAL data for the next TAL that it generates.  These
   measures will help to mitigate the risk of an adversary gaining
   access to the private key and its associated publication points in
   order to send invalid/incorrect data to RPs seeded with the TAL data
   for the corresponding public key.

11.2.  TA Compromise

   TAK objects do not offer protection against compromise of the current
   TA private key or the successor TA private key.  TA private key
   compromise in general is out of scope for this document.

   While it is possible for a malicious actor to use TAK objects to
   cause RPs to transition from the current TA public key to a successor
   TA public key, such action is predicated on the malicious actor
   having compromised the current TA private key in the first place, so
   TAK objects do not alter the security considerations relevant to this
   scenario.

11.3.  Alternate Transition Models

   Section 9.2 describes other ways in which a TA may transition from
   one key pair to another.  Transition by way of an in-band process
   reliant on TAK objects is not mandatory for TAs or RPs, though the
   fact that the TAK objects are verifiable by way of the currently-
   trusted TA public key is a benefit compared with existing out-of-band
   mechanisms for TA public key distribution.

   There will be a period of time where both the current public key and
   the successor public key are available for use, and RPs that are
   initialised at different points of the transition process, or from
   different out-of-band sources, may be using either the current public
   key or the successor public key.  TAs are required to ensure so far
   as is possible that for the purposes of RPKI validation, it makes no
   difference which public key is used.

12.  IANA Considerations






Martinez, et al.        Expires 17 November 2024               [Page 15]

Internet-Draft         RPKI signed object for TAL               May 2024


12.1.  Content Type

   IANA is asked to register an object identifier for one content type
   in the "SMI Security for S/MIME CMS Content Type
   (1.2.840.113549.1.9.16.1)" registry as follows:

          Decimal | Description                    | References
          --------+--------------------------------+---------------
          50      | id-ct-signedTAL                | [section 3.1]

   *  Description: id-ct-signedTAL

   *  OID: 1.2.840.113549.1.9.16.1.50

   *  Specification: [section 3.1]

12.2.  Signed Object

   IANA is asked to add the following to the "RPKI Signed Objects"
   registry:

        Name             | OID                        | Reference
        -----------------+----------------------------+---------------
        Trust Anchor Key | 1.2.840.113549.1.9.16.1.50 | [section 3.1]

   IANA is also asked to add the following note to the "RPKI Signed
   Objects" registry:

   |  Objects of the types listed in this registry, as well as RPKI
   |  resource certificates and CRLs, are expected to be validated using
   |  the RPKI.

12.3.  File Extension

   IANA is asked to add an item for the Signed TAL file extension to the
   "RPKI Repository Name Schemes" created by [RFC6481] as follows:

       Filename Extension  | RPKI Object              | Reference
       --------------------+--------------------------+----------------
        .tak               | Trust Anchor Key         | [this document]

12.4.  Module Identifier

   IANA is asked to register an object identifier for one module
   identifier in the "SMI Security for S/MIME Module Identifier
   (1.2.840.113549.1.9.16.0)" registry as follows:





Martinez, et al.        Expires 17 November 2024               [Page 16]

Internet-Draft         RPKI signed object for TAL               May 2024


          Decimal | Description                    | References
          --------+--------------------------------+---------------
          74      | RPKISignedTrustAnchorList-2021 | [this document]

   *  Description: RPKISignedTrustAnchorList-2021

   *  OID: 1.2.840.113549.1.9.16.0.74

   *  Specification: [this document]

12.5.  Registration of Media Type application/rpki-signed-tal

   IANA is asked to register the media type "application/rpki-signed-
   tal" in the "Media Types" registry as follows:

   Type name:  application

   Subtype name:  rpki-signed-tal

   Required parameters:  N/A

   Optional parameters:  N/A

   Encoding considerations:  binary

   Security considerations:  Carries an RPKI Signed TAL.  This media
      type contains no active content.  See the Security Considerations
      section of RFC XXXX for further information.

   Interoperability considerations:  N/A

   Published specification:  RFC XXXX

   Applications that use this media type:  RPKI operators

   Fragment identifier considerations:  N/A

   Additional information:  Content:  This media type is for a signed
         object, as defined in RFC 6488, which contains trust anchor key
         material as defined in RFC XXXX.

                            Magic number(s):  N/A

                            File extension(s):  .tak

                            Macintosh file type code(s):  N/A





Martinez, et al.        Expires 17 November 2024               [Page 17]

Internet-Draft         RPKI signed object for TAL               May 2024


   Person & email address to contact for further information:
   iesg@ietf.org

   Intended usage:  COMMON

   Restrictions on usage:  N/A

   Author:  sidrops WG

   Change controller:  IESG

13.  Implementation Status

   NOTE: Please remove this section and the reference to RFC 7942 prior
   to publication as an RFC.

   This section records the status of known implementations of the
   protocol defined by this specification at the time of posting of this
   Internet-Draft, and is based on a proposal described in [RFC7942].
   The description of implementations in this section is intended to
   assist the IETF in its decision processes in progressing drafts to
   RFCs.  Please note that the listing of any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a catalog of available implementations or their
   features.  Readers are advised to note that other implementations may
   exist.

   According to RFC 7942, "this will allow reviewers and working groups
   to assign due consideration to documents that have the benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the implemented protocols more mature.
   It is up to the individual working groups to use this information as
   they see fit".

13.1.  APNIC

   *  Responsible Organization: Asia-Pacific Network Information Centre

   *  Location: https://github.com/APNIC-net/rpki-signed-tal-demo

   *  Description: A proof-of-concept for relying party TAK usage.

   *  Level of Maturity: This is a proof-of-concept implementation.






Martinez, et al.        Expires 17 November 2024               [Page 18]

Internet-Draft         RPKI signed object for TAL               May 2024


   *  Coverage: This implementation includes all of the features
      described in version 16 of this specification, except for writing
      TAL files based on TAK data.  The repository includes a link to
      various test TALs that can be used for testing TAK scenarios, too.

   *  Contact Information: Tom Harrison, tomh@apnic.net

13.2.  rpki-client

   *  Responsible Organization: Job Snijders, the OpenBSD project

   *  Location: https://www.rpki-client.org

   *  Description: A relying party implementation which can validate
      TAKs.

   *  Level of Maturity: Mature.  Trust Anchor operators are encouraged
      to use rpki-client as part of smoke testing to help ensure high
      levels of standards compliance when introducing changes, and use
      rpki-client in a continuous monitoring fashion to help maintain
      high levels of operational excellence.

   *  Coverage: This implementation includes all features except TAK
      acceptance timers.

   *  Contact information: Job Snijders, job@fastly.com

13.3.  rpki-rs

   *  Responsible Organization: Tim Bruijnzeels, tim@ripe.net

   *  Location: https://github.com/NLnetLabs/rpki-rs/tree/signed-tal

   *  Description: Library support for encoding and decoding TAK
      objects.

   *  Level of Maturity: This is a proof-of-concept implementation.

   *  Coverage: This implementation includes support for encoding and
      decoding TAK objects.

   *  Contact information: Tim Bruijnzeels, tim@ripe.net

14.  Revision History

   03 - Last draft under Tim's authorship.

   04 - First draft with George's authorship.  No substantive revisions.



Martinez, et al.        Expires 17 November 2024               [Page 19]

Internet-Draft         RPKI signed object for TAL               May 2024


   05 - First draft with Tom's authorship.  No substantive revisions.

   06 - Rob Kisteleki's critique.

   07 - Switch to two-key model.

   08 - Keepalive.

   09 - Acceptance timers, predecessor keys, no long-lived CRL/MFT.

   10 - Using TAK objects for distribution of TAL data.

   11 - Manual update guidance, additional security considerations,
   identifier updates.

   12 - TAK object comments.

   13 - Removal of compromise text, extra RP support text, key
   destruction text, media type registration, signed object registry
   note.

   14 - Keepalive.

   15 - Additional implementation notes and editorial updates.

   16 - Updates from Secdir and IESG reviews.

15.  Acknowledgments

   The authors wish to thank Martin Hoffmann for a thorough review of
   the document, Russ Housley for multiple reviews of the ASN.1
   definitions and for providing a new module for the TAK object, Job
   Snijders for the extensive suggestions around TAK object structure/
   distribution and rpki-client implementation work, and Ties de Kock
   for text/suggestions around TAK/TAL distribution and general security
   considerations.

16.  References

16.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.






Martinez, et al.        Expires 17 November 2024               [Page 20]

Internet-Draft         RPKI signed object for TAL               May 2024


   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/info/rfc3629>.

   [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>.

   [RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network
              Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
              <https://www.rfc-editor.org/info/rfc5198>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [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>.

   [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>.





Martinez, et al.        Expires 17 November 2024               [Page 21]

Internet-Draft         RPKI signed object for TAL               May 2024


   [RFC8630]  Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
              Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
              Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630,
              August 2019, <https://www.rfc-editor.org/info/rfc8630>.

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/info/rfc9110>.

   [RFC9286]  Austein, R., Huston, G., Kent, S., and M. Lepinski,
              "Manifests for the Resource Public Key Infrastructure
              (RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022,
              <https://www.rfc-editor.org/info/rfc9286>.

   [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.

16.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>.

   [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", BCP 205,
              RFC 7942, DOI 10.17487/RFC7942, July 2016,
              <https://www.rfc-editor.org/info/rfc7942>.

Appendix A.  ASN.1 Module

   This appendix includes the ASN.1 module for the TAK object.
















Martinez, et al.        Expires 17 November 2024               [Page 22]

Internet-Draft         RPKI signed object for TAL               May 2024


   <CODE BEGINS>
   RPKISignedTrustAnchorList-2021
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs9(9) smime(16) mod(0) 74 }

   DEFINITIONS EXPLICIT TAGS ::=
   BEGIN

   IMPORTS

   CONTENT-TYPE
       FROM CryptographicMessageSyntax-2009 -- in [RFC5911]
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) }

   SubjectPublicKeyInfo
       FROM PKIX1Explicit-2009 -- in [RFC5912]
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-pkix1-explicit-02(51) } ;

   ct-signedTAL CONTENT-TYPE ::=
       { TYPE TAK IDENTIFIED BY
         id-ct-signedTAL }

   id-ct-signedTAL OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 50 }

   CertificateURI ::= IA5String

   TAKey ::= SEQUENCE {
       comments  SEQUENCE SIZE (0..MAX) OF UTF8String,
       certificateURIs  SEQUENCE SIZE (1..MAX) OF CertificateURI,
       subjectPublicKeyInfo  SubjectPublicKeyInfo
   }

   TAK ::= SEQUENCE {
       version     INTEGER DEFAULT 0,
       current     TAKey,
       predecessor [0] TAKey OPTIONAL,
       successor   [1] TAKey OPTIONAL
   }

   END
   <CODE ENDS>

Authors' Addresses




Martinez, et al.        Expires 17 November 2024               [Page 23]

Internet-Draft         RPKI signed object for TAL               May 2024


   Carlos Martinez
   LACNIC
   Rambla Mexico 6125
   11400 Montevideo
   Uruguay
   Email: carlos@lacnic.net
   URI:   https://www.lacnic.net/


   George G. Michaelson
   Asia Pacific Network Information Centre
   6 Cordelia St
   South Brisbane QLD 4101
   Australia
   Email: ggm@apnic.net


   Tom Harrison
   Asia Pacific Network Information Centre
   6 Cordelia St
   South Brisbane QLD 4101
   Australia
   Email: tomh@apnic.net


   Tim Bruijnzeels
   RIPE NCC
   Stationsplein 11
   Amsterdam
   Netherlands
   Email: tim@ripe.net
   URI:   https://www.ripe.net/


   Rob Austein
   Dragon Research Labs
   Email: sra@hactrn.net














Martinez, et al.        Expires 17 November 2024               [Page 24]

--rQbEyiJe6XyvY2Db
Content-Type: text/html; charset=us-ascii
Content-Disposition: attachment;
	filename="draft-ietf-sidrops-signed-tal-16-from-5.diff.html"

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 
<!-- Generated by rfcdiff 1.45: rfcdiff  --> 
<!-- <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional" > -->
<!-- System: Linux TomH-498551 6.1.0-21-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.90-1 (2024-05-03) x86_64 GNU/Linux --> 
<!-- Using awk: /usr/bin/gawk: GNU Awk 5.2.1, API 3.2, PMA Avon 8-g1, (GNU MPFR 4.2.0, GNU MP 6.2.1) --> 
<!-- Using diff: /usr/bin/diff: diff (GNU diffutils) 3.8 --> 
<!-- Using wdiff: /usr/bin/wdiff: wdiff (GNU wdiff) 1.2.2 --> 
<html xmlns="http://www.w3.org/1999/xhtml"> 
<head> 
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> 
  <meta http-equiv="Content-Style-Type" content="text/css" /> 
  <title>Diff: draft-ietf-sidrops-signed-tal-15.txt - draft-ietf-sidrops-signed-tal-16.txt</title> 
  <style type="text/css"> 
    body    { margin: 0.4ex; margin-right: auto; } 
    tr      { } 
    td      { white-space: pre; font-family: monospace; vertical-align: top; font-size: 0.86em;} 
    th      { font-size: 0.86em; } 
    .small  { font-size: 0.6em; font-style: italic; font-family: Verdana, Helvetica, sans-serif; } 
    .left   { background-color: #EEE; } 
    .right  { background-color: #FFF; } 
    .diff   { background-color: #CCF; } 
    .lblock { background-color: #BFB; } 
    .rblock { background-color: #FF8; } 
    .insert { background-color: #8FF; } 
    .delete { background-color: #ACF; } 
    .void   { background-color: #FFB; } 
    .cont   { background-color: #EEE; } 
    .linebr { background-color: #AAA; } 
    .lineno { color: red; background-color: #FFF; font-size: 0.7em; text-align: right; padding: 0 2px; } 
    .elipsis{ background-color: #AAA; } 
    .left .cont { background-color: #DDD; } 
    .right .cont { background-color: #EEE; } 
    .lblock .cont { background-color: #9D9; } 
    .rblock .cont { background-color: #DD6; } 
    .insert .cont { background-color: #0DD; } 
    .delete .cont { background-color: #8AD; } 
    .stats, .stats td, .stats th { background-color: #EEE; padding: 2px 0; } 
    span.hide { display: none; color: #aaa;}    a:hover span { display: inline; }    tr.change { background-color: gray; } 
    tr.change a { text-decoration: none; color: black } 
  </style> 
     <script>
var chunk_index = 0;
var old_chunk = null;

function format_chunk(index) {
    var prefix = "diff";
    var str = index.toString();
    for (x=0; x<(4-str.length); ++x) {
        prefix+='0';
    }
    return prefix + str;
}

function find_chunk(n){
    return document.querySelector('tr[id$="' + n + '"]');
}

function change_chunk(offset) {
    var index = chunk_index + offset;
    var new_str;
    var new_chunk;

    new_str = format_chunk(index);
    new_chunk = find_chunk(new_str);
    if (!new_chunk) {
        return;
    }
    if (old_chunk) {
        old_chunk.style.outline = "";
    }
    old_chunk = new_chunk;
    old_chunk.style.outline = "1px solid red";
    window.location.hash = "#" + new_str;
    window.scrollBy(0,-100);
    chunk_index = index;
}

document.onkeydown = function(e) {
    switch (e.keyCode) {
    case 78:
        change_chunk(1);
        break;
    case 80:
        change_chunk(-1);
        break;
    }
};
   </script> 
</head> 
<body > 
  <table border="0" cellpadding="0" cellspacing="0"> 
  <tr id="part-1" bgcolor="orange"><th></th><th>&nbsp;draft-ietf-sidrops-signed-tal-15.txt&nbsp;</th><th> </th><th>&nbsp;draft-ietf-sidrops-signed-tal-16.txt&nbsp;</th><th></th></tr> 
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">Network Working Group                                        C. Martinez</td><td> </td><td class="right">Network Working Group                                        C. Martinez</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">Internet-Draft                                                    LACNIC</td><td> </td><td class="right">Internet-Draft                                                    LACNIC</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">Intended status: Standards Track                           G. Michaelson</td><td> </td><td class="right">Intended status: Standards Track                           G. Michaelson</td><td class="lineno"></td></tr>
      <tr id="diff0001"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">Expires: 1<span class="delete">2 October 2024 </span>                                    T. Harrison</td><td> </td><td class="rblock">Expires: 1<span class="insert">7 November 2024</span>                                    T. Harrison</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">                                                                   APNIC</td><td> </td><td class="right">                                                                   APNIC</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">                                                          T. Bruijnzeels</td><td> </td><td class="right">                                                          T. Bruijnzeels</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">                                                                RIPE NCC</td><td> </td><td class="right">                                                                RIPE NCC</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">                                                              R. Austein</td><td> </td><td class="right">                                                              R. Austein</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">                                                    Dragon Research Labs</td><td> </td><td class="right">                                                    Dragon Research Labs</td><td class="lineno"></td></tr>
      <tr id="diff0002"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">                                                           <span class="delete">10 April</span> 2024</td><td> </td><td class="rblock">                                                           <span class="insert">  16 May</span> 2024</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">                RPKI Signed Object for Trust Anchor Key</td><td> </td><td class="right">                RPKI Signed Object for Trust Anchor Key</td><td class="lineno"></td></tr>
      <tr id="diff0003"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">                    draft-ietf-sidrops-signed-tal-1<span class="delete">5</span></td><td> </td><td class="rblock">                    draft-ietf-sidrops-signed-tal-1<span class="insert">6</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">Abstract</td><td> </td><td class="right">Abstract</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the</td><td> </td><td class="right">   A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Resource Public Key Infrastructure (RPKI) to locate and validate a</td><td> </td><td class="right">   Resource Public Key Infrastructure (RPKI) to locate and validate a</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Trust Anchor (TA) Certification Authority (CA) certificate used in</td><td> </td><td class="right">   Trust Anchor (TA) Certification Authority (CA) certificate used in</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   RPKI validation.  This document defines an RPKI signed object for a</td><td> </td><td class="right">   RPKI validation.  This document defines an RPKI signed object for a</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Trust Anchor Key (TAK), that can be used by a TA to signal the</td><td> </td><td class="right">   Trust Anchor Key (TAK), that can be used by a TA to signal the</td><td class="lineno"></td></tr>
      <tr id="diff0004"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   location(s) of the accompanying CA certificate for the current key to</td><td> </td><td class="rblock">   location(s) of the accompanying CA certificate for the current <span class="insert">public</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   RPs, as well as the successor key and the location(s) of its CA</td><td> </td><td class="rblock">   key to RPs, as well as the successor <span class="insert">public</span> key and the location(s)</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   certificate.  This object helps to support planned key <span class="delete">rolls</span> without</td><td> </td><td class="rblock">   of its CA certificate.  This object helps to support planned key</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   impacting RPKI validation.</td><td> </td><td class="rblock">   <span class="insert">rollovers</span> without impacting RPKI validation.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">Status of This Memo</td><td> </td><td class="right">Status of This Memo</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   This Internet-Draft is submitted in full conformance with the</td><td> </td><td class="right">   This Internet-Draft is submitted in full conformance with the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   provisions of BCP 78 and BCP 79.</td><td> </td><td class="right">   provisions of BCP 78 and BCP 79.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Internet-Drafts are working documents of the Internet Engineering</td><td> </td><td class="right">   Internet-Drafts are working documents of the Internet Engineering</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Task Force (IETF).  Note that other groups may also distribute</td><td> </td><td class="right">   Task Force (IETF).  Note that other groups may also distribute</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   working documents as Internet-Drafts.  The list of current Internet-</td><td> </td><td class="right">   working documents as Internet-Drafts.  The list of current Internet-</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Drafts is at https://datatracker.ietf.org/drafts/current/.</td><td> </td><td class="right">   Drafts is at https://datatracker.ietf.org/drafts/current/.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Internet-Drafts are draft documents valid for a maximum of six months</td><td> </td><td class="right">   Internet-Drafts are draft documents valid for a maximum of six months</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   and may be updated, replaced, or obsoleted by other documents at any</td><td> </td><td class="right">   and may be updated, replaced, or obsoleted by other documents at any</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   time.  It is inappropriate to use Internet-Drafts as reference</td><td> </td><td class="right">   time.  It is inappropriate to use Internet-Drafts as reference</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   material or to cite them other than as "work in progress."</td><td> </td><td class="right">   material or to cite them other than as "work in progress."</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0005"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   This Internet-Draft will expire on 1<span class="delete">2 Octo</span>ber 2024.</td><td> </td><td class="rblock">   This Internet-Draft will expire on 1<span class="insert">7 Novem</span>ber 2024.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">Copyright Notice</td><td> </td><td class="right">Copyright Notice</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Copyright (c) 2024 IETF Trust and the persons identified as the</td><td> </td><td class="right">   Copyright (c) 2024 IETF Trust and the persons identified as the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   document authors.  All rights reserved.</td><td> </td><td class="right">   document authors.  All rights reserved.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   This document is subject to BCP 78 and the IETF Trust's Legal</td><td> </td><td class="right">   This document is subject to BCP 78 and the IETF Trust's Legal</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Provisions Relating to IETF Documents (https://trustee.ietf.org/</td><td> </td><td class="right">   Provisions Relating to IETF Documents (https://trustee.ietf.org/</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   license-info) in effect on the date of publication of this document.</td><td> </td><td class="right">   license-info) in effect on the date of publication of this document.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Please review these documents carefully, as they describe your rights</td><td> </td><td class="right">   Please review these documents carefully, as they describe your rights</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="part-2" class="change" ><td></td><th><small>skipping to change at</small><a href="#part-2"><em> page 2, line 23<span class="hide"> &para;</span></em></a></th><th> </th><th><small>skipping to change at</small><a href="#part-2"><em> page 2, line 23<span class="hide"> &para;</span></em></a></th><td></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">Table of Contents</td><td> </td><td class="right">Table of Contents</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   1.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   3</td><td> </td><td class="right">   1.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   3</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3</td><td> </td><td class="right">   2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   3</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   3.  TAK Object Definition . . . . . . . . . . . . . . . . . . . .   4</td><td> </td><td class="right">   3.  TAK Object Definition . . . . . . . . . . . . . . . . . . . .   4</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">     3.1.  The TAK Object Content Type . . . . . . . . . . . . . . .   4</td><td> </td><td class="right">     3.1.  The TAK Object Content Type . . . . . . . . . . . . . . .   4</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">     3.2.  The TAK Object eContent . . . . . . . . . . . . . . . . .   4</td><td> </td><td class="right">     3.2.  The TAK Object eContent . . . . . . . . . . . . . . . . .   4</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">       3.2.1.  TAKey . . . . . . . . . . . . . . . . . . . . . . . .   5</td><td> </td><td class="right">       3.2.1.  TAKey . . . . . . . . . . . . . . . . . . . . . . . .   5</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">       3.2.2.  TAK . . . . . . . . . . . . . . . . . . . . . . . . .   5</td><td> </td><td class="right">       3.2.2.  TAK . . . . . . . . . . . . . . . . . . . . . . . . .   5</td><td class="lineno"></td></tr>
      <tr id="diff0006"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">     3.3.  TAK Object Validation . . . . . . . . . . . . . . . . . .   <span class="delete">6</span></td><td> </td><td class="rblock">     3.3.  TAK Object Validation . . . . . . . . . . . . . . . . . .   <span class="insert">5</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   4.  TAK Object Generation and Publication . . . . . . . . . . . .   6</td><td> </td><td class="right">   4.  TAK Object Generation and Publication . . . . . . . . . . . .   6</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   5.  Relying Party Use . . . . . . . . . . . . . . . . . . . . . .   7</td><td> </td><td class="right">   5.  Relying Party Use . . . . . . . . . . . . . . . . . . . . . .   7</td><td class="lineno"></td></tr>
      <tr id="diff0007"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">     5.1.  Manual update of TA key details . . . . . . . . . <span class="delete">. . . .</span>   9</td><td> </td><td class="rblock">     5.1.  Manual update of TA <span class="insert">public</span> key details  . . . . . . . . .   9</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   6.  Maintaining Multiple TA <span class="delete">Keys  . .</span> . . . . . . . . . . . . . .   9</td><td> </td><td class="rblock">   6.  Maintaining Multiple TA <span class="insert">Key Pairs</span> . . . . . . . . . . . . . .   9</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   7.  Performing TA Key Rolls . . . . . . . . . . . . . . . . . . .  11</td><td> </td><td class="right">   7.  Performing TA Key Rolls . . . . . . . . . . . . . . . . . . .  11</td><td class="lineno"></td></tr>
      <tr id="diff0008"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">     7.1.  Phase 1: Add a TAK for Key 'A'  . . . . . . . . . . . <span class="delete">. .</span>  11</td><td> </td><td class="rblock">     7.1.  Phase 1: Add a TAK for Key <span class="insert">Pair</span> 'A' . . . . . . . . . . .  11</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">     7.2.  Phase 2: Add a Key 'B'  . . . . . . . . . . . . . . . <span class="delete">. .</span>  11</td><td> </td><td class="rblock">     7.2.  Phase 2: Add a Key <span class="insert">Pair</span> 'B' . . . . . . . . . . . . . . .  11</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">     7.3.  Phase 3: Update TAL to point to 'B' . . . . . . . . . . .  <span class="delete">12</span></td><td> </td><td class="rblock">     7.3.  Phase 3: Update TAL to point to 'B' . . . . . . . . . . .  <span class="insert">11</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">     7.4.  Phase 4: Remove Key 'A' <span class="delete">. . .</span> . . . . . . . . . . . . . .  12</td><td> </td><td class="rblock">     7.4.  Phase 4: Remove Key <span class="insert">Pair</span> 'A'  . . . . . . . . . . . . . .  12</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   8.  Using TAK objects to distribute TAL data  . . . . . . . . . .  12</td><td> </td><td class="right">   8.  Using TAK objects to distribute TAL data  . . . . . . . . . .  12</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   9.  Deployment Considerations . . . . . . . . . . . . . . . . . .  13</td><td> </td><td class="right">   9.  Deployment Considerations . . . . . . . . . . . . . . . . . .  13</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">     9.1.  Relying Party Support . . . . . . . . . . . . . . . . . .  13</td><td> </td><td class="right">     9.1.  Relying Party Support . . . . . . . . . . . . . . . . . .  13</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">     9.2.  Alternate Transition Models . . . . . . . . . . . . . . .  13</td><td> </td><td class="right">     9.2.  Alternate Transition Models . . . . . . . . . . . . . . .  13</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   10. Operational Considerations  . . . . . . . . . . . . . . . . .  14</td><td> </td><td class="right">   10. Operational Considerations  . . . . . . . . . . . . . . . . .  14</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">     10.1.  Acceptance Timers  . . . . . . . . . . . . . . . . . . .  14</td><td> </td><td class="right">     10.1.  Acceptance Timers  . . . . . . . . . . . . . . . . . . .  14</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   11. Security Considerations . . . . . . . . . . . . . . . . . . .  14</td><td> </td><td class="right">   11. Security Considerations . . . . . . . . . . . . . . . . . . .  14</td><td class="lineno"></td></tr>
      <tr id="diff0009"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">     11.1.  Previous Keys  . . . . . . . . . . . . . . . . . . . . .  1<span class="delete">5</span></td><td> </td><td class="rblock">     11.1.  Previous Keys  . . . . . . . . . . . . . . . . . . . . .  1<span class="insert">4</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">     11.2.  TA Compromise  . . . . . . . . . . . . . . . . . . . . .  15</td><td> </td><td class="right">     11.2.  TA Compromise  . . . . . . . . . . . . . . . . . . . . .  15</td><td class="lineno"></td></tr>
      <tr id="diff0010"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">     11.3.  Alternate Transition Models  . . . . . . . . . . . . . .  15</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15</td><td> </td><td class="right">   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15</td><td class="lineno"></td></tr>
      <tr id="diff0011"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">     12.1.  Content Type . . . . . . . . . . . . . . . . . . . . . .  1<span class="delete">5</span></td><td> </td><td class="rblock">     12.1.  Content Type . . . . . . . . . . . . . . . . . . . . . .  1<span class="insert">6</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">     12.2.  Signed Object  . . . . . . . . . . . . . . . . . . . . .  16</td><td> </td><td class="right">     12.2.  Signed Object  . . . . . . . . . . . . . . . . . . . . .  16</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">     12.3.  File Extension . . . . . . . . . . . . . . . . . . . . .  16</td><td> </td><td class="right">     12.3.  File Extension . . . . . . . . . . . . . . . . . . . . .  16</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">     12.4.  Module Identifier  . . . . . . . . . . . . . . . . . . .  16</td><td> </td><td class="right">     12.4.  Module Identifier  . . . . . . . . . . . . . . . . . . .  16</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">     12.5.  Registration of Media Type application/</td><td> </td><td class="right">     12.5.  Registration of Media Type application/</td><td class="lineno"></td></tr>
      <tr id="diff0012"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">            rpki-signed-tal  . . . . . . . . . . . . . . . . . . . .  <span class="delete">16</span></td><td> </td><td class="rblock">            rpki-signed-tal  . . . . . . . . . . . . . . . . . . . .  <span class="insert">17</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   13. Implementation Status . . . . . . . . . . . . . . . . . . . .  <span class="delete">17</span></td><td> </td><td class="rblock">   13. Implementation Status . . . . . . . . . . . . . . . . . . . .  <span class="insert">18</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">     13.1.  APNIC  . . . . . . . . . . . . . . . . . . . . . . . . .  18</td><td> </td><td class="right">     13.1.  APNIC  . . . . . . . . . . . . . . . . . . . . . . . . .  18</td><td class="lineno"></td></tr>
      <tr id="diff0013"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">     13.2.  rpki-client  . . . . . . . . . . . . . . . . . . . . . .  1<span class="delete">8</span></td><td> </td><td class="rblock">     13.2.  rpki-client  . . . . . . . . . . . . . . . . . . . . . .  1<span class="insert">9</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">     13.3.  rpki-rs  . . . . . . . . . . . . . . . . . . . . . . . .  19</td><td> </td><td class="right">     13.3.  rpki-rs  . . . . . . . . . . . . . . . . . . . . . . . .  19</td><td class="lineno"></td></tr>
      <tr id="diff0014"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">                                                                         </span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   14. Revision History  . . . . . . . . . . . . . . . . . . . . . .  19</td><td> </td><td class="right">   14. Revision History  . . . . . . . . . . . . . . . . . . . . . .  19</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  20</td><td> </td><td class="right">   15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  20</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20</td><td> </td><td class="right">   16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  20</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">     16.1.  Normative References . . . . . . . . . . . . . . . . . .  20</td><td> </td><td class="right">     16.1.  Normative References . . . . . . . . . . . . . . . . . .  20</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">     16.2.  Informative References . . . . . . . . . . . . . . . . .  22</td><td> </td><td class="right">     16.2.  Informative References . . . . . . . . . . . . . . . . .  22</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Appendix A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . .  22</td><td> </td><td class="right">   Appendix A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . .  22</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23</td><td> </td><td class="right">   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  23</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">1.  Requirements Notation</td><td> </td><td class="right">1.  Requirements Notation</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="part-3" class="change" ><td></td><th><small>skipping to change at</small><a href="#part-3"><em> page 3, line 28<span class="hide"> &para;</span></em></a></th><th> </th><th><small>skipping to change at</small><a href="#part-3"><em> page 3, line 28<span class="hide"> &para;</span></em></a></th><td></td></tr>
      <tr><td class="lineno"></td><td class="left">   14 [RFC2119] [RFC8174] when, and only when, they appear in all</td><td> </td><td class="right">   14 [RFC2119] [RFC8174] when, and only when, they appear in all</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   capitals, as shown here.</td><td> </td><td class="right">   capitals, as shown here.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">2.  Overview</td><td> </td><td class="right">2.  Overview</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   A Trust Anchor Locator (TAL) [RFC8630] is used by Relying Parties</td><td> </td><td class="right">   A Trust Anchor Locator (TAL) [RFC8630] is used by Relying Parties</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   (RPs) in the Resource Public Key Infrastructure (RPKI) to locate and</td><td> </td><td class="right">   (RPs) in the Resource Public Key Infrastructure (RPKI) to locate and</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   validate Trust Anchor (TA) Certification Authority (CA) certificates</td><td> </td><td class="right">   validate Trust Anchor (TA) Certification Authority (CA) certificates</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   used in RPKI validation.  However, until now, there has been no in-</td><td> </td><td class="right">   used in RPKI validation.  However, until now, there has been no in-</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   band way of notifying RPs of updates to a TAL.  In-band notification</td><td> </td><td class="right">   band way of notifying RPs of updates to a TAL.  In-band notification</td><td class="lineno"></td></tr>
      <tr id="diff0015"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   means that <span class="delete">TAs</span> can be more confident of RPs being aware of key <span class="delete">roll</span></td><td> </td><td class="rblock">   means that <span class="insert">TA operators</span> can be more confident of RPs being aware of</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   operations.</td><td> </td><td class="rblock">   key <span class="insert">rollover</span> operations.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   This document defines a new RPKI signed object that can be used to</td><td> </td><td class="right">   This document defines a new RPKI signed object that can be used to</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   document the location(s) of the TA CA certificate for the current TA</td><td> </td><td class="right">   document the location(s) of the TA CA certificate for the current TA</td><td class="lineno"></td></tr>
      <tr id="diff0016"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   key, as well as the value of the successor key and the location(s) of</td><td> </td><td class="rblock">   <span class="insert">public</span> key, as well as the value of the successor <span class="insert">public</span> key and the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   its TA CA certificate.  This allows RPs to be notified automatically</td><td> </td><td class="rblock">   location(s) of its TA CA certificate.  This allows RPs to be notified</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   of such changes, and enables TAs to stage a successor key so that</td><td> </td><td class="rblock">   automatically of such changes, and enables TAs to stage a successor</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   planned key <span class="delete">rolls</span> can be performed without risking the invalidation</td><td> </td><td class="rblock">   <span class="insert">public</span> key so that planned key <span class="insert">rollovers</span> can be performed without</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   of the RPKI tree under the TA.  We call this object the Trust Anchor</td><td> </td><td class="rblock">   risking the invalidation of the RPKI tree under the TA.  We call this</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   Key (TAK) object.</td><td> </td><td class="rblock">   object the Trust Anchor Key (TAK) object.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0017"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   When RPs are first bootstrapped, they use a TAL to discover the key</td><td> </td><td class="rblock">   When RPs are first bootstrapped, they use a TAL to discover the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   and location(s) of the CA certificate for a TA.  The RP can then</td><td> </td><td class="rblock">   <span class="insert">public</span> key and location(s) of the CA certificate for a TA.  The RP</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   retrieve and validate the CA certificate, and subsequently validate</td><td> </td><td class="rblock">   can then retrieve and validate the CA certificate, and subsequently</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   the manifest [RFC9286] and Certificate Revocation List (CRL)</td><td> </td><td class="rblock">   validate the manifest [RFC9286] and Certificate Revocation List (CRL)</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   published by that TA (section 5 of [RFC6487]).  However, before</td><td> </td><td class="right">   published by that TA (section 5 of [RFC6487]).  However, before</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   processing any other objects, it will first validate the TAK object,</td><td> </td><td class="right">   processing any other objects, it will first validate the TAK object,</td><td class="lineno"></td></tr>
      <tr id="diff0018"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   if present.  If the TAK object lists only the current key, then the</td><td> </td><td class="rblock">   if present.  If the TAK object lists only the current <span class="insert">public</span> key,</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   RP continues processing as it would in the absence of a TAK object.</td><td> </td><td class="rblock">   then the RP continues processing as it would in the absence of a TAK</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   If the TAK object includes a successor key, the RP starts <span class="delete">an</span></td><td> </td><td class="rblock">   object.  If the TAK object includes a successor <span class="insert">public</span> key, the RP</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   acceptance <span class="delete">timer,</span> and then continues <span class="delete">processing as it would in</span> the</td><td> </td><td class="rblock">   starts <span class="insert">a 30-day</span> acceptance <span class="insert">timer for that key,</span> and then continues</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   <span class="delete">absence of a TAK object.</span>  If, during the following validation runs up</td><td> </td><td class="rblock">   <span class="insert">standard top-down validation with</span> the <span class="insert">current public key.</span>  If, during</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   until the expiry of the acceptance timer, the RP has not observed any</td><td> </td><td class="rblock">   the following validation runs up until the expiry of the acceptance</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   changes to the keys and certificate URLs listed in the TAK object,</td><td> </td><td class="rblock">   timer, the RP has not observed any changes to the <span class="insert">public</span> keys and</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   then the RP will fetch the successor key, update its local state with</td><td> </td><td class="rblock">   certificate URLs listed in the TAK object, then the RP will fetch the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   that key and its associated certification location(s), and continue</td><td> </td><td class="rblock">   successor <span class="insert">public</span> key, update its local state with that <span class="insert">public</span> key and</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   processing using that key.</td><td> </td><td class="rblock">   its associated certification location(s), and continue processing</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   using that <span class="insert">public</span> key.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   The primary motivation for this work is being able to migrate from a</td><td> </td><td class="right">   The primary motivation for this work is being able to migrate from a</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Hardware Security Module (HSM) produced by one vendor to one produced</td><td> </td><td class="right">   Hardware Security Module (HSM) produced by one vendor to one produced</td><td class="lineno"></td></tr>
      <tr id="diff0019"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   by another, where the first vendor does not support exporting keys</td><td> </td><td class="rblock">   by another, where the first vendor does not support exporting <span class="insert">private</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   for use by the second.  There may be other scenarios in which key</td><td> </td><td class="rblock">   keys for use by the second.  There may be other scenarios in which</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   rollover is useful, though.</td><td> </td><td class="rblock">   key rollover is useful, though.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">3.  TAK Object Definition</td><td> </td><td class="right">3.  TAK Object Definition</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   The TAK object makes use of the template for RPKI digitally signed</td><td> </td><td class="right">   The TAK object makes use of the template for RPKI digitally signed</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   objects [RFC6488], which defines a Cryptographic Message Syntax (CMS)</td><td> </td><td class="right">   objects [RFC6488], which defines a Cryptographic Message Syntax (CMS)</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   [RFC5652] wrapper for the content as well as a generic validation</td><td> </td><td class="right">   [RFC5652] wrapper for the content as well as a generic validation</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   procedure for RPKI signed objects.  Therefore, to complete the</td><td> </td><td class="right">   procedure for RPKI signed objects.  Therefore, to complete the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   specification of the TAK object (see Section 4 of [RFC6488]), this</td><td> </td><td class="right">   specification of the TAK object (see Section 4 of [RFC6488]), this</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   document defines:</td><td> </td><td class="right">   document defines:</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="part-4" class="change" ><td></td><th><small>skipping to change at</small><a href="#part-4"><em> page 4, line 34<span class="hide"> &para;</span></em></a></th><th> </th><th><small>skipping to change at</small><a href="#part-4"><em> page 4, line 36<span class="hide"> &para;</span></em></a></th><td></td></tr>
      <tr><td class="lineno"></td><td class="left">      being a TAK.  (This OID appears within the eContentType in the</td><td> </td><td class="right">      being a TAK.  (This OID appears within the eContentType in the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      encapContentInfo object, as well as the content-type signed</td><td> </td><td class="right">      encapContentInfo object, as well as the content-type signed</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      attribute in the signerInfo object.)</td><td> </td><td class="right">      attribute in the signerInfo object.)</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  The ASN.1 syntax for the TAK eContent, in Section 3.2.</td><td> </td><td class="right">   *  The ASN.1 syntax for the TAK eContent, in Section 3.2.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  The additional steps required to validate a TAK, in Section 3.3.</td><td> </td><td class="right">   *  The additional steps required to validate a TAK, in Section 3.3.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">3.1.  The TAK Object Content Type</td><td> </td><td class="right">3.1.  The TAK Object Content Type</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0020"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   This document <span class="delete">request</span>s an OID for the TAK object as follows:</td><td> </td><td class="rblock">   This document <span class="insert">specifie</span>s an OID for the TAK object as follows:</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      id-ct-signedTAL OBJECT IDENTIFIER ::=</td><td> </td><td class="right">      id-ct-signedTAL OBJECT IDENTIFIER ::=</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)</td><td> </td><td class="right">         { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">           smime(16) ct(1) 50 }</td><td> </td><td class="right">           smime(16) ct(1) 50 }</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   This OID MUST appear in both the eContentType in the encapContentInfo</td><td> </td><td class="right">   This OID MUST appear in both the eContentType in the encapContentInfo</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   object and the content-type signed attribute in the signerInfo object</td><td> </td><td class="right">   object and the content-type signed attribute in the signerInfo object</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   (see [RFC6488]).</td><td> </td><td class="right">   (see [RFC6488]).</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">3.2.  The TAK Object eContent</td><td> </td><td class="right">3.2.  The TAK Object eContent</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   The content of a TAK object is ASN.1 encoded using the Distinguished</td><td> </td><td class="right">   The content of a TAK object is ASN.1 encoded using the Distinguished</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Encoding Rules (DER) [X.690], and is defined per the module in</td><td> </td><td class="right">   Encoding Rules (DER) [X.690], and is defined per the module in</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Appendix A.</td><td> </td><td class="right">   Appendix A.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">3.2.1.  TAKey</td><td> </td><td class="right">3.2.1.  TAKey</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0021"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   This structure defines a TA key, similar to that from [RFC8630].  It</td><td> </td><td class="rblock">   This structure defines a TA <span class="insert">public</span> key, similar to that from</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   contains a sequence of zero or more comments, one or more certificate</td><td> </td><td class="rblock">   [RFC8630].  It contains a sequence of zero or more comments, one or</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   URIs, and a SubjectPublicKeyInfo.</td><td> </td><td class="rblock">   more certificate URIs, and a SubjectPublicKeyInfo.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">                                                                         </td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">3.2.1.1.  comments</span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete"></span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">   This field is equivalent to the comment section defined in section</span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">   2.2 of [RFC8630].  Each comment is human-readable informational UTF-8</span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">   text [RFC3629], conforming to the restrictions defined in Section 2</span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">   of [RFC5198].  The leading "#" character is omitted.</span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete"></span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">3.2.1.2.  certificateURIs</span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0022"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   This field is equivalent to the <span class="delete">URI</span> section defined in section 2.2 of</td><td> </td><td class="rblock">   <span class="insert">*  comments:</span> This field is <span class="insert">semantically</span> equivalent to the <span class="insert">comment</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   [RFC8630].  <span class="delete">It MUST contain at least one CertificateURI element.</span></td><td> </td><td class="rblock">      section defined in section 2.2 of [RFC8630].  Each <span class="insert">comment is</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   Each <span class="delete">CertificateURI element contains</span> the <span class="delete">IA5String representation</span> of</td><td> </td><td class="rblock"><span class="insert">      human-readable informational UTF-8 text [RFC3629], conforming to</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   <span class="delete">either an rsync URI [RFC5781], or an HTTPS URI [RFC9110].</span></td><td> </td><td class="rblock">      the <span class="insert">restrictions defined in Section 2</span> of <span class="insert">[RFC5198].  The leading</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      "#" character that is used to denote a comment in [RFC8630] is</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      omitted here.</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0023"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">3.2.1.3.  subjectPublicKeyInfo</span></td><td> </td><td class="rblock">   <span class="insert">*  certificateURIs: This field is semantically equivalent to the URI</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      section defined in section 2.2 of [RFC8630].  It MUST contain at</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      least one CertificateURI element.  Each CertificateURI element</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      contains the IA5String representation of either an rsync URI</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      [RFC5781], or an HTTPS URI [RFC9110].</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0024"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   This field contains a SubjectPublicKeyInfo (section 4.1.2.7 of</td><td> </td><td class="rblock">   <span class="insert">*  subjectPublicKeyInfo:</span> This field contains a SubjectPublicKeyInfo</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   [RFC5280]) in DER format [X.690].</td><td> </td><td class="rblock">      (section 4.1.2.7 of [RFC5280]) in DER format [X.690].</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">3.2.2.  TAK</td><td> </td><td class="right">3.2.2.  TAK</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0025"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">3.2.2.1.  version</span></td><td> </td><td class="rblock">   <span class="insert">*  version:</span> The version number of the TAK object MUST be 0.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">                                                                         </td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   The version number of the TAK object MUST be 0.</td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">                                                                         </td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">3.2.2.2.  current</span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete"></span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">   This field contains the TA key of the repository in which the TAK</span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">   object is published.</span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete"></span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">3.2.2.3.  predecessor</span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0026"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   This field contains the TA key <span class="delete">that was</span> in <span class="delete">use for this TA</span></td><td> </td><td class="rblock">   <span class="insert">*  current:</span> This field contains the TA <span class="insert">public</span> key <span class="insert">of the repository</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">   immediately prior to</span> the <span class="delete">current TA key, if applicable.</span></td><td> </td><td class="rblock">      in <span class="insert">which</span> the <span class="insert">TAK object is published.</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0027"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">3.2.2.4.  successor</span></td><td> </td><td class="rblock">   <span class="insert">*  predecessor: This field contains the TA public key that was in use</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      for this TA immediately prior to the current TA public key, if</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">      applicable.</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0028"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   This field contains the TA key to be used in place of the current</td><td> </td><td class="rblock">   <span class="insert">*  successor:</span> This field contains the TA <span class="insert">public</span> key to be used in</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   key, after expiry of the relevant acceptance timer.</td><td> </td><td class="rblock">      place of the current <span class="insert">public</span> key, <span class="insert">if applicable,</span> after expiry of</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">      the relevant acceptance timer.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">3.3.  TAK Object Validation</td><td> </td><td class="right">3.3.  TAK Object Validation</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   To determine whether a TAK object is valid, the RP MUST perform the</td><td> </td><td class="right">   To determine whether a TAK object is valid, the RP MUST perform the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   following checks in addition to those specified in [RFC6488]:</td><td> </td><td class="right">   following checks in addition to those specified in [RFC6488]:</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  The eContentType OID matches the OID described in Section 3.1.</td><td> </td><td class="right">   *  The eContentType OID matches the OID described in Section 3.1.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  The TAK object appears as the product of a TA CA certificate (i.e.</td><td> </td><td class="right">   *  The TAK object appears as the product of a TA CA certificate (i.e.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      the TA CA certificate is itself the issuer of the End-Entity (EE)</td><td> </td><td class="right">      the TA CA certificate is itself the issuer of the End-Entity (EE)</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      certificate of the TAK object).</td><td> </td><td class="right">      certificate of the TAK object).</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  The TA CA has published only one TAK object in its repository for</td><td> </td><td class="right">   *  The TA CA has published only one TAK object in its repository for</td><td class="lineno"></td></tr>
      <tr id="diff0029"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">      this key, and this object appears on the manifest as the only</td><td> </td><td class="rblock">      this <span class="insert">public</span> key, and this object appears on the manifest as the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">      entry using the ".tak" extension (see [RFC6481]).</td><td> </td><td class="rblock">      only entry using the ".tak" extension (see [RFC6481]).</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  The EE certificate of this TAK object describes its Internet</td><td> </td><td class="right">   *  The EE certificate of this TAK object describes its Internet</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      Number Resources (INRs) using the "inherit" attribute.</td><td> </td><td class="right">      Number Resources (INRs) using the "inherit" attribute.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  The decoded TAK content conforms to the format defined in</td><td> </td><td class="right">   *  The decoded TAK content conforms to the format defined in</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      Section 3.2.</td><td> </td><td class="right">      Section 3.2.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0030"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   *  The SubjectPublicKeyInfo value of the current TA key in the TAK</td><td> </td><td class="rblock">   *  The SubjectPublicKeyInfo value of the current TA <span class="insert">public</span> key in the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">      object matches that of the TA CA certificate used to issue the EE</td><td> </td><td class="rblock">      TAK object matches that of the TA CA certificate used to issue the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">      certificate of the TAK object.</td><td> </td><td class="rblock">      EE certificate of the TAK object.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   If any of these checks does not succeed, the RP MUST ignore the TAK</td><td> </td><td class="right">   If any of these checks does not succeed, the RP MUST ignore the TAK</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   object and proceed as though it were not listed on the manifest.</td><td> </td><td class="right">   object and proceed as though it were not listed on the manifest.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   The RP is not required to compare its current set of certificateURIs</td><td> </td><td class="right">   The RP is not required to compare its current set of certificateURIs</td><td class="lineno"></td></tr>
      <tr id="diff0031"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   for the current key with those listed in the TAK object.  The RP MAY</td><td> </td><td class="rblock">   for the current <span class="insert">public</span> key with those listed in the TAK object.  The</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   alert the user that these sets of certificateURIs do not match, with</td><td> </td><td class="rblock">   RP MAY alert the user that these sets of certificateURIs do not</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   a view to the user manually updating the set of certificateURIs in</td><td> </td><td class="rblock">   match, with a view to the user manually updating the set of</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   their configuration.  The RP MUST NOT automatically update its</td><td> </td><td class="rblock">   certificateURIs in their configuration.  The RP MUST NOT</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   configuration to use these certificateURIs in the event of</td><td> </td><td class="rblock">   automatically update its configuration to use these certificateURIs</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   inconsistency, though, because the migration of users to new</td><td> </td><td class="rblock">   in the event of inconsistency, though, because the migration of users</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   certificateURIs should happen by way of the successor key process.</td><td> </td><td class="rblock">   to new certificateURIs should happen by way of the successor <span class="insert">public</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   key process.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">4.  TAK Object Generation and Publication</td><td> </td><td class="right">4.  TAK Object Generation and Publication</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0032"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   <span class="delete">If a TA chooses to use TAK objects to communicate its current,</span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">   predecessor, and successor keys, then it SHOULD generate and publish</span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">   TAK objects under each of its keys.</span></td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">                                                                         </td><td> </td><td class="rblock"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   A non-normative guideline for naming this object is that the filename</td><td> </td><td class="right">   A non-normative guideline for naming this object is that the filename</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   chosen for the TAK object in the publication repository be a value</td><td> </td><td class="right">   chosen for the TAK object in the publication repository be a value</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   derived from the public key part of the entity's key pair, using the</td><td> </td><td class="right">   derived from the public key part of the entity's key pair, using the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   algorithm described for CRLs in section 2.2 of [RFC6481] for</td><td> </td><td class="right">   algorithm described for CRLs in section 2.2 of [RFC6481] for</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   generation of filenames.  The filename extension of ".tak" MUST be</td><td> </td><td class="right">   generation of filenames.  The filename extension of ".tak" MUST be</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   used to denote the object as a TAK.</td><td> </td><td class="right">   used to denote the object as a TAK.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   In order to generate a TAK object, the TA MUST perform the following</td><td> </td><td class="right">   In order to generate a TAK object, the TA MUST perform the following</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   actions:</td><td> </td><td class="right">   actions:</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="part-5" class="change" ><td></td><th><small>skipping to change at</small><a href="#part-5"><em> page 7, line 41<span class="hide"> &para;</span></em></a></th><th> </th><th><small>skipping to change at</small><a href="#part-5"><em> page 7, line 21<span class="hide"> &para;</span></em></a></th><td></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  This EE certificate MUST have a "notBefore" time that matches or</td><td> </td><td class="right">   *  This EE certificate MUST have a "notBefore" time that matches or</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      predates the moment that the TAK will be published.</td><td> </td><td class="right">      predates the moment that the TAK will be published.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  This EE certificate MUST have a "notAfter" time that reflects the</td><td> </td><td class="right">   *  This EE certificate MUST have a "notAfter" time that reflects the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      intended duration for which this TAK will be published.  If the EE</td><td> </td><td class="right">      intended duration for which this TAK will be published.  If the EE</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      certificate for a TAK object is expired, it MUST no longer be</td><td> </td><td class="right">      certificate for a TAK object is expired, it MUST no longer be</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      published, but it MAY be replaced by a newly generated TAK object</td><td> </td><td class="right">      published, but it MAY be replaced by a newly generated TAK object</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      with equivalent content and an updated "notAfter" time.</td><td> </td><td class="right">      with equivalent content and an updated "notAfter" time.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0033"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   *  The current TA key for the TAK MUST match that of the TA CA</td><td> </td><td class="rblock">   *  The current TA <span class="insert">public </span>key for the TAK MUST match that of the TA CA</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      certificate under which the TAK was issued.</td><td> </td><td class="right">      certificate under which the TAK was issued.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0034"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   <span class="insert">In distribution contexts that support media types, the "application/</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   rpki-signed-tal" media type can be used for TAK objects.</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">                                                                         </td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">5.  Relying Party Use</td><td> </td><td class="right">5.  Relying Party Use</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0035"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   Relying Parties MUST keep a record of the current key for each</td><td> </td><td class="rblock">   Relying Parties MUST keep a record of the current <span class="insert">public </span>key for each</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   configured TA, as well as the URI(s) where the CA certificate for</td><td> </td><td class="right">   configured TA, as well as the URI(s) where the CA certificate for</td><td class="lineno"></td></tr>
      <tr id="diff0036"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   this key may be retrieved.  This record is typically bootstrapped by</td><td> </td><td class="rblock">   this <span class="insert">public</span> key may be retrieved.  This record is typically</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   the use of a pre-configured (and unsigned) TAL file [RFC8630].</td><td> </td><td class="rblock">   bootstrapped by the use of a pre-configured (and unsigned) TAL file</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   [RFC8630].</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   When performing top-down validation, RPs MUST first validate and</td><td> </td><td class="right">   When performing top-down validation, RPs MUST first validate and</td><td class="lineno"></td></tr>
      <tr id="diff0037"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   process the TAK object for its current known key, by performing the</td><td> </td><td class="rblock">   process the TAK object for its current known <span class="insert">public</span> key, by</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   following steps:</td><td> </td><td class="rblock">   performing the following steps:</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  A CA certificate is retrieved and validated from the known URIs as</td><td> </td><td class="right">   *  A CA certificate is retrieved and validated from the known URIs as</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      described in sections 3 and 4 of [RFC8630].</td><td> </td><td class="right">      described in sections 3 and 4 of [RFC8630].</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  The manifest and CRL for this certificate are then validated as</td><td> </td><td class="right">   *  The manifest and CRL for this certificate are then validated as</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      described in [RFC6487] and [RFC9286].</td><td> </td><td class="right">      described in [RFC6487] and [RFC9286].</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  The TAK object, if present, is validated as described in</td><td> </td><td class="right">   *  The TAK object, if present, is validated as described in</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      Section 3.3.</td><td> </td><td class="right">      Section 3.3.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0038"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   If the TAK object includes a successor key, then the RP must verify</td><td> </td><td class="rblock">   If the TAK object includes a successor <span class="insert">public</span> key, then the RP must</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   the successor key by doing the following:</td><td> </td><td class="rblock">   verify the successor <span class="insert">public</span> key by doing the following:</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0039"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   *  performing top-down validation using the successor key, in order</td><td> </td><td class="rblock">   *  performing top-down validation using the successor <span class="insert">public</span> key, in</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">      to validate the TAK object for the successor TA;</td><td> </td><td class="rblock">      order to validate the TAK object for the successor TA;</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  ensuring that a valid TAK object exists for the successor TA;</td><td> </td><td class="right">   *  ensuring that a valid TAK object exists for the successor TA;</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0040"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   *  ensuring that the successor TAK object's current key matches the</td><td> </td><td class="rblock">   *  ensuring that the successor TAK object's current <span class="insert">public</span> key</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">      initial TAK object's successor key; and</td><td> </td><td class="rblock">      matches the initial TAK object's successor <span class="insert">public</span> key; and</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0041"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   *  ensuring that the successor TAK object's predecessor key matches</td><td> </td><td class="rblock">   *  ensuring that the successor TAK object's predecessor <span class="insert">public</span> key</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">      the initial TAK object's current key.</td><td> </td><td class="rblock">      matches the initial TAK object's current <span class="insert">public</span> key.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0042"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   If any of these steps fails, then the successor key has failed</td><td> </td><td class="rblock">   If any of these steps fails, then the successor <span class="insert">public </span>key has failed</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   verification.</td><td> </td><td class="right">   verification.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0043"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   If the successor key passes verification, and the RP has not seen</td><td> </td><td class="rblock">   If the successor <span class="insert">public</span> key passes verification, and the RP has not</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   that successor key on the previous successful validation run for this</td><td> </td><td class="rblock">   seen that successor <span class="insert">public</span> key on the previous successful validation</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   TA, then the RP:</td><td> </td><td class="rblock">   run for this TA, then the RP:</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0044"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   *  sets an acceptance timer of 30 days for this successor key for</td><td> </td><td class="rblock">   *  sets an acceptance timer of 30 days for this successor <span class="insert">public</span> key</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">      this TA;</td><td> </td><td class="rblock">      for this TA;</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  cancels the existing acceptance timer for this TA (if applicable);</td><td> </td><td class="right">   *  cancels the existing acceptance timer for this TA (if applicable);</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      and</td><td> </td><td class="right">      and</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  continues standard top-down validation as described in [RFC6487]</td><td> </td><td class="right">   *  continues standard top-down validation as described in [RFC6487]</td><td class="lineno"></td></tr>
      <tr id="diff0045"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">      using the current key.</td><td> </td><td class="rblock">      using the current <span class="insert">public </span>key.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0046"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   If the successor key passes verification, and the RP has seen that</td><td> </td><td class="rblock">   If the successor <span class="insert">public</span> key passes verification, and the RP has seen</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   successor key on the previous successful validation run for this TA:</td><td> </td><td class="rblock">   that successor <span class="insert">public</span> key on the previous successful validation run</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   for this TA:</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  if the relevant acceptance timer has not expired, the RP continues</td><td> </td><td class="right">   *  if the relevant acceptance timer has not expired, the RP continues</td><td class="lineno"></td></tr>
      <tr id="diff0047"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">      standard top-down validation using the current key;</td><td> </td><td class="rblock">      standard top-down validation using the current <span class="insert">public </span>key;</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0048"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   *  otherwise, the RP updates its current known key details for this</td><td> </td><td class="rblock">   *  otherwise, the RP updates its current known <span class="insert">public</span> key details for</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">      TA to be those of the successor key, and then begins top-down</td><td> </td><td class="rblock">      this TA to be those of the successor <span class="insert">public</span> key, and then begins</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">      validation again using the successor key.</td><td> </td><td class="rblock">      top-down validation again using the successor <span class="insert">public</span> key.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0049"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   If the successor key does not pass verification, or if the TAK object</td><td> </td><td class="rblock">   If the successor <span class="insert">public</span> key does not pass verification, or if the TAK</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   does not include a successor key, the RP cancels the existing</td><td> </td><td class="rblock">   object does not include a successor <span class="insert">public</span> key, the RP cancels the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   acceptance timer for this TA (if applicable).</td><td> </td><td class="rblock">   existing acceptance timer for this TA (if applicable).</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0050"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   An RP MUST NOT use a successor key for top-down validation outside of</td><td> </td><td class="rblock">   An RP MUST NOT use a successor <span class="insert">public</span> key for top-down validation</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   the process described above, except for the purpose of testing that</td><td> </td><td class="rblock">   outside of the process described above, except for the purpose of</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   the new key is working correctly.  This allows a TA to publish a</td><td> </td><td class="rblock">   testing that the new <span class="insert">public</span> key is working correctly.  This allows a</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   successor key for a period of time, allowing RPs to test it, while</td><td> </td><td class="rblock">   TA to publish a successor <span class="insert">public</span> key for a period of time, allowing</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   still being able to rely on RPs using the current key for their</td><td> </td><td class="rblock">   RPs to test it, while still being able to rely on RPs using the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   production RPKI operations.</td><td> </td><td class="rblock">   current <span class="insert">public</span> key for their production RPKI operations.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0051"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   A successor key may have the same SubjectPublicKeyInfo value as the</td><td> </td><td class="rblock">   A successor <span class="insert">public</span> key may have the same SubjectPublicKeyInfo value</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   current key: this will be the case where a TA is updating the</td><td> </td><td class="rblock">   as the current <span class="insert">public</span> key: this will be the case where a TA is</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   certificateURIs for that key.</td><td> </td><td class="rblock">   updating the certificateURIs for that <span class="insert">public</span> key.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0052"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">5.1.  Manual update of TA key details</td><td> </td><td class="rblock">5.1.  Manual update of TA <span class="insert">public </span>key details</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   A Relying Party may opt not to support the automatic transition of TA</td><td> </td><td class="right">   A Relying Party may opt not to support the automatic transition of TA</td><td class="lineno"></td></tr>
      <tr id="diff0053"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   key data, as defined in the previous section.  An alternative</td><td> </td><td class="rblock">   <span class="insert">public </span>key data, as defined in the previous section.  An alternative</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   approach is for the Relying Party to alert the user when a new</td><td> </td><td class="right">   approach is for the Relying Party to alert the user when a new</td><td class="lineno"></td></tr>
      <tr id="diff0054"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   successor key is seen, and also when the relevant acceptance timer</td><td> </td><td class="rblock">   successor <span class="insert">public</span> key is seen, and also when the relevant acceptance</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   has expired.  The user can then manually transition to the new TA key</td><td> </td><td class="rblock">   timer has expired.  The user can then manually transition to the new</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   data.  This process ensures that the benefits of the acceptance timer</td><td> </td><td class="rblock">   TA <span class="insert">public</span> key data.  This process ensures that the benefits of the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   period are still realised, as compared with TA key update based on a</td><td> </td><td class="rblock">   acceptance timer period are still realised, as compared with TA</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   TAL distributed out-of-band by a TA.</td><td> </td><td class="rblock">   <span class="insert">public</span> key update based on a TAL distributed out-of-band by a TA.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0055"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">6.  Maintaining Multiple TA Keys</td><td> </td><td class="rblock">6.  Maintaining Multiple TA Key<span class="insert"> Pair</span>s</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Although an RP that can process TAK objects will only ever use one</td><td> </td><td class="right">   Although an RP that can process TAK objects will only ever use one</td><td class="lineno"></td></tr>
      <tr id="diff0056"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   key for validation (either the current key, or the successor key,</td><td> </td><td class="rblock">   <span class="insert">public</span> key for validation (either the current <span class="insert">public</span> key, or the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   once the relevant acceptance timer has expired), an RP that cannot</td><td> </td><td class="rblock">   successor <span class="insert">public</span> key, once the relevant acceptance timer has</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   process TAK objects will continue to use the key details per its TAL</td><td> </td><td class="rblock">   expired), an RP that cannot process TAK objects will continue to use</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   (or equivalent manual configuration) indefinitely.  As a result, even</td><td> </td><td class="rblock">   the <span class="insert">public</span> key details per its TAL (or equivalent manual</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   when a TA is using a TAK object in order to migrate clients to a new</td><td> </td><td class="rblock">   configuration) indefinitely.  As a result, even when a TA is using a</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   key, the TA may have to maintain the previous key for a period of</td><td> </td><td class="rblock">   TAK object in order to migrate clients to a new <span class="insert">public</span> key, the TA</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   time alongside the new key in order to ensure continuity of service</td><td> </td><td class="rblock">   may have to maintain the previous key <span class="insert">pair</span> for a period of time</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   alongside the new key <span class="insert">pair</span> in order to ensure continuity of service</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   for older clients.</td><td> </td><td class="right">   for older clients.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0057"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   For each TA key that a TA maintains, the signed material for these</td><td> </td><td class="rblock">   For each TA key <span class="insert">pair</span> that a TA maintains, the signed material for</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   <span class="delete">keys</span> MUST be published under different directories in the context of</td><td> </td><td class="rblock">   these <span class="insert">key pairs</span> MUST be published under different directories in the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   the 'id-ad-caRepository' and 'id-ad-rpkiManifest' Subject Information</td><td> </td><td class="rblock">   context of the 'id-ad-caRepository' and 'id-ad-rpkiManifest' Subject</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   Access descriptions contained on the CA certificates [RFC6487].</td><td> </td><td class="rblock">   Information Access descriptions contained on the CA certificates</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   Publishing objects under the same directory is potentially confusing</td><td> </td><td class="rblock">   [RFC6487].  Publishing objects under the same directory is</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   for RPs, and could lead to object invalidity in the event of file</td><td> </td><td class="rblock">   potentially confusing for RPs, and could lead to object invalidity in</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   name collisions.</td><td> </td><td class="rblock">   the event of file name collisions.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0058"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   Also, the CA certificates for each maintained <span class="delete">key,</span> and the <span class="delete">contents</span></td><td> </td><td class="rblock">   Also, the CA certificates for each maintained <span class="insert">key pair,</span> and the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   published <span class="delete">by</span> each <span class="delete">key,</span> MUST be equivalent (except for the TAK</td><td> </td><td class="rblock">   <span class="insert">content</span> published <span class="insert">for</span> each <span class="insert">key pair,</span> MUST be equivalent (except for</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   object).  In other words, for the purposes of RPKI validation, it</td><td> </td><td class="rblock">   the TAK object).  In other words, for the purposes of RPKI</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   MUST NOT make a difference which of the keys is used as a starting</td><td> </td><td class="rblock">   validation, it MUST NOT make a difference which of the <span class="insert">public</span> keys is</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   point.</td><td> </td><td class="rblock">   used as a starting point.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   This means that the IP and Autonomous System (AS) resources contained</td><td> </td><td class="right">   This means that the IP and Autonomous System (AS) resources contained</td><td class="lineno"></td></tr>
      <tr id="diff0059"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   on all current CA certificates for the maintained TA <span class="delete">keys</span> MUST be the</td><td> </td><td class="rblock">   on all current CA certificates for the maintained TA <span class="insert">key pairs</span> MUST</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   same.  Furthermore, for any delegation of IP and AS resources to a</td><td> </td><td class="rblock">   be the same.  Furthermore, for any delegation of IP and AS resources</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   child, the TA MUST have an equivalent CA certificate published under</td><td> </td><td class="rblock">   to a child, the TA MUST have an equivalent CA certificate published</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   each of its <span class="delete">keys.</span>  Any updates in delegations MUST be reflected under</td><td> </td><td class="rblock">   under each of its <span class="insert">key pairs.</span>  Any updates in delegations MUST be</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   each of its <span class="delete">keys.</span>  A TA SHOULD NOT publish any other objects besides</td><td> </td><td class="rblock">   reflected under each of its <span class="insert">key pairs.</span>  A TA SHOULD NOT publish any</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   a CRL, a Manifest, a single TAK object, and any number of CA</td><td> </td><td class="rblock">   other objects besides a CRL, a Manifest, a single TAK object, and any</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   certificates for delegation to child CAs.</td><td> </td><td class="rblock">   number of CA certificates for delegation to child CAs.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0060"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   If a TA uses a single remote publication server for its <span class="delete">keys,</span> per</td><td> </td><td class="rblock">   If a TA uses a single remote publication server for its <span class="insert">key pairs,</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   [RFC8181], then it MUST include all &lt;publish/&gt; and &lt;withdraw/&gt;</td><td> </td><td class="rblock">   per [RFC8181], then it MUST include all &lt;publish/&gt; and &lt;withdraw/&gt;</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   Protocol Data Units (PDUs) for the products of each of its <span class="delete">keys</span> in a</td><td> </td><td class="rblock">   Protocol Data Units (PDUs) for the products of each of its <span class="insert">key pairs</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   single query, in order to <span class="delete">ensure that they will reflect</span> the <span class="delete">same</span></td><td> </td><td class="rblock">   in a single query, in order to <span class="insert">reduce</span> the <span class="insert">risk of RPs seeing</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">   content at all times.</span></td><td> </td><td class="rblock"><span class="insert">   inconsistent data in the TA's RPKI repositories.</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   If a TA uses multiple publication servers, then the content for</td><td> </td><td class="right">   If a TA uses multiple publication servers, then the content for</td><td class="lineno"></td></tr>
      <tr id="diff0061"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   different <span class="delete">keys</span> will be out of sync at times.  The TA SHOULD ensure</td><td> </td><td class="rblock">   different <span class="insert">key pairs</span> will be out of sync at times.  The TA SHOULD</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   that the duration of these moments is limited to the shortest</td><td> </td><td class="rblock">   ensure that the duration of these moments is limited to the shortest</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   possible time.  Furthermore, the following should be observed:</td><td> </td><td class="right">   possible time.  Furthermore, the following should be observed:</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  In cases where a CA certificate is revoked, or replaced by a</td><td> </td><td class="right">   *  In cases where a CA certificate is revoked, or replaced by a</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      certificate with a reduced set of resources, these changes will</td><td> </td><td class="right">      certificate with a reduced set of resources, these changes will</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      not take effect fully until all the relevant repository</td><td> </td><td class="right">      not take effect fully until all the relevant repository</td><td class="lineno"></td></tr>
      <tr id="diff0062"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">      publication points have been updated.  Given that TA key</td><td> </td><td class="rblock">      publication points have been updated.  Given that TA <span class="insert">private </span>key</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      operations are normally performed infrequently, this is unlikely</td><td> </td><td class="right">      operations are normally performed infrequently, this is unlikely</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      to be a problem: if the revocation or shrinking of an issued CA</td><td> </td><td class="right">      to be a problem: if the revocation or shrinking of an issued CA</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      certificate is staged for days/weeks, then experiencing a delay of</td><td> </td><td class="right">      certificate is staged for days/weeks, then experiencing a delay of</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      several minutes for the repository publication points to be</td><td> </td><td class="right">      several minutes for the repository publication points to be</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      updated is relatively insignificant.</td><td> </td><td class="right">      updated is relatively insignificant.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  In cases where a CA certificate is replaced by a certificate with</td><td> </td><td class="right">   *  In cases where a CA certificate is replaced by a certificate with</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      an extended set of resources, the TA MUST inform the receiving CA</td><td> </td><td class="right">      an extended set of resources, the TA MUST inform the receiving CA</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      only after all of its repository publication points have been</td><td> </td><td class="right">      only after all of its repository publication points have been</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      updated.  This ensures that the receiving CA will not issue any</td><td> </td><td class="right">      updated.  This ensures that the receiving CA will not issue any</td><td class="lineno"></td></tr>
      <tr id="diff0063"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">      products that could be invalid if an RP uses a TA key just before</td><td> </td><td class="rblock">      products that could be invalid if an RP uses a TA <span class="insert">public</span> key just</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">      the CA certificate was due to be updated.</td><td> </td><td class="rblock">      before the CA certificate was due to be updated.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Finally, note that the publication locations of CA certificates for</td><td> </td><td class="right">   Finally, note that the publication locations of CA certificates for</td><td class="lineno"></td></tr>
      <tr id="diff0064"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   delegations to child CAs under each key will be different, and</td><td> </td><td class="rblock">   delegations to child CAs under each key <span class="insert">pair </span>will be different, and</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   therefore the Authority Information Access 'id-ad-caIssuers' values</td><td> </td><td class="right">   therefore the Authority Information Access 'id-ad-caIssuers' values</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   (section 4.8.7 of [RFC6487]) on certificates issued by the child CAs</td><td> </td><td class="right">   (section 4.8.7 of [RFC6487]) on certificates issued by the child CAs</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   may not be as expected when performing top-down validation, depending</td><td> </td><td class="right">   may not be as expected when performing top-down validation, depending</td><td class="lineno"></td></tr>
      <tr id="diff0065"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   on the TA key that is used.  However, these values are not critical</td><td> </td><td class="rblock">   on the TA <span class="insert">public</span> key that is used.  However, these values are not</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   to top-down validation, so RPs performing such validation MUST NOT</td><td> </td><td class="rblock">   critical to top-down validation, so RPs performing such validation</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   reject a certificate simply because this value is not as expected.</td><td> </td><td class="rblock">   MUST NOT reject a certificate simply because this value is not as</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   expected.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">7.  Performing TA Key Rolls</td><td> </td><td class="right">7.  Performing TA Key Rolls</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   In this section we describe how present-day RPKI TAs that use only</td><td> </td><td class="right">   In this section we describe how present-day RPKI TAs that use only</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   one key pair, and that do not use TAK objects, can use a TAK object</td><td> </td><td class="right">   one key pair, and that do not use TAK objects, can use a TAK object</td><td class="lineno"></td></tr>
      <tr id="diff0066"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   to perform a planned key roll.</td><td> </td><td class="rblock">   to perform a planned key roll<span class="insert">over</span>.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0067"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">7.1.  Phase 1: Add a TAK for Key 'A'</td><td> </td><td class="rblock">7.1.  Phase 1: Add a TAK for Key <span class="insert">Pair </span>'A'</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0068"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   Before adding a successor key, a TA may want to confirm that it can</td><td> </td><td class="rblock">   Before adding a successor <span class="insert">public</span> key, a TA may want to confirm that</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   maintain a TAK object for its current key only.  We will refer to</td><td> </td><td class="rblock">   it can maintain a TAK object for its current key <span class="insert">pair</span> only.  We will</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   this key as key 'A' throughout this section.</td><td> </td><td class="rblock">   refer to this key <span class="insert">pair</span> as key <span class="insert">pair</span> 'A' throughout this section.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0069"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">7.2.  Phase 2: Add a Key 'B'</td><td> </td><td class="rblock">7.2.  Phase 2: Add a Key <span class="insert">Pair </span>'B'</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0070"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   The TA can now generate a new key <span class="delete">pair for key</span> 'B'.  <span class="delete">This</span> key MUST</td><td> </td><td class="rblock">   The TA can now generate a new key <span class="insert">pair, called</span> 'B'.  <span class="insert">The private</span> key</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   now be used to create a new CA certificate for <span class="delete">this</span> key, and to issue</td><td> </td><td class="rblock">   <span class="insert">of this key pair</span> MUST now be used to create a new CA certificate for</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   equivalent CA certificates for delegations to child CAs, as described</td><td> </td><td class="rblock">   <span class="insert">the associated public</span> key, and to issue equivalent CA certificates</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   in Section 6.</td><td> </td><td class="rblock">   for delegations to child CAs, as described in Section 6.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   At this point, the TA can also construct a new TAL file [RFC8630] for</td><td> </td><td class="right">   At this point, the TA can also construct a new TAL file [RFC8630] for</td><td class="lineno"></td></tr>
      <tr id="diff0071"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   key 'B', and test locally that the validation outcome for the new key</td><td> </td><td class="rblock">   <span class="insert">the public key of</span> key <span class="insert">pair</span> 'B', and test locally that the validation</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   is equivalent to that of the other current key(s).</td><td> </td><td class="rblock">   outcome for the new <span class="insert">public</span> key is equivalent to that of the other</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   current <span class="insert">public</span> key(s).</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0072"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   When the TA is certain that both keys <span class="delete">are</span> equivalent, and wants to</td><td> </td><td class="rblock">   When the TA is certain that <span class="insert">the content for</span> both <span class="insert">public</span> keys <span class="insert">is</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   initiate the migration from 'A' to 'B', it issues a new TAK object</td><td> </td><td class="rblock">   equivalent, and wants to initiate the migration from 'A' to 'B', it</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   under key 'A', with key <span class="delete">'A'</span> as the current key for that object, key</td><td> </td><td class="rblock">   issues a new TAK object under key <span class="insert">pair</span> 'A', with <span class="insert">the public</span> key <span class="insert">from</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   'B' as the successor key, and no predecessor key.  It also issues a</td><td> </td><td class="rblock"><span class="insert">   that key pair</span> as the current <span class="insert">public</span> key for that object, <span class="insert">the public</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   TAK object under key 'B', with key <span class="delete">'B'</span> as the current key for that</td><td> </td><td class="rblock"><span class="insert">   key from</span> key <span class="insert">pair</span> 'B' as the successor <span class="insert">public</span> key, and no predecessor</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   object, key 'A' as the predecessor key, and no successor key.</td><td> </td><td class="rblock">   <span class="insert">public</span> key.  It also issues a TAK object under key <span class="insert">pair</span> 'B', with <span class="insert">the</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   public</span> key <span class="insert">from that key pair</span> as the current <span class="insert">public</span> key for that</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   object, <span class="insert">the public key from</span> key <span class="insert">pair</span> 'A' as the predecessor <span class="insert">public</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   key, and no successor <span class="insert">public</span> key.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0073"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   Once this has happened, RP clients will start seeing the new key and</td><td> </td><td class="rblock">   Once this has happened, RP clients will start seeing the new <span class="insert">public</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   setting acceptance timers accordingly.</td><td> </td><td class="rblock">   key and setting acceptance timers accordingly.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">7.3.  Phase 3: Update TAL to point to 'B'</td><td> </td><td class="right">7.3.  Phase 3: Update TAL to point to 'B'</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0074"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   At about the time that the TA expects clients to start setting key</td><td> </td><td class="rblock">   At about the time that the TA expects clients to start setting <span class="insert">the</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   'B' as the current key, the TA must release a new TAL file for <span class="delete">key</span></td><td> </td><td class="rblock"><span class="insert">   public key from</span> key <span class="insert">pair</span> 'B' as the current <span class="insert">public</span> key, the TA must</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">   'B'.</span>  It SHOULD use a different set of URIs in the TAL compared to</td><td> </td><td class="rblock">   release a new TAL file for <span class="insert">that public key.</span>  It SHOULD use a</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   the TAK file, so that the TA can learn the proportion of RPs that can</td><td> </td><td class="rblock">   different set of URIs in the TAL compared to the TAK file, so that</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   successfully validate and use the updated TAK objects.</td><td> </td><td class="rblock">   the TA can learn the proportion of RPs that can successfully validate</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   and use the updated TAK objects.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   To support RPs that do not take account of TAK objects, the TA should</td><td> </td><td class="right">   To support RPs that do not take account of TAK objects, the TA should</td><td class="lineno"></td></tr>
      <tr id="diff0075"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   continue operating key 'A' for a period of time after the expected</td><td> </td><td class="rblock">   continue operating key <span class="insert">pair</span> 'A' for a period of time after the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   migration of clients to 'B'.  The length of that period of time is a</td><td> </td><td class="rblock">   expected migration of clients to <span class="insert">the public key from</span> 'B'.  The length</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   local policy matter for that TA: it might operate the key until no</td><td> </td><td class="rblock">   of that period of time is a local policy matter for that TA: it might</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   clients are attempting to validate using <span class="delete">it,</span> for example.</td><td> </td><td class="rblock">   operate the key <span class="insert">pair</span> until no clients are attempting to validate</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   using <span class="insert">the associated public key,</span> for example.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0076"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">7.4.  Phase 4: Remove Key 'A'</td><td> </td><td class="rblock">7.4.  Phase 4: Remove Key <span class="insert">Pair </span>'A'</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   The TA SHOULD now remove all content from the repository used by key</td><td> </td><td class="right">   The TA SHOULD now remove all content from the repository used by key</td><td class="lineno"></td></tr>
      <tr id="diff0077"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   'A', and destroy the private key for key <span class="delete">'A'.</span>  RPs attempting to rely</td><td> </td><td class="rblock">   <span class="insert">pair</span> 'A', and destroy the private key for <span class="insert">that</span> key <span class="insert">pair.</span>  RPs</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   on a TAL for key 'A' from this point will not be able to perform RPKI</td><td> </td><td class="rblock">   attempting to rely on a TAL for <span class="insert">the public key from</span> key <span class="insert">pair</span> 'A' from</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   validation for the TA, and will have to update their local state</td><td> </td><td class="rblock">   this point will not be able to perform RPKI validation for the TA,</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   manually, by way of a new TAL file.</td><td> </td><td class="rblock">   and will have to update their local state manually, by way of a new</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   TAL file.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">8.  Using TAK objects to distribute TAL data</td><td> </td><td class="right">8.  Using TAK objects to distribute TAL data</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Relying Parties must be configured with RPKI Trust Anchor data in</td><td> </td><td class="right">   Relying Parties must be configured with RPKI Trust Anchor data in</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   order to function correctly.  This Trust Anchor data is typically</td><td> </td><td class="right">   order to function correctly.  This Trust Anchor data is typically</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   distributed in the Trust Anchor Locator (TAL) format defined in RFC</td><td> </td><td class="right">   distributed in the Trust Anchor Locator (TAL) format defined in RFC</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   8630.  A TAK object can also serve as a format for distribution of</td><td> </td><td class="right">   8630.  A TAK object can also serve as a format for distribution of</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   this data, though, because the TAKey data stored in the TAK object</td><td> </td><td class="right">   this data, though, because the TAKey data stored in the TAK object</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   contains the same data that would appear in a TAL for the associated</td><td> </td><td class="right">   contains the same data that would appear in a TAL for the associated</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Trust Anchor.</td><td> </td><td class="right">   Trust Anchor.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="part-6" class="change" ><td></td><th><small>skipping to change at</small><a href="#part-6"><em> page 13, line 37<span class="hide"> &para;</span></em></a></th><th> </th><th><small>skipping to change at</small><a href="#part-6"><em> page 13, line 31<span class="hide"> &para;</span></em></a></th><td></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">9.1.  Relying Party Support</td><td> </td><td class="right">9.1.  Relying Party Support</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Publishing TAK objects while RPs do not support this standard will</td><td> </td><td class="right">   Publishing TAK objects while RPs do not support this standard will</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   result in those RPs rejecting these objects.  It is not expected that</td><td> </td><td class="right">   result in those RPs rejecting these objects.  It is not expected that</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   this will result in the invalidation of any other object under a</td><td> </td><td class="right">   this will result in the invalidation of any other object under a</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Trust Anchor.</td><td> </td><td class="right">   Trust Anchor.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Some RPs may purposefully not support this mechanism: for example,</td><td> </td><td class="right">   Some RPs may purposefully not support this mechanism: for example,</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   they may be implemented or configured such that they are unable to</td><td> </td><td class="right">   they may be implemented or configured such that they are unable to</td><td class="lineno"></td></tr>
      <tr id="diff0078"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   update local current key data.  <span class="delete">TAs</span> should take this into</td><td> </td><td class="rblock">   update local current <span class="insert">public</span> key data.  <span class="insert">TA operators</span> should take this</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   consideration when planning key rollover.  However, these RPs would</td><td> </td><td class="rblock">   into consideration when planning key rollover.  However, these RPs</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   ideally still notify their operators of planned key rollovers, so</td><td> </td><td class="rblock">   would ideally still notify their operators of planned key rollovers,</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   that the operator could update the relevant configuration manually.</td><td> </td><td class="rblock">   so that the operator could update the relevant configuration</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   manually.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">9.2.  Alternate Transition Models</td><td> </td><td class="right">9.2.  Alternate Transition Models</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Alternate models of TAL update exist and are complementary to this</td><td> </td><td class="right">   Alternate models of TAL update exist and are complementary to this</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   mechanism.  For example, TAs can liaise directly with RP software</td><td> </td><td class="right">   mechanism.  For example, TAs can liaise directly with RP software</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   developers to include updated and reissued TAL files in new code</td><td> </td><td class="right">   developers to include updated and reissued TAL files in new code</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   releases, and use existing code update mechanisms in the RP community</td><td> </td><td class="right">   releases, and use existing code update mechanisms in the RP community</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   to distribute the changes.</td><td> </td><td class="right">   to distribute the changes.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Additionally, these non-TA channels for distributing TAL data may</td><td> </td><td class="right">   Additionally, these non-TA channels for distributing TAL data may</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   themselves rely on monitoring for TAK objects and then updating the</td><td> </td><td class="right">   themselves rely on monitoring for TAK objects and then updating the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   TAL data in their distributions or packages accordingly.  In this</td><td> </td><td class="right">   TAL data in their distributions or packages accordingly.  In this</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   way, TAK objects may be useful even for RPs that don't implement in-</td><td> </td><td class="right">   way, TAK objects may be useful even for RPs that don't implement in-</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   band support for the protocol.</td><td> </td><td class="right">   band support for the protocol.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Non-TA channels for distributing TAL data should ensure, so far as is</td><td> </td><td class="right">   Non-TA channels for distributing TAL data should ensure, so far as is</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   possible, that their update mechanisms take account of any changes</td><td> </td><td class="right">   possible, that their update mechanisms take account of any changes</td><td class="lineno"></td></tr>
      <tr id="diff0079"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   that a user has made to their local TA key configuration.  For</td><td> </td><td class="rblock">   that a user has made to their local TA <span class="insert">public</span> key configuration.  For</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   example, if a new key is published for a TA, but the non-TA channel's</td><td> </td><td class="rblock">   example, if a new <span class="insert">public</span> key is published for a TA, but the non-TA</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   mechanism is able to detect that a user had removed the TA's previous</td><td> </td><td class="rblock">   channel's mechanism is able to detect that a user had removed the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   key from their local TA key configuration such that the user no</td><td> </td><td class="rblock">   TA's previous <span class="insert">public</span> key from their local TA <span class="insert">public</span> key configuration</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   longer relies on it, then the mechanism should not by default add the</td><td> </td><td class="rblock">   such that the user no longer relies on it, then the mechanism should</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   new key to the user's TA key configuration.</td><td> </td><td class="rblock">   not by default add the new <span class="insert">public</span> key to the user's TA <span class="insert">public</span> key</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   configuration.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">10.  Operational Considerations</td><td> </td><td class="right">10.  Operational Considerations</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">10.1.  Acceptance Timers</td><td> </td><td class="right">10.1.  Acceptance Timers</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Acceptance timers are used in TAK objects in order to permit RPs to</td><td> </td><td class="right">   Acceptance timers are used in TAK objects in order to permit RPs to</td><td class="lineno"></td></tr>
      <tr id="diff0080"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   test that the new key is working correctly.  This in turn means that</td><td> </td><td class="rblock">   test that the new <span class="insert">public</span> key is working correctly.  This in turn</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   the TA will be able to gain confidence in the correct functioning of</td><td> </td><td class="rblock">   means that the TA <span class="insert">operator</span> will be able to gain confidence in the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   the new key before RPs are relying on that in their production RPKI</td><td> </td><td class="rblock">   correct functioning of the new <span class="insert">public</span> key before RPs are relying on</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   operations.  If a successor key is not working correctly, a TA may</td><td> </td><td class="rblock">   that in their production RPKI operations.  If a successor <span class="insert">public</span> key</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   remove that key from the current TAK object.</td><td> </td><td class="rblock">   is not working correctly, a TA may remove that <span class="insert">public</span> key from the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   current TAK object.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0081"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   A TA that removes a successor key from a TAK object SHOULD NOT add</td><td> </td><td class="rblock">   A TA that removes a successor <span class="insert">public</span> key from a TAK object SHOULD NOT</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   the same successor key back into the TAK object for that TA.  This is</td><td> </td><td class="rblock">   add the same successor <span class="insert">public</span> key back into the TAK object for that</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   because there may be an RP that has fetched the TAK object while the</td><td> </td><td class="rblock">   TA.  This is because there may be an RP that has fetched the TAK</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   successor key was listed in it, and has started an acceptance timer</td><td> </td><td class="rblock">   object while the successor <span class="insert">public</span> key was listed in it, and has</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   accordingly, but has not fetched the TAK object during the period</td><td> </td><td class="rblock">   started an acceptance timer accordingly, but has not fetched the TAK</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   when the successor key was not listed in it.  If the unchanged</td><td> </td><td class="rblock">   object during the period when the successor <span class="insert">public</span> key was not listed</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   successor key is added back into the TA, such an RP will transition</td><td> </td><td class="rblock">   in it.  If the unchanged successor <span class="insert">public</span> key is added back into the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   to using the new TA key more quickly than other RPs, which may, in</td><td> </td><td class="rblock">   TA, such an RP will transition to using the new TA <span class="insert">public</span> key more</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   turn, make debugging and similar more complicated.  A simple way of</td><td> </td><td class="rblock">   quickly than other RPs, which may, in turn, make debugging and</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   addressing this problem in a situation where the TA doesn't want to</td><td> </td><td class="rblock">   similar more complicated.  A simple way of addressing this problem in</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   reissue the SubjectPublicKeyInfo content for the successor key that</td><td> </td><td class="rblock">   a situation where the TA <span class="insert">operator</span> doesn't want to reissue the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   was withdrawn is to update the URL set for the successor key, since</td><td> </td><td class="rblock">   SubjectPublicKeyInfo content for the successor <span class="insert">public</span> key that was</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   RPs must take that URL set into account for the purposes of</td><td> </td><td class="rblock">   withdrawn is to update the URL set for the successor <span class="insert">public</span> key,</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   since RPs must take that URL set into account for the purposes of</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   initiating and cancelling acceptance timers.</td><td> </td><td class="right">   initiating and cancelling acceptance timers.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">11.  Security Considerations</td><td> </td><td class="right">11.  Security Considerations</td><td class="lineno"></td></tr>
      <tr id="diff0082"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">                                                                         </span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">11.1.  Previous Keys</td><td> </td><td class="right">11.1.  Previous Keys</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   A TA needs to consider the length of time for which it will maintain</td><td> </td><td class="right">   A TA needs to consider the length of time for which it will maintain</td><td class="lineno"></td></tr>
      <tr id="diff0083"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   previously-current <span class="delete">keys</span> and their associated repositories.  An RP</td><td> </td><td class="rblock">   previously-current <span class="insert">key pairs</span> and their associated repositories.  An</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   that is seeded with old TAL data will run for 30 days using the</td><td> </td><td class="rblock">   RP that is seeded with old TAL data will run for 30 days using the</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   previous key before migrating to the next key, due to the acceptance</td><td> </td><td class="rblock">   previous <span class="insert">public</span> key before migrating to the next <span class="insert">public</span> key, due to</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   timer requirements, and this 30-day delay applies to each new key</td><td> </td><td class="rblock">   the acceptance timer requirements, and this 30-day delay applies to</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   that has been issued since the old TAL data was initially published.</td><td> </td><td class="rblock">   each new key <span class="insert">pair</span> that has been issued since the old TAL data was</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   It may be better in these instances to <span class="delete">have</span> the old publication <span class="delete">URLs</span></td><td> </td><td class="rblock">   initially published.  It may be better in these instances <span class="insert">for the TA</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">   simply fail to resolve,</span> so that the RP reports an error to its</td><td> </td><td class="rblock">   to <span class="insert">send error responses when receiving requests for</span> the old</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   operator and the operator seeds it with up-to-date TAL data</td><td> </td><td class="rblock">   publication <span class="insert">URLs,</span> so that the RP reports an error to its operator and</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   immediately.</td><td> </td><td class="rblock">   the operator seeds it with up-to-date TAL data immediately.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0084"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   Once a TA has decided not to maintain a previously-current key and</td><td> </td><td class="rblock">   Once a TA has decided not to maintain a previously-current key <span class="insert">pair</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   its associated repository, the TA SHOULD destroy <span class="delete">that</span> key.  The TA</td><td> </td><td class="rblock">   and its associated repository, the TA SHOULD destroy <span class="insert">the associated</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   SHOULD also reuse the TA CA certificate URLs from the previous TAL</td><td> </td><td class="rblock"><span class="insert">   private</span> key.  The TA SHOULD also reuse the TA CA certificate URLs</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   data for the next TAL that it generates.  These measures will help to</td><td> </td><td class="rblock">   from the previous TAL data for the next TAL that it generates.  These</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   mitigate the risk of an adversary gaining access to the key and its</td><td> </td><td class="rblock">   measures will help to mitigate the risk of an adversary gaining</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   associated publication points in order to send invalid/incorrect data</td><td> </td><td class="rblock">   access to the <span class="insert">private</span> key and its associated publication points in</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   to RPs seeded with the TAL data for <span class="delete">that</span> key.</td><td> </td><td class="rblock">   order to send invalid/incorrect data to RPs seeded with the TAL data</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   for <span class="insert">the corresponding public</span> key.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">11.2.  TA Compromise</td><td> </td><td class="right">11.2.  TA Compromise</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   TAK objects do not offer protection against compromise of the current</td><td> </td><td class="right">   TAK objects do not offer protection against compromise of the current</td><td class="lineno"></td></tr>
      <tr id="diff0085"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   TA key or the successor TA key.  TA key compromise in general is out</td><td> </td><td class="rblock">   TA <span class="insert">private</span> key or the successor TA <span class="insert">private</span> key.  TA <span class="insert">private</span> key</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   of scope for this document.</td><td> </td><td class="rblock">   compromise in general is out of scope for this document.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0086"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock"><span class="delete">12.  IANA Considerations</span></td><td> </td><td class="rblock">   <span class="insert">While it is possible for a malicious actor to use TAK objects to</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   cause RPs to transition from the current TA public key to a successor</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   TA public key, such action is predicated on the malicious actor</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   having compromised the current TA private key in the first place, so</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   TAK objects do not alter the security considerations relevant to this</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   scenario.</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"></span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">11.3.  Alternate Transition Models</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0087"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   <span class="insert">Section 9.2 describes other ways in which a TA may transition from</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   one key pair to another.  Transition by way of an in-band process</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   reliant on TAK objects is not mandatory for TAs or RPs, though the</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   fact that the TAK objects are verifiable by way of the currently-</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   trusted TA public key is a benefit compared with existing out-of-band</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   mechanisms for TA public key distribution.</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"></span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   There will be a period of time where both the current public key and</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   the successor public key are available for use, and RPs that are</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   initialised at different points of the transition process, or from</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   different out-of-band sources, may be using either the current public</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   key or the successor public key.  TAs are required to ensure so far</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   as is possible that for the purposes of RPKI validation, it makes no</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">   difference which public key is used.</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert"></span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock"><span class="insert">12.  IANA Considerations</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">12.1.  Content Type</td><td> </td><td class="right">12.1.  Content Type</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   IANA is asked to register an object identifier for one content type</td><td> </td><td class="right">   IANA is asked to register an object identifier for one content type</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   in the "SMI Security for S/MIME CMS Content Type</td><td> </td><td class="right">   in the "SMI Security for S/MIME CMS Content Type</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   (1.2.840.113549.1.9.16.1)" registry as follows:</td><td> </td><td class="right">   (1.2.840.113549.1.9.16.1)" registry as follows:</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">          Decimal | Description                    | References</td><td> </td><td class="right">          Decimal | Description                    | References</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">          --------+--------------------------------+---------------</td><td> </td><td class="right">          --------+--------------------------------+---------------</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">          50      | id-ct-signedTAL                | [section 3.1]</td><td> </td><td class="right">          50      | id-ct-signedTAL                | [section 3.1]</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="part-7" class="change" ><td></td><th><small>skipping to change at</small><a href="#part-7"><em> page 16, line 24<span class="hide"> &para;</span></em></a></th><th> </th><th><small>skipping to change at</small><a href="#part-7"><em> page 16, line 39<span class="hide"> &para;</span></em></a></th><td></td></tr>
      <tr><td class="lineno"></td><td class="left">   IANA is also asked to add the following note to the "RPKI Signed</td><td> </td><td class="right">   IANA is also asked to add the following note to the "RPKI Signed</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Objects" registry:</td><td> </td><td class="right">   Objects" registry:</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   |  Objects of the types listed in this registry, as well as RPKI</td><td> </td><td class="right">   |  Objects of the types listed in this registry, as well as RPKI</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   |  resource certificates and CRLs, are expected to be validated using</td><td> </td><td class="right">   |  resource certificates and CRLs, are expected to be validated using</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   |  the RPKI.</td><td> </td><td class="right">   |  the RPKI.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">12.3.  File Extension</td><td> </td><td class="right">12.3.  File Extension</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   IANA is asked to add an item for the Signed TAL file extension to the</td><td> </td><td class="right">   IANA is asked to add an item for the Signed TAL file extension to the</td><td class="lineno"></td></tr>
      <tr id="diff0088"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">   "RPKI Repository Name Scheme" created by [RFC6481] as follows:</td><td> </td><td class="rblock">   "RPKI Repository Name Scheme<span class="insert">s</span>" created by [RFC6481] as follows:</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">       Filename Extension  | RPKI Object              | Reference</td><td> </td><td class="right">       Filename Extension  | RPKI Object              | Reference</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">       --------------------+--------------------------+----------------</td><td> </td><td class="right">       --------------------+--------------------------+----------------</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">        .tak               | Trust Anchor Key         | [this document]</td><td> </td><td class="right">        .tak               | Trust Anchor Key         | [this document]</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">12.4.  Module Identifier</td><td> </td><td class="right">12.4.  Module Identifier</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   IANA is asked to register an object identifier for one module</td><td> </td><td class="right">   IANA is asked to register an object identifier for one module</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   identifier in the "SMI Security for S/MIME Module Identifier</td><td> </td><td class="right">   identifier in the "SMI Security for S/MIME Module Identifier</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   (1.2.840.113549.1.9.16.0)" registry as follows:</td><td> </td><td class="right">   (1.2.840.113549.1.9.16.0)" registry as follows:</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="part-8" class="change" ><td></td><th><small>skipping to change at</small><a href="#part-8"><em> page 18, line 36<span class="hide"> &para;</span></em></a></th><th> </th><th><small>skipping to change at</small><a href="#part-8"><em> page 19, line 6<span class="hide"> &para;</span></em></a></th><td></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  Responsible Organization: Asia-Pacific Network Information Centre</td><td> </td><td class="right">   *  Responsible Organization: Asia-Pacific Network Information Centre</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  Location: https://github.com/APNIC-net/rpki-signed-tal-demo</td><td> </td><td class="right">   *  Location: https://github.com/APNIC-net/rpki-signed-tal-demo</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  Description: A proof-of-concept for relying party TAK usage.</td><td> </td><td class="right">   *  Description: A proof-of-concept for relying party TAK usage.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  Level of Maturity: This is a proof-of-concept implementation.</td><td> </td><td class="right">   *  Level of Maturity: This is a proof-of-concept implementation.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  Coverage: This implementation includes all of the features</td><td> </td><td class="right">   *  Coverage: This implementation includes all of the features</td><td class="lineno"></td></tr>
      <tr id="diff0089"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock">      described in version 1<span class="delete">5</span> of this specification, except for writing</td><td> </td><td class="rblock">      described in version 1<span class="insert">6</span> of this specification, except for writing</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      TAL files based on TAK data.  The repository includes a link to</td><td> </td><td class="right">      TAL files based on TAK data.  The repository includes a link to</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">      various test TALs that can be used for testing TAK scenarios, too.</td><td> </td><td class="right">      various test TALs that can be used for testing TAK scenarios, too.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  Contact Information: Tom Harrison, tomh@apnic.net</td><td> </td><td class="right">   *  Contact Information: Tom Harrison, tomh@apnic.net</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">13.2.  rpki-client</td><td> </td><td class="right">13.2.  rpki-client</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  Responsible Organization: Job Snijders, the OpenBSD project</td><td> </td><td class="right">   *  Responsible Organization: Job Snijders, the OpenBSD project</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   *  Location: https://www.rpki-client.org</td><td> </td><td class="right">   *  Location: https://www.rpki-client.org</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="part-9" class="change" ><td></td><th><small>skipping to change at</small><a href="#part-9"><em> page 20, line 15<span class="hide"> &para;</span></em></a></th><th> </th><th><small>skipping to change at</small><a href="#part-9"><em> page 20, line 30<span class="hide"> &para;</span></em></a></th><td></td></tr>
      <tr><td class="lineno"></td><td class="left">   12 - TAK object comments.</td><td> </td><td class="right">   12 - TAK object comments.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   13 - Removal of compromise text, extra RP support text, key</td><td> </td><td class="right">   13 - Removal of compromise text, extra RP support text, key</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   destruction text, media type registration, signed object registry</td><td> </td><td class="right">   destruction text, media type registration, signed object registry</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   note.</td><td> </td><td class="right">   note.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   14 - Keepalive.</td><td> </td><td class="right">   14 - Keepalive.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   15 - Additional implementation notes and editorial updates.</td><td> </td><td class="right">   15 - Additional implementation notes and editorial updates.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr id="diff0090"><td></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">   <span class="insert">16 - Updates from Secdir and IESG reviews.</span></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="lblock"></td><td> </td><td class="rblock">                                                                         </td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">15.  Acknowledgments</td><td> </td><td class="right">15.  Acknowledgments</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   The authors wish to thank Martin Hoffmann for a thorough review of</td><td> </td><td class="right">   The authors wish to thank Martin Hoffmann for a thorough review of</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   the document, Russ Housley for multiple reviews of the ASN.1</td><td> </td><td class="right">   the document, Russ Housley for multiple reviews of the ASN.1</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   definitions and for providing a new module for the TAK object, Job</td><td> </td><td class="right">   definitions and for providing a new module for the TAK object, Job</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   Snijders for the extensive suggestions around TAK object structure/</td><td> </td><td class="right">   Snijders for the extensive suggestions around TAK object structure/</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   distribution and rpki-client implementation work, and Ties de Kock</td><td> </td><td class="right">   distribution and rpki-client implementation work, and Ties de Kock</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   for text/suggestions around TAK/TAL distribution and general security</td><td> </td><td class="right">   for text/suggestions around TAK/TAL distribution and general security</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left">   considerations.</td><td> </td><td class="right">   considerations.</td><td class="lineno"></td></tr>
      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>

     <tr><td></td><td class="left"></td><td> </td><td class="right"></td><td></td></tr>
     <tr id="end" bgcolor="gray"><th colspan="5" align="center">&nbsp;End of changes. 90 change blocks.&nbsp;</th></tr>
     <tr class="stats"><td></td><th><i>267 lines changed or deleted</i></th><th><i> </i></th><th><i>301 lines changed or added</i></th><td></td></tr>
     <tr><td colspan="5" align="center" class="small"><br/>This html diff was produced by rfcdiff 1.45. The latest version is available from <a href="http://www.tools.ietf.org/tools/rfcdiff/" >http://tools.ietf.org/tools/rfcdiff/</a> </td></tr>
   </table>
   </body>
   </html>

--rQbEyiJe6XyvY2Db--