Skip to main content

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

Yes

Warren Kumari

No Objection

Deb Cooley
Erik Kline
Jim Guichard
Murray Kucherawy

Note: This ballot was opened for revision 06 and is now closed.

John Scudder
Yes
Comment (2024-04-16) Sent
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.
Paul Wouters
Yes
Comment (2024-04-17) Sent
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.
Warren Kumari
Yes
Deb Cooley
No Objection
Erik Kline
No Objection
Gunter Van de Velde
No Objection
Comment (2024-04-10 for -06) Not sent
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.
Jim Guichard
No Objection
Mahesh Jethanandani
No Objection
Comment (2024-04-14 for -06) Sent
I also noticed that the Introduction and the Abstract were exact copies of each other. Could the Abstract be an abstract?
Murray Kucherawy
No Objection
Orie Steele
No Objection
Comment (2024-04-08 for -06) Sent
# 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.
Roman Danyliw
No Objection
Comment (2024-04-15 for -06) Sent
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.
Zaheduzzaman Sarker
No Objection
Comment (2024-04-16 for -06) Sent
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.
Éric Vyncke
No Objection
Comment (2024-04-16 for -06) Sent
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.