Skip to main content

RPKI Signed Object for Trust Anchor Key
draft-ietf-sidrops-signed-tal-16

Revision differences

Document history

Date Rev. By Action
2024-07-15
16 Carlos Pignataro Closed request for Last Call review by OPSDIR with state 'Overtaken by Events'
2024-07-15
16 Carlos Pignataro Assignment of request for Last Call review by OPSDIR to Nagendra Nainar was marked no-response
2024-05-30
16 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2024-05-30
16 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2024-05-30
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2024-05-29
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2024-05-27
16 (System) IANA Action state changed to In Progress from Waiting on Authors
2024-05-24
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2024-05-21
16 (System) RFC Editor state changed to EDIT
2024-05-21
16 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2024-05-21
16 (System) Announcement was received by RFC Editor
2024-05-21
16 (System) IANA Action state changed to In Progress
2024-05-21
16 (System) Removed all action holders (IESG state changed)
2024-05-21
16 Jenny Bui IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2024-05-21
16 Jenny Bui IESG has approved the document
2024-05-21
16 Jenny Bui Closed "Approve" ballot
2024-05-21
16 Jenny Bui Ballot approval text was generated
2024-05-21
16 Jenny Bui Ballot writeup was changed
2024-05-16
16 Jean Mahoney Closed request for Last Call review by GENART with state 'Overtaken by Events'
2024-05-16
16 Jean Mahoney Assignment of request for Last Call review by GENART to Matt Joras was marked no-response
2024-05-16
16 Jenny Bui IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation
2024-05-16
16 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2024-05-15
16 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2024-05-15
16 Tom Harrison New version available: draft-ietf-sidrops-signed-tal-16.txt
2024-05-15
16 (System) New version approved
2024-05-15
16 (System) Request for posting confirmation emailed to previous authors: Carlos Martinez , George Michaelson , Rob Austein , Tim Bruijnzeels , Tom Harrison
2024-05-15
16 Tom Harrison Uploaded new revision
2024-05-15
15 Murray Kucherawy [Ballot comment]
For the SHOULD in Section 4, what if I don't?
2024-05-15
15 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2024-05-15
15 Roman Danyliw [Ballot comment]
** Section 12.3.  Editorial.  There is a typo in the official name of the registry: s/Repository Name Scheme/Repository Name Schemes/
2024-05-15
15 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2024-05-15
15 John Scudder
[Ballot comment]
Thanks for the document. I have a few comments, which I hope may be helpful.

### Section 3.2.1.1, octothorpe, equivalence

  This field …
[Ballot comment]
Thanks for the document. I have a few comments, which I hope may be helpful.

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

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.

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

### 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".)
2024-05-15
15 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2024-05-15
15 Paul Wouters
[Ballot comment]
I am not an rPKI expert, so this might be a dumb question. If Key A generates its CA, and then lets its …
[Ballot comment]
I am not an rPKI expert, so this might be a dumb question. If Key A generates its CA, and then lets its CA expire, or the expiration time is smaller than the acceptance window, is there a way to recover from this? The rules seem to say a new Key B cannot be created because it wouldn't be accepted ?
2024-05-15
15 Paul Wouters [Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters
2024-05-14
15 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2024-05-14
15 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2024-05-14
15 Deb Cooley
[Ballot comment]
Thanks to Linda Dunbar for her valuable secdir review.

Nits, or just observations:

General:  This is just me, no action required (I am …
[Ballot comment]
Thanks to Linda Dunbar for her valuable secdir review.

Nits, or just observations:

General:  This is just me, no action required (I am a PKI person, so I am pedantic on occasion).  I find the use of 'key' vice 'public key' to be a bit confusing.  There should be a distinction between 'private keys' and 'public keys' and the generic us of 'key' doesn't do that (in fact, I think most people think of 'key' as synonymous with 'private key').  I gather from reading this draft and poking around at the RPKI RFCs that the use of 'Key' is common terminology, so it would be confusing to change that now.  If there was ever an opportunity to clarify, it would be nice (maybe in the intro, para 2?).

Section 2, para 3:  This is confusing?  "... will first validate the TAK object, if present. ... If the TAK object lists only a current key....continues processing as it would in the absence of a TAK object.... if the TAK object includes a successor key... continues processing as it would in the absence of a TAK object."  Does processing of the TAK object happen elsewhere?  While other processing occurs?  If there is a TAK object, then why do you need the phrase 'continues processing as it would in the absence of a TAK object'? 

Section 7:  Thanks for this.  It wasn't clear to me just how many TAK objects would have to exist to move from a current to successor key.  This section helps clarify.
2024-05-14
15 Deb Cooley [Ballot Position Update] New position, No Objection, has been recorded for Deb Cooley
2024-05-10
15 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2024-05-08
15 Éric Vyncke
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-sidrops-signed-tal-15

Thank you for the work put into this document.

Please find below osome non-blocking COMMENT …
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-sidrops-signed-tal-15

Thank you for the work put into this document.

Please find below osome non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Russ for the shepherd's detailed write-up including the WG consensus *but* it lacks the justification of the intended status and uses the old template.

I hope that this review helps to improve the document,

Regards,

-éric


# COMMENTS (non-blocking)

## Section 3.1

The wording `This document requests an OID for the TAK object as follows` is perfect in the IANA considerations section but not in the normative part. Suggest "This document specifies an OID..."

## Section 3.2.1 & 3.2.2

The reader will benefit of using a bullet list rather than tiny sub-sub-sections with a lead text.

And a normative text specifying that *all* fields must be present (my guess) and rejection (?) to be executed for invalid objects (missing parts). Section 3.3 does not say whether parts are mandatory or optional (even if the implementer could guess).

## Section 3.2.1.2

Where is the "#" in `The leading "#" character is omitted.` coming from ?

## Section 4

When can the `SHOULD` in the first paragraph be bypassed ?

Should there also be a media type associated to `The filename extension of ".tak" MUST be used to denote the object as a TAK.`? It takes section 12.5 to discover the IANA request while it is an integral part of the specification IMHO, i.e., it should appear in this section 4.

## Section 7.2

s/key/public key/ in `This key MUST now be used to create a new CA certificate for this key` ?

## Section 11.1

In `old publication URLs simply fail to resolve`, it is unclear whether 'resolve' means 'DNS resolve' or something else.
2024-05-08
15 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2024-05-08
15 Gunter Van de Velde
[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-sidrops-signed-tal-15

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

All of the COMMENTS that …
[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-sidrops-signed-tal-15

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

All of the COMMENTS that follow are non-blocking.

#GENERIC COMMENTS
#================
## Well written draft nice to read providing sufficient context and information why decisions have been made
## addresses a true problem seen by the Resource Public Key Infrastructure (RPKI)

#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

121   band way of notifying RPs of updates to a TAL.  In-band notification
122   means that TAs can be more confident of RPs being aware of key roll
123   operations.

[minor]
a TA to be confident sounds as anthropomorphism. What does being more
confident mean to a TA?

128   its TA CA certificate.  This allows RPs to be notified automatically
129   of such changes, and enables TAs to stage a successor key so that
130   planned key rolls can be performed without risking the invalidation
131   of the RPKI tree under the TA.  We call this object the Trust Anchor
132   Key (TAK) object.

[minor]
unsure if best terminology is key rolls or key rollovers?

144   absence of a TAK object.  If, during the following validation runs up
145   until the expiry of the acceptance timer, the RP has not observed any
146   changes to the keys and certificate URLs listed in the TAK object,
147   then the RP will fetch the successor key, update its local state with
148   that key and its associated certification location(s), and continue
149   processing using that key.

[minor]
are there any timers that are implied during this process in which fetching
a key should be successfull? WHat if not successful? any event logging or
other tracking/notifications?

638   turn, make debugging and similar more complicated.  A simple way of
639   addressing this problem in a situation where the TA doesn't want to
640   reissue the SubjectPublicKeyInfo content for the successor key that
641   was withdrawn is to update the URL set for the successor key, since
642   RPs must take that URL set into account for the purposes of
643   initiating and cancelling acceptance timers.

[minor]
I do not believe that "TA doesn't want to reissue" is correct. A TA can not
truely 'want' anything. It is not human. It may be configured to reissue
the SubjectPublicKeyInfo content though. Maybe the word 'prefer' is
more correct and less anthropomorph
2024-05-08
15 Gunter Van de Velde [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde
2024-04-29
15 Linda Dunbar Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Linda Dunbar. Sent review to list.
2024-04-29
15 Liz Flynn Placed on agenda for telechat - 2024-05-16
2024-04-29
15 Warren Kumari Ballot has been issued
2024-04-29
15 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2024-04-29
15 Warren Kumari Created "Approve" ballot
2024-04-29
15 Warren Kumari IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2024-04-29
15 Warren Kumari Ballot writeup was changed
2024-04-26
15 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2024-04-23
15 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2024-04-23
15 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-sidrops-signed-tal-15. If any part of this review is inaccurate, please let us know.

The …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-sidrops-signed-tal-15. If any part of this review is inaccurate, please let us know.

The IANA understands that, upon approval of this document, there are five actions which we must complete.

First, in the SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1) in the Structure of Management Information (SMI) Numbers (MIB Module Registrations) registry group located at:

https://www.iana.org/assignments/smi-numbers/

the existing early allocation for Decimal: 50 will be made permanent as follows:

Decimal: 50
Description: id-ct-signedTAL
Reference: [ RFC-to-be; Section 3.1 ]

Second, in the RPKI Signed Objects registry in the Resource Public Key Infrastructure (RPKI) registry group located at:

https://www.iana.org/assignments/rpki/

the existing temporary registration for Name: Trust Anchor Key will be made permanent as follows:

Name: Trust Anchor Key
OID: 1.2.840.113549.1.9.16.1.50
Reference: [ RFC-to-be; Section 3.1 ]

Third, also in the RPKI Signed Objects registry in the Resource Public Key Infrastructure (RPKI) registry group located at:

https://www.iana.org/assignments/rpki/

a note will be added to the registry as follows:

Objects of the types listed in this registry, as well as RPKI resource certificates and CRLs, are expected to be validated using the RPKI.

Fourth, in the RPKI Repository Name Scheme registry also in the Resource Public Key Infrastructure (RPKI) registry group located at:

https://www.iana.org/assignments/rpki/

the existing temporary registration for Filename Extension: .tak will be made permanent as follows:

Filename Extension: .tak
RPKI Object: Trust Anchor Key
Reference: [ RFC-to-be ]

Fifth, in the application namespace of the Media Type Registry located at:

https://www.iana.org/assignments/

a single new registration will be made as follows:

Name: rpki-signed-tal
Template: [TBD-at-Registration ]
Reference: [ RFC-to-be ]

We understand that these five actions are the only ones required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist
2024-04-19
15 Carlos Pignataro Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2024-04-18
15 Tero Kivinen Request for Last Call review by SECDIR is assigned to Linda Dunbar
2024-04-15
15 Jean Mahoney Request for Last Call review by GENART is assigned to Matt Joras
2024-04-12
15 Cindy Morgan IANA Review state changed to IANA - Review Needed
2024-04-12
15 Cindy Morgan
The following Last Call announcement was sent out (ends 2024-04-26):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sidrops-signed-tal@ietf.org, housley@vigilsec.com, keyur@arrcus.com, sidrops-chairs@ietf.org, sidrops@ietf.org …
The following Last Call announcement was sent out (ends 2024-04-26):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sidrops-signed-tal@ietf.org, housley@vigilsec.com, keyur@arrcus.com, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (RPKI Signed Object for Trust Anchor Key) to Proposed Standard


The IESG has received a request from the SIDR Operations WG (sidrops) to
consider the following document: - 'RPKI Signed Object for Trust Anchor Key'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-04-26. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

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 key to
  RPs, as well as the successor key and the location(s) of its CA
  certificate.  This object helps to support planned key rolls without
  impacting RPKI validation.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidrops-signed-tal/



No IPR declarations have been submitted directly on this I-D.




2024-04-12
15 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2024-04-12
15 Warren Kumari Last call was requested
2024-04-12
15 Warren Kumari Last call announcement was generated
2024-04-12
15 Warren Kumari Ballot approval text was generated
2024-04-12
15 Warren Kumari Ballot writeup was generated
2024-04-12
15 Warren Kumari IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2024-04-09
15 (System) Changed action holders to Warren Kumari (IESG state changed)
2024-04-09
15 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-04-09
15 Tom Harrison New version available: draft-ietf-sidrops-signed-tal-15.txt
2024-04-09
15 (System) New version approved
2024-04-09
15 (System) Request for posting confirmation emailed to previous authors: Carlos Martinez , George Michaelson , Rob Austein , Tim Bruijnzeels , Tom Harrison , sidrops-chairs@ietf.org
2024-04-09
15 Tom Harrison Uploaded new revision
2024-04-05
14 Warren Kumari 2024-04-05: Completed AD review.
2024-04-05
14 (System) Changed action holders to Carlos Martínez, George Michaelson, Tom Harrison, Tim Bruijnzeels, Rob Austein (IESG state changed)
2024-04-05
14 Warren Kumari IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2024-02-29
14 Warren Kumari IESG state changed to AD Evaluation from Publication Requested
2024-02-25
14 Russ Housley Document shepherd changed to Russ Housley
2024-02-25
14 Russ Housley Notification list changed to keyur@arrcus.com, housley@vigilsec.com from keyur@arrcus.com
2024-02-25
14 Russ Housley
Shepherd Write-up for draft-ietf-sidrops-signed-tal-14


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the …
Shepherd Write-up for draft-ietf-sidrops-signed-tal-14


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Proposed Standard.  Yes, the header calls for a Standards Track RFC.


(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

  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 TA CA certificate.  The TAK also supports planned
  key transitions without impacting RPKI validation by announcing the
  successor key and the location(s) of its CA certificate.

  Working Group Summary:

  There is consensus for this document in the SIDRops WG.

  Document Quality:

  There are multiple implementations.
   
  Personnel:

  Russ Housley is the document shepherd.
  Warren Kumari is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The document shepherd did a thorough review of the document during
  WG Last Call.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?  If so, describe the review that took
place.

  No concerns.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.  If not, explain why?

  The authors have explicitly stated that they are unaware of any IPR
  related with the document.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures were issued against this document.


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is consensus for this document in the SIDRops WG.
  Several people indicated that the document fills a real need.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.
 
  IDnits points out the downref for RFC 5781; however, this document
  is already in the downref registry.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  No special reviews are needed.


(13) Have all references within this document been identified as either
normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  Since publication of the Internet-Draft, RFC 6486 has been obsoleted
  by RFC 9286, and RFC 7230 has been oObsoleted by the combination of
  RFC 9110 and RFC 9112.  These references can be updated when IETF
  Last Call comments are addressed.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  There are no downward normative references that are not already in
  the downref registry.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  Early allocation was made for the code points called for in Sections
  12.1 and 12.4 to facilitate interoperable implementation.  The IANA
  actions called for in Sections 12.2, 12.3, and 12.5 are still pending.


(18) List any new IANA registries that require Expert Review for future
allocations.  Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No new IANA registries are needed.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  The ASN.1 module in Appendix A compiles without error.
2024-02-25
14 Russ Housley IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2024-02-25
14 Russ Housley IESG state changed to Publication Requested from I-D Exists
2024-02-25
14 (System) Changed action holders to Warren Kumari (IESG state changed)
2024-02-25
14 Russ Housley Responsible AD changed to Warren Kumari
2024-02-25
14 Russ Housley Document is now in IESG state Publication Requested
2024-02-25
14 Russ Housley Intended Status changed to Proposed Standard from None
2024-02-25
14 Russ Housley
Shepherd Write-up for draft-ietf-sidrops-signed-tal-14


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the …
Shepherd Write-up for draft-ietf-sidrops-signed-tal-14


(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)?  Why is this the
proper type of RFC?  Is this type of RFC indicated in the title page
header?

  Proposed Standard.  Yes, the header calls for a Standards Track RFC.


(2) The IESG approval announcement includes a Document Announcement
Write-Up.  Please provide such a Document Announcement Write-Up.  Recent
examples can be found in the "Action" announcements for approved
documents.  The approval announcement contains the following sections:

  Technical Summary:

  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 TA CA certificate.  The TAK also supports planned
  key transitions without impacting RPKI validation by announcing the
  successor key and the location(s) of its CA certificate.

  Working Group Summary:

  There is consensus for this document in the SIDRops WG.

  Document Quality:

  There are multiple implementations.
   
  Personnel:

  Russ Housley is the document shepherd.
  Warren Kumari is the responsible area director.


(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

  The document shepherd did a thorough review of the document during
  WG Last Call.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization?  If so, describe the review that took
place.

  No concerns.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of?  For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it.  In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.

  No concerns.


(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed.  If not, explain why?

  The authors have explicitly stated that they are unaware of any IPR
  related with the document.


(8) Has an IPR disclosure been filed that references this document?  If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosures were issued against this document.


(9) How solid is the WG consensus behind this document?  Does it
represent the strong concurrence of a few individuals, with others being
silent, or does the WG as a whole understand and agree with it?

  There is consensus for this document in the SIDRops WG.
  Several people indicated that the document fills a real need.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent?  If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director.  (It should be in a
separate email because this questionnaire is publicly available.)

  No one has threatened an appeal.


(11) Identify any ID nits the Document Shepherd has found in this
document.  (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist).  Boilerplate checks are not enough; this check needs to be
thorough.
 
  IDnits points out the downref for RFC 5781; however, this document
  is already in the downref registry.


(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.

  No special reviews are needed.


(13) Have all references within this document been identified as either
normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?  If such normative
references exist, what is the plan for their completion?

  Since publication of the Internet-Draft, RFC 6486 has been obsoleted
  by RFC 9286, and RFC 7230 has been oObsoleted by the combination of
  RFC 9110 and RFC 9112.  These references can be updated when IETF
  Last Call comments are addressed.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  There are no downward normative references that are not already in
  the downref registry.


(16) Will publication of this document change the status of any existing
RFCs?  Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?  If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs is
discussed.  If this information is not in the document, explain why the
WG considers it unnecessary.

  No.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document.  Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly identified.
Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations
procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

  Early allocation was made for the code points called for in Sections
  12.1 and 12.4 to facilitate interoperable implementation.  The IANA
  actions called for in Sections 12.2, 12.3, and 12.5 are still pending.


(18) List any new IANA registries that require Expert Review for future
allocations.  Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.

  No new IANA registries are needed.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  The ASN.1 module in Appendix A compiles without error.
2024-02-25
14 Russ Housley Changed consensus to Yes from Unknown
2024-02-24
14 Russ Housley IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document
2023-09-05
14 Tom Harrison New version available: draft-ietf-sidrops-signed-tal-14.txt
2023-09-05
14 Tom Harrison New version accepted (logged-in submitter: Tom Harrison)
2023-09-05
14 Tom Harrison Uploaded new revision
2023-03-12
13 Tom Harrison New version available: draft-ietf-sidrops-signed-tal-13.txt
2023-03-12
13 Tom Harrison New version accepted (logged-in submitter: Tom Harrison)
2023-03-12
13 Tom Harrison Uploaded new revision
2023-02-09
12 Keyur Patel Notification list changed to keyur@arrcus.com because the document shepherd was set
2023-02-09
12 Keyur Patel Document shepherd changed to Keyur Patel
2023-02-09
12 Keyur Patel IETF WG state changed to WG Document from In WG Last Call
2022-10-11
12 Tom Harrison New version available: draft-ietf-sidrops-signed-tal-12.txt
2022-10-11
12 Tom Harrison New version accepted (logged-in submitter: Tom Harrison)
2022-10-11
12 Tom Harrison Uploaded new revision
2022-09-14
11 Tom Harrison New version available: draft-ietf-sidrops-signed-tal-11.txt
2022-09-14
11 Tom Harrison New version accepted (logged-in submitter: Tom Harrison)
2022-09-14
11 Tom Harrison Uploaded new revision
2022-07-11
10 Tom Harrison New version available: draft-ietf-sidrops-signed-tal-10.txt
2022-07-11
10 Tom Harrison New version accepted (logged-in submitter: Tom Harrison)
2022-07-11
10 Tom Harrison Uploaded new revision
2022-03-06
09 Tom Harrison New version available: draft-ietf-sidrops-signed-tal-09.txt
2022-03-06
09 (System) New version accepted (logged-in submitter: Tom Harrison)
2022-03-06
09 Tom Harrison Uploaded new revision
2021-12-16
08 Tom Harrison New version available: draft-ietf-sidrops-signed-tal-08.txt
2021-12-16
08 (System) New version accepted (logged-in submitter: Tom Harrison)
2021-12-16
08 Tom Harrison Uploaded new revision
2021-06-17
07 Tom Harrison New version available: draft-ietf-sidrops-signed-tal-07.txt
2021-06-17
07 (System) New version accepted (logged-in submitter: Tom Harrison)
2021-06-17
07 Tom Harrison Uploaded new revision
2021-05-05
06 (System) Document has expired
2020-11-01
06 George Michaelson New version available: draft-ietf-sidrops-signed-tal-06.txt
2020-11-01
06 (System) New version approved
2020-11-01
06 (System) Request for posting confirmation emailed to previous authors: George Michaelson , Rob Austein , Tom Harrison , Tim Bruijnzeels , Carlos Martinez
2020-11-01
06 George Michaelson Uploaded new revision
2020-07-27
05 (System) Document has expired
2020-01-15
05 George Michaelson New version available: draft-ietf-sidrops-signed-tal-05.txt
2020-01-15
05 (System) New version approved
2020-01-15
05 (System) Request for posting confirmation emailed to previous authors: sidrops-chairs@ietf.org, Rob Austein , Tim Bruijnzeels , George Michaelson , Carlos Martinez
2020-01-15
05 George Michaelson Uploaded new revision
2020-01-06
04 George Michaelson New version available: draft-ietf-sidrops-signed-tal-04.txt
2020-01-06
04 (System) New version approved
2020-01-06
04 (System) Request for posting confirmation emailed to previous authors: sidrops-chairs@ietf.org, Rob Austein , Tim Bruijnzeels , Carlos Martinez
2020-01-06
04 George Michaelson Uploaded new revision
2019-07-08
03 Tim Bruijnzeels New version available: draft-ietf-sidrops-signed-tal-03.txt
2019-07-08
03 (System) New version approved
2019-07-08
03 (System) Request for posting confirmation emailed to previous authors: Rob Austein , Tim Bruijnzeels , Carlos Martinez
2019-07-08
03 Tim Bruijnzeels Uploaded new revision
2019-04-22
02 (System) Document has expired
2018-11-05
02 Chris Morrow IETF WG state changed to In WG Last Call from WG Document
2018-10-19
02 Tim Bruijnzeels New version available: draft-ietf-sidrops-signed-tal-02.txt
2018-10-19
02 (System) New version approved
2018-10-19
02 (System) Request for posting confirmation emailed to previous authors: sidrops-chairs@ietf.org, Tim Bruijnzeels , Carlos Martinez
2018-10-19
02 Tim Bruijnzeels Uploaded new revision
2018-06-08
01 Tim Bruijnzeels New version available: draft-ietf-sidrops-signed-tal-01.txt
2018-06-08
01 (System) New version approved
2018-06-08
01 (System) Request for posting confirmation emailed to previous authors: sidrops-chairs@ietf.org, Tim Bruijnzeels , Carlos Martinez
2018-06-08
01 Tim Bruijnzeels Uploaded new revision
2018-05-17
00 (System) Document has expired
2017-11-14
00 Chris Morrow Added to session: IETF-100: sidrops  Wed-1330
2017-11-13
00 Chris Morrow This document now replaces draft-tbruijnzeels-sidrops-signed-tal instead of None
2017-11-13
00 Tim Bruijnzeels New version available: draft-ietf-sidrops-signed-tal-00.txt
2017-11-13
00 (System) WG -00 approved
2017-11-13
00 Tim Bruijnzeels Set submitter to "Tim Bruijnzeels ", replaces to draft-tbruijnzeels-sidrops-signed-tal and sent approval email to group chairs: sidrops-chairs@ietf.org
2017-11-13
00 Tim Bruijnzeels Uploaded new revision