Skip to main content

On the use of the CMS signing-time attribute in RPKI Signed Objects
draft-ietf-sidrops-cms-signing-time-07

Revision differences

Document history

Date Rev. By Action
2024-05-23
(System)
Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-sidrops-cms-signing-time and RFC 9589, changed IESG state to RFC …
Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-sidrops-cms-signing-time and RFC 9589, changed IESG state to RFC Published)
2024-05-20
07 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2024-05-17
07 (System) RFC Editor state changed to AUTH48
2024-05-16
07 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2024-05-04
07 Carlos Pignataro Request closed, assignment withdrawn: Tina Tsou Last Call OPSDIR review
2024-05-04
07 Carlos Pignataro Closed request for Last Call review by OPSDIR with state 'Overtaken by Events'
2024-04-25
07 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2024-04-25
07 Tero Kivinen Assignment of request for Last Call review by SECDIR to Aanchal Malhotra was marked no-response
2024-04-23
07 (System) RFC Editor state changed to EDIT
2024-04-23
07 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2024-04-23
07 (System) Announcement was received by RFC Editor
2024-04-22
07 (System) IANA Action state changed to No IANA Actions from In Progress
2024-04-22
07 (System) IANA Action state changed to In Progress
2024-04-22
07 (System) Removed all action holders (IESG state changed)
2024-04-22
07 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2024-04-22
07 Cindy Morgan IESG has approved the document
2024-04-22
07 Cindy Morgan Closed "Approve" ballot
2024-04-22
07 Cindy Morgan Ballot approval text was generated
2024-04-18
07 Cindy Morgan IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation
2024-04-18
07 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2024-04-17
07 Paul Wouters
[Ballot comment]
The abstract seems overly long and best moved to the Introduction. I would only
keep the last paragraph of the Abstract. Although it …
[Ballot comment]
The abstract seems overly long and best moved to the Introduction. I would only
keep the last paragraph of the Abstract. Although it seems already mostly
repeated in the Introduction so just removing the first two paragraphs would
probably be good as well.

        This document advances the aforementioned concept

Advance from what to what? I think you mean "from optional to mandatory" ?

In section 2.2, it talks about omitting transfers and sparse backups, but it
does not mention it creates hardlinks for files that need no transfering from
the reference directory, at least how I use rsync, eg with --archive which
means "-rlptgoD". (this is fact the way I still do backups, creating daily
trees that are full directory sets per day all using hardlinks for unmodified
files). With this option, it does the things the document talks about, like
using original datestamp, perms, modes, etc.
2024-04-17
07 Paul Wouters [Ballot Position Update] New position, Yes, has been recorded for Paul Wouters
2024-04-16
07 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2024-04-16
07 John Scudder
[Ballot comment]
Thanks for this clean and easy to read document. I have two small comments.

### Section 2

  To avoid needless re-transfers of …
[Ballot comment]
Thanks for this clean and easy to read document. I have two small comments.

### Section 2

  To avoid needless re-transfers of unchanged files in consecutive
  rsync synchronizations, [I-D.timbru-sidrops-publication-server-bcp]
  recommends the use of so-called 'deterministic' (normalized)
  timestamps for files.  When the content of a file is unchanged,
  Repository Operators SHOULD ensure that the last modification
  timestamp of the file remains unchanged as well.

Is the RFC 2119 keyword a new requirement you are introducing in this document? If it’s a quote from the draft you cite, please make it clear that’s what it is.

### Section 2.2

  If an RP uses RRDP to synthesize a filesystem hierarchy for the
  repository, then synchronizing to the corresponding directory
  directly is an option.  Alternatively, the RP can synchronize to a
  new (empty) directory using the _--compare-dest=DIR_ rsync feature,
  in order to avoid retrieving files that are already available by way
  of the synthesized filesystem hierarchy stemming from previous RRDP
  fetches.

I found this difficult to follow. Something like this would’ve been easier for me —

NEW:

  If an RP used RRDP to synthesize a filesystem hierarchy for the
  repository, then when it must fall back to rsync one option is
  synchronizing to the corresponding directory
  directly.  Alternatively, the RP can synchronize to a
  new (empty) directory using the _--compare-dest=DIR_ rsync feature,
  in order to avoid retrieving files that are already available by way
  of the synthesized filesystem hierarchy stemming from previous RRDP
  fetches.
2024-04-16
07 John Scudder [Ballot Position Update] New position, Yes, has been recorded for John Scudder
2024-04-16
07 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2024-04-16
07 Job Snijders New version available: draft-ietf-sidrops-cms-signing-time-07.txt
2024-04-16
07 Job Snijders New version accepted (logged-in submitter: Job Snijders)
2024-04-16
07 Job Snijders Uploaded new revision
2024-04-16
06 Zaheduzzaman Sarker
[Ballot comment]
Thanks for working on this specification, I have no comments from transport layer points of view.

However, I am a bit struggling with …
[Ballot comment]
Thanks for working on this specification, I have no comments from transport layer points of view.

However, I am a bit struggling with "Publisher", where is it defined? Is this a CA or Publisher Server? It would be great if we can clarify the role of the publisher in this document as well.
2024-04-16
06 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2024-04-16
06 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2024-04-16
06 Éric Vyncke
[Ballot comment]
Thanks for the work done on this document.

Minor regret about the shepherd's write-up as it lacks the justification for the intended status. …
[Ballot comment]
Thanks for the work done on this document.

Minor regret about the shepherd's write-up as it lacks the justification for the intended status.

Like noted by other ADs: the goal of an abstract is not to repeat the introduction but be a concise 10-line-max summary of the document.

In section 2 `Publishers and RPs SHOULD adhere to the following guidelines` when can this SHOULD be bypassed ? Same comment applies to many "SHOULD" in this document.
2024-04-16
06 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2024-04-15
06 Roman Danyliw
[Ballot comment]
Thank you to Gyan Mishra for the GENART review.

** Section 2.*

-- Section 2
  When the content of a file is …
[Ballot comment]
Thank you to Gyan Mishra for the GENART review.

** Section 2.*

-- Section 2
  When the content of a file is unchanged,
  Publishers SHOULD ensure that the last modification timestamp of the
  file remains unchanged as well.

-- Section 2.2
  When serializing RPKI Signed Objects retrieved via RRDP to a
  filesystem hierarchy, the mod-time of the file containing the Signed
  Object SHOULD be set to the value of the CMS signing-time attribute
  contained within the Signed Object.

How does this mechanism work if the timestamp is not set per the above guidance?  Why not MUST?

** Section 2.  Editorial.
  As described in [I-D.ietf-sidrops-prefer-rrdp], all modern RP
  implementations will first attempt synchronization via RRDP.

Is “modern” characterization that will age well in an RFC?

** Section 2.2.  Section 2 says the “Publishers and RPs SHOULD adhere to the following guidelines”, where these guidelines are Section 2.*.  Later, in Section 2.2, there appears be guidance around the specific invocation of [rsync] and [openrsync].  Hence, both of these references need to be normative.

** Thanks for the analysis in Section 3.
2024-04-15
06 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2024-04-14
06 Mahesh Jethanandani [Ballot comment]
I also noticed that the Introduction and the Abstract were exact copies of each other. Could the Abstract be an abstract?
2024-04-14
06 Mahesh Jethanandani [Ballot Position Update] New position, No Objection, has been recorded for Mahesh Jethanandani
2024-04-10
06 Gunter Van de Velde
[Ballot comment]
Document reviewed: draft-ietf-sidrops-cms-signing-time-06.txt

Many thanks for this write-up.
During my review cycle i noted some observations that you may consider if you find …
[Ballot comment]
Document reviewed: draft-ietf-sidrops-cms-signing-time-06.txt

Many thanks for this write-up.
During my review cycle i noted some observations that you may consider if you find beneficial

13   In the Resource Public Key Infrastructure (RPKI), Signed Objects are
14   defined as Cryptographic Message Syntax (CMS) protected content types
15   by way of a standard template (RFC 6488).  That template includes an
16   optional CMS signing-time attribute, representing the purported time
17   at which the object was signed by its issuer.  At the time when the
18   standard template was defined, rsync was the only distribution
19   mechanism for RPKI repositories.

would the following blob flow as a more natural read?
In the Resource Public Key Infrastructure (RPKI), Signed Objects are specified as
Cryptographic Message Syntax (CMS) protected content types, utilizing a
standardized template as defined in RFC 6488. This template encompasses an
optional CMS signing-time attribute, which purports to indicate the time
at which the issuer signed the object. Concurrent with the establishment
of this standard template, rsync constituted the sole distribution
mechanism for RPKI repositories.

32   This document describes how Publishers and RPs can use the CMS
33   signing-time attribute to minimize the burden of switching over from

i got thrown of by the usage of 'publishers' i suspect this is referring to the good folks that host RPKI.
the relationship between publishers and RPs is only implicit assumed. Is that that good enough?

32   This document describes how Publishers and RPs can use the CMS
33   signing-time attribute to minimize the burden of switching over from
34   RRDP to rsync.  Additionally, this document updates RFC 6488 by

this is only about a fallback from RRDP to rsync and not about restoring the reverse (rsync back to RRDP) direction?

96 1.  Introduction

The complete introduction is an exact copy from the abstract.
Maybe the abstract can be mode more abstract'isch to add value?

What about something like this for abstract instead:

"This document provides an overview of the cryptographic frameworks and distribution
mechanisms in the Resource Public Key Infrastructure (RPKI) as defined by various
RFCs. Initially, RPKI Signed Objects were secured using the Cryptographic Message
Syntax (CMS), with an optional signing-time attribute indicating the time of
signing by the issuer, and distributed exclusively via rsync.

With the development and subsequent adoption of the RPKI Repository Delta
Protocol (RRDP), a newer method that is generally preferred for its efficiency,
the landscape has evolved. RPKI operators are still required to offer rsync
as a fallback, highlighting the need for effective transition strategies between
the two protocols.

This document outlines the strategic use of the CMS signing-time
attribute to ease the transition from RRDP back to rsync, proposing updates to
RFC6488 to enhance protocol implementation and reliability by mandating the
signing-time attribute and eliminating the binary-signing-time attribute.
These modifications aim to streamline operations and improve the robustness
of RPKI repository management."

128   timestamps for files.  When the content of a file is unchanged,
129   Publishers SHOULD ensure that the last modification timestamp of the

The who or what a publisher exactly is, has not be mentioned within this document.

137   As described in [I-D.ietf-sidrops-prefer-rrdp], all modern RP
138   implementations will first attempt synchronization via RRDP.  If
139   synchronization via RRDP fails for some reason (e.g. malformed XML,
140   expired TLS certificate, HTTP connection timeout), the RP will
141   attempt to synchronize via rsync instead.

the three words 'for some reason' could be removed without changing the intent of the phrase.
2024-04-10
06 Gunter Van de Velde [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde
2024-04-09
06 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2024-04-09
06 Deb Cooley [Ballot Position Update] New position, No Objection, has been recorded for Deb Cooley
2024-04-08
06 Orie Steele
[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-sidrops-cms-signing-time-06
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-sidrops-cms-signing-time-06.txt&submitcheck=True

## Comments

```
129   Publishers SHOULD ensure that the last modification …
[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-sidrops-cms-signing-time-06
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-sidrops-cms-signing-time-06.txt&submitcheck=True

## Comments

```
129   Publishers SHOULD ensure that the last modification timestamp of the
130   file remains unchanged as well.
```

Why not MUST? What happens if they do not?

```
156   In order to reduce the burden of the rsync synchronization (following
157   an RRDP failure), Publishers and RPs SHOULD adhere to the following
158   guidelines.
```

Why not MUST? Perhaps this sentence is not needed.

```
162   When serializing RPKI Signed Objects to a filesystem hierarchy for
163   publication via rsync, the mod-time of the file containing the Signed
164   Object SHOULD be set to the value of the CMS signing-time attribute
165   contained within the Signed Object.
```

Why not MUST? What happens if the mod-time is set to something else?
Does this guidance also apply to publishers that support RRDP in addition to rsync?

```
169   When serializing RPKI Signed Objects retrieved via RRDP to a
170   filesystem hierarchy, the mod-time of the file containing the Signed
171   Object SHOULD be set to the value of the CMS signing-time attribute
172   contained within the Signed Object.
```

Why not MUST?

The amount of redundancy between this section and previous section, is confusing.
I would assume publishing and consuming would both need guidance on CMS signing-time, regardless of if rsync or RRDP was used.
2024-04-08
06 Orie Steele [Ballot Position Update] New position, No Objection, has been recorded for Orie Steele
2024-04-05
06 Jenny Bui Placed on agenda for telechat - 2024-04-18
2024-04-05
06 Warren Kumari Ballot has been issued
2024-04-05
06 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2024-04-05
06 Warren Kumari Created "Approve" ballot
2024-04-05
06 Warren Kumari IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2024-03-11
06 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2024-03-07
06 Gyan Mishra Request for Last Call review by GENART Completed: Ready. Reviewer: Gyan Mishra. Sent review to list. Submission of review completed at an earlier date.
2024-03-07
06 Gyan Mishra Request for Last Call review by GENART Completed: Ready. Reviewer: Gyan Mishra.
2024-03-05
06 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2024-03-05
06 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-sidrops-cms-signing-time-06, which is currently in Last Call, and has the following comments:

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

IANA has completed its review of draft-ietf-sidrops-cms-signing-time-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

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-02-29
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Aanchal Malhotra
2024-02-29
06 Jean Mahoney Request for Last Call review by GENART is assigned to Gyan Mishra
2024-02-27
06 Carlos Pignataro Request for Last Call review by OPSDIR is assigned to Tina Tsou
2024-02-26
06 Cindy Morgan IANA Review state changed to IANA - Review Needed
2024-02-26
06 Cindy Morgan
The following Last Call announcement was sent out (ends 2024-03-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sidrops-cms-signing-time@ietf.org, housley@vigilsec.com, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net …
The following Last Call announcement was sent out (ends 2024-03-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sidrops-cms-signing-time@ietf.org, housley@vigilsec.com, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (On the use of the CMS signing-time attribute in RPKI Signed Objects) to Proposed Standard


The IESG has received a request from the SIDR Operations WG (sidrops) to
consider the following document: - 'On the use of the CMS signing-time
attribute in RPKI Signed Objects'
  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-03-11. 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


  In the Resource Public Key Infrastructure (RPKI), Signed Objects are
  defined as Cryptographic Message Syntax (CMS) protected content types
  by way of a standard template (RFC 6488).  That template includes an
  optional CMS signing-time attribute, representing the purported time
  at which the object was signed by its issuer.  At the time when the
  standard template was defined, rsync was the only distribution
  mechanism for RPKI repositories.

  Since the publication of the standard template, a new, additional
  protocol for distribution of RPKI repositories has been developed:
  the RPKI Repository Delta Protocol (RRDP).  While RPKI repository
  operators must provide rsync service, RRDP is typically deployed
  alongside it as well, and preferred by default by most Relying Party
  (RP) implementations.  However, RP implementations also support
  fallback to rsync in the event of problems with the RRDP service.  As
  deployment experience with RRDP has increased, the usefulness of
  optimizing switchovers by RPs from one mechanism to the other has
  become apparent.

  This document describes how Publishers and RPs can use the CMS
  signing-time attribute to minimize the burden of switching over from
  RRDP to rsync.  Additionally, this document updates RFC 6488 by
  mandating the presence of the CMS signing-time attribute and
  disallowing the use of the binary-signing-time attribute.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidrops-cms-signing-time/



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




2024-02-26
06 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2024-02-26
06 Cindy Morgan Last call announcement was generated
2024-02-24
06 Warren Kumari Last call was requested
2024-02-24
06 Warren Kumari Last call announcement was generated
2024-02-24
06 Warren Kumari Ballot approval text was generated
2024-02-24
06 Warren Kumari IESG state changed to Last Call Requested from Publication Requested
2024-02-24
06 Warren Kumari Ballot writeup was changed
2024-02-10
06 Russ Housley
Shepherd Write-up for draft-ietf-sidrops-cms-signing-time-06


(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-cms-signing-time-06


(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:

  In the Resource Public Key Infrastructure (RPKI), Signed Objects are
  defined as Cryptographic Message Syntax (CMS) protected content types
  using the template that is published in RFC 6488, which includes an
  optional CMS signing-time attribute.  When the template was defined,
  rsync was the only distribution mechanism for RPKI repositories.
  Today, the RPKI Repository Delta Protocol (RRDP) is also used.  While
  RPKI repository operators must provide rsync service, RRDP is also
  typically deployed and preferred by most relying parties (RPs).  When
  fetches with RRDP fail, PRs fallback to rsync.  This document
  describes how Publishers and RPs can use the CMS signing-time
  attribute to minimize the burden of switching over from
  RRDP to rsync.  Additionally, this document updates RFC 6488 to
  mandate the presence of the CMS signing-time attribute and
  disallow the use of the alternative binary-signing-time attribute.

  Working Group Summary:

  There is consensus for this document in the SIDRops WG.

  Document Quality:

  There are multiple implementations available today.
   
  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 after
  WG Last Call.  All issues that were raised during WG Last Call have
  been resolved.


(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.
  Many people indicated that they are looking forward to the
  performance improvement associated with this document.


(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 downrefs for RFC 6268 and RFC 6480; however, both
  of these documents are 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?

  No.


(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).

  No updates to the IANA registries are needed.


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

  None are needed.
2024-02-10
06 Russ Housley IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2024-02-10
06 Russ Housley IESG state changed to Publication Requested from I-D Exists
2024-02-10
06 (System) Changed action holders to Warren Kumari (IESG state changed)
2024-02-10
06 Russ Housley Responsible AD changed to Warren Kumari
2024-02-10
06 Russ Housley Document is now in IESG state Publication Requested
2024-02-10
06 Russ Housley Intended Status changed to Proposed Standard from None
2024-02-10
06 Russ Housley
Shepherd Write-up for draft-ietf-sidrops-cms-signing-time-06


(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-cms-signing-time-06


(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:

  In the Resource Public Key Infrastructure (RPKI), Signed Objects are
  defined as Cryptographic Message Syntax (CMS) protected content types
  using the template that is published in RFC 6488, which includes an
  optional CMS signing-time attribute.  When the template was defined,
  rsync was the only distribution mechanism for RPKI repositories.
  Today, the RPKI Repository Delta Protocol (RRDP) is also used.  While
  RPKI repository operators must provide rsync service, RRDP is also
  typically deployed and preferred by most relying parties (RPs).  When
  fetches with RRDP fail, PRs fallback to rsync.  This document
  describes how Publishers and RPs can use the CMS signing-time
  attribute to minimize the burden of switching over from
  RRDP to rsync.  Additionally, this document updates RFC 6488 to
  mandate the presence of the CMS signing-time attribute and
  disallow the use of the alternative binary-signing-time attribute.

  Working Group Summary:

  There is consensus for this document in the SIDRops WG.

  Document Quality:

  There are multiple implementations available today.
   
  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 after
  WG Last Call.  All issues that were raised during WG Last Call have
  been resolved.


(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.
  Many people indicated that they are looking forward to the
  performance improvement associated with this document.


(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 downrefs for RFC 6268 and RFC 6480; however, both
  of these documents are 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?

  No.


(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).

  No updates to the IANA registries are needed.


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

  None are needed.
2024-02-10
06 Russ Housley Changed document external resources from: None to:

github_repo https://github.com/job/draft-sidrops-cms-signing-time
related_implementations https://github.com/NLnetLabs/krill-sync
related_implementations https://github.com/RIPE-NCC/rsyncit
related_implementations https://github.com/job/rpkitouch
related_implementations https://github.com/ties/rpki-rrdp-tools-py
related_implementations https://www.rpki-client.org
2024-02-10
06 Job Snijders New version available: draft-ietf-sidrops-cms-signing-time-06.txt
2024-02-10
06 Job Snijders New version accepted (logged-in submitter: Job Snijders)
2024-02-10
06 Job Snijders Uploaded new revision
2024-02-09
05 Russ Housley IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2024-01-29
05 Job Snijders New version available: draft-ietf-sidrops-cms-signing-time-05.txt
2024-01-29
05 Job Snijders New version accepted (logged-in submitter: Job Snijders)
2024-01-29
05 Job Snijders Uploaded new revision
2024-01-22
04 Russ Housley Notification list changed to housley@vigilsec.com because the document shepherd was set
2024-01-22
04 Russ Housley Document shepherd changed to Russ Housley
2024-01-22
04 Russ Housley IETF WG state changed to In WG Last Call from WG Document
2024-01-22
04 Russ Housley Changed consensus to Yes from Unknown
2024-01-22
04 Job Snijders New version available: draft-ietf-sidrops-cms-signing-time-04.txt
2024-01-22
04 Job Snijders New version accepted (logged-in submitter: Job Snijders)
2024-01-22
04 Job Snijders Uploaded new revision
2024-01-18
03 Job Snijders New version available: draft-ietf-sidrops-cms-signing-time-03.txt
2024-01-18
03 Job Snijders New version accepted (logged-in submitter: Job Snijders)
2024-01-18
03 Job Snijders Uploaded new revision
2024-01-16
02 Job Snijders New version available: draft-ietf-sidrops-cms-signing-time-02.txt
2024-01-16
02 Job Snijders New version accepted (logged-in submitter: Job Snijders)
2024-01-16
02 Job Snijders Uploaded new revision
2024-01-16
01 Job Snijders New version available: draft-ietf-sidrops-cms-signing-time-01.txt
2024-01-16
01 Job Snijders New version accepted (logged-in submitter: Job Snijders)
2024-01-16
01 Job Snijders Uploaded new revision
2023-07-24
00 Russ Housley This document now replaces draft-spaghetti-sidrops-cms-signing-time instead of None
2023-07-24
00 Job Snijders New version available: draft-ietf-sidrops-cms-signing-time-00.txt
2023-07-24
00 Russ Housley WG -00 approved
2023-07-24
00 Job Snijders Set submitter to "Job Snijders ", replaces to draft-spaghetti-sidrops-cms-signing-time and sent approval email to group chairs: sidrops-chairs@ietf.org
2023-07-24
00 Job Snijders Uploaded new revision