Skip to main content

Manifests for the Resource Public Key Infrastructure (RPKI)
draft-ietf-sidrops-6486bis-11

Revision differences

Document history

Date Rev. By Action
2024-01-26
11 Gunter Van de Velde Request closed, assignment withdrawn: Linda Dunbar Last Call OPSDIR review
2024-01-26
11 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2022-06-20
11 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2022-05-20
11 (System) RFC Editor state changed to AUTH48
2022-05-19
11 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2022-04-14
11 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Overtaken by Events'
2022-04-14
11 Tero Kivinen Assignment of request for Last Call review by SECDIR to Alan DeKok was marked no-response
2022-04-11
11 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2022-04-11
11 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2022-04-11
11 (System) IANA Action state changed to In Progress from Waiting on Authors
2022-04-11
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2022-04-07
11 (System) RFC Editor state changed to EDIT
2022-04-07
11 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2022-04-07
11 (System) Announcement was received by RFC Editor
2022-04-07
11 (System) IANA Action state changed to In Progress
2022-04-07
11 (System) Removed all action holders (IESG state changed)
2022-04-07
11 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2022-04-07
11 Cindy Morgan IESG has approved the document
2022-04-07
11 Cindy Morgan Closed "Approve" ballot
2022-04-07
11 Cindy Morgan Ballot approval text was generated
2022-03-24
11 Stephen Kent New version available: draft-ietf-sidrops-6486bis-11.txt
2022-03-24
11 (System) New version approved
2022-03-24
11 (System) Request for posting confirmation emailed to previous authors: Geoff Huston , Matt Lepinski , Rob Austein , Stephen Kent
2022-03-24
11 Stephen Kent Uploaded new revision
2022-03-23
10 Benjamin Kaduk
[Ballot comment]
Clearing DISCUSS on expectation of the additional change discussed with the
authors.  Thanks for being responsive to all the comments and working to …
[Ballot comment]
Clearing DISCUSS on expectation of the additional change discussed with the
authors.  Thanks for being responsive to all the comments and working to
get the right thing documented!
2022-03-23
10 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2022-03-20
10 (System) Changed action holders to Warren Kumari (IESG state changed)
2022-03-20
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-03-20
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2022-03-20
10 Stephen Kent New version available: draft-ietf-sidrops-6486bis-10.txt
2022-03-20
10 (System) New version approved
2022-03-20
10 (System) Request for posting confirmation emailed to previous authors: Geoff Huston , Matt Lepinski , Rob Austein , Stephen Kent
2022-03-20
10 Stephen Kent Uploaded new revision
2022-03-11
09 Jean Mahoney Closed request for Last Call review by GENART with state 'Overtaken by Events'
2022-03-11
09 Jean Mahoney Assignment of request for Last Call review by GENART to Suhas Nandakumar was marked no-response
2022-02-03
09 (System) Changed action holders to Rob Austein, Geoff Huston, Matt Lepinski, Stephen Kent, Warren Kumari (IESG state changed)
2022-02-03
09 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2022-02-03
09 Robert Wilton
[Ballot comment]
Thanks for this document, just a couple of minor comments:

1) Section 4.2.1. Manifest

  nextUpdate:
      This field contains the …
[Ballot comment]
Thanks for this document, just a couple of minor comments:

1) Section 4.2.1. Manifest

  nextUpdate:
      This field contains the time at which the next scheduled manifest
      will be issued.  The value of nextUpdate MUST be later than the
      value of thisUpdate.  The specification of the GeneralizedTime
      value is the same as required for the thisUpdate field.

      If the authority alters any of the items that it has published in
      the repository publication point, then the authority MUST issue a
      new manifest.  Even if no changes are made to objects at a
      publication point, a new manifest MUST be issued before the
      nextUpdate time.  Each manifest encompasses a CRL, and the
      nextUpdate field of the manifest SHOULD match that of the CRL's
      nextUpdate field, as the manifest will be re-issued when a new CRL
      is published.  When a new manifest is issued before the time
      specified in nextUpdate of the current manifest, the CA MUST also
      issue a new CRL that revokes the EE certificate corresponding to
      the old manifest.

Although this last sentence is not wrong, am I right in thinking that this sentence isn't specific to when the manifest is issued, i.e., isn't it the case that that CA MUST issue a new CRL whenever a new manifest is issues for any reason (e.g., as per 5.1, step 2)?  If so, perhaps this sentence could be tweaked to make that clearer.

2) 5.2.  Considerations for Manifest Generation

  A new manifest MUST be issued and published before the nextUpdate
  time.

Should any guidance be given about how far before the nextUpdate time a new manifest should be issued.  E.g., is publishing right at the nextUpdate time (e.g., 1 millisecond before) sufficient , or does it make sense to publish it a bit earlier than the nextUpdate time?

Nits:

4.1.  eContentType

  The eContentType for a manifest is defined as id-ct-rpkiManifest and
  has the numerical value of 1.2.840.113549.1.9.16.1.26.

Would numerical object identifier, or numerical OID, be better than numerical value here?

4.2.  eContent

I would have preferred for "file" to be "filename" in the structure, but I presume that this can't be changed at this stage anyway ...

Regards,
Rob
2022-02-03
09 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2022-02-03
09 Lars Eggert
[Ballot comment]
Using lowercase "not" together with an uppercase RFC2119 keyword is not
acceptable usage. Found: "MUST not"

Found terminology that should be reviewed for …
[Ballot comment]
Using lowercase "not" together with an uppercase RFC2119 keyword is not
acceptable usage. Found: "MUST not"

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "man"; alternatives might be "individual", "people", "person".

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 5.2. , paragraph 5, nit:
> ion point to effect this operation. Thus the term "fetch" refers to an operat
>                                    ^^^^
A comma may be missing after the conjunctive/linking adverb "Thus".

Section 11.1. , paragraph 11, nit:
> Appendix B. Changes to RFC 6486 In 2019 it came to light that multiple Relyin
>                                    ^^^^
A comma is probably missing here.

Uncited references: [RFC6493], [RFC6482], [RFC8209], and [RFC8488].

Reference [RFC6485] to RFC6485, which was obsoleted by RFC7935 (this may be on
purpose).
2022-02-03
09 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2022-02-03
09 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2022-02-02
09 Roman Danyliw
[Ballot comment]
I support Ben Kaduk's DISCUSS position.

** Section 8.  The Section 4.2.1 guidance that “Each RP MUST verify that a purported "new" Manifest …
[Ballot comment]
I support Ben Kaduk's DISCUSS position.

** Section 8.  The Section 4.2.1 guidance that “Each RP MUST verify that a purported "new" Manifest contains a higher manifestNumber than previously-validated Manifests” is crucial to prevent a replay-like attack.  What is the recovery procedure if an RP loses that state (i.e., “forgets” what the last manifestNumber was for a given publication point)?  Should it be TOFU (trust whatever is the first value it downloads next)?

** Editorial
-- Section 1.  In the spirit of inclusive language consider replacing “man-in-the-middle”.  For example, s/man-in-the-middle attack on the retrieval/an on-path attack during the retrieval/

-- Section 4.2.1.  Editorial.  In the thisUpdate field, s/is recent any/is more recent than any/
2022-02-02
09 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2022-02-02
09 Alvaro Retana [Ballot comment]
I support Ben's DISCUSS.
2022-02-02
09 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2022-02-02
09 Francesca Palombini
[Ballot comment]
Thank you for the work on this document

I have an easy to fix point that should be address before publication (although it …
[Ballot comment]
Thank you for the work on this document

I have an easy to fix point that should be address before publication (although it probably does not rise to the level of DISCUSS). I also have a number of minor comments (answers will be appreciated) and nits.

Francesca

# Major

1. -----

  objects from a successful fetch.  This implies that the RP MUST not

FP: This should be "MUST NOT" (rather than "MUST not")

# Minor

2. -----

FP: as noted by the shepherd, there are some references to fix:

  * RFC 6485 needs to be replaced with RFC 7935

The following references need to be removed as they are not used.

  == Unused Reference: 'RFC6482'
  == Unused Reference: 'RFC6493'
  == Unused Reference: 'RFC8209'
  == Unused Reference: 'RFC8488'  (this was even last called as downref)

3. -----

      monotonically for each newly-generated Manifest.  Each RP MUST
      verify that a purported "new" Manifest contains a higher
      manifestNumber than previously-validated Manifests.

FP: This should contain a sentence about what the RP has to do if verification fails (I expect ignore the "new" Manifest). Same comment for the thisUpdate field:

      Manifest.  Each RP MUST verify that this field value is greater
      (more recent) than the most recent Manifest it has validated.

And for the text in Section 5.1:

      Note: An RP MUST verify all mandated syntactic constraints, i.e.,
      constraints imposed on a CA via a "MUST".

      publication point that is described by the manifest.  (RPs are
      required to verify the CMS signature.)

4. ------

      nextUpdate time.  Each manifest encompasses a CRL, and the
      nextUpdate field of the manifest SHOULD match that of the CRL's
      nextUpdate field, as the manifest will be re-issued when a new CRL

FP: What are the exception cases where it is expected not to match (i.e. what is the reason for the SHOULD here)?

5. -----

  The RP MUST check that the current time (translated to UTC) is
  between thisUpdate and nextUpdate.  If the current time lies within

FP: I am not sure the parenthesis needs to be there - this seems like an unnecessary implementation detail.

# Nits

6. -----

  *  all published signed objects that are verifiable using EE

FP: Please expand all acronyms (EE, OID) on first use

7. -----

  termed a "one-time-use" EE certificate [RFC6487]

FP: missing period
2022-02-02
09 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2022-02-02
09 Zaheduzzaman Sarker
[Ballot comment]
Thanks for the efforts on this specification. It was a good read.

After reading the shepherd's writeup I was expecting an update to …
[Ballot comment]
Thanks for the efforts on this specification. It was a good read.

After reading the shepherd's writeup I was expecting an update to 6486 but the document actually obsoletes 6486. Something happened between when the shepherd writeup was written and when this doc went for publication, not captured. Not a big deal I guess, would have been better to get this captured.

Nits:

  Section 4.2.1 : "The issuer MUST ensure that the value of this field is more recent any previously-generated Manifest", missing "than" ?
2022-02-02
09 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2022-02-01
09 Murray Kucherawy
[Ballot comment]
The response to question 7 of the shepherd writeup doesn't really answer the question being asked.  Also, please tidy up the stuff identified …
[Ballot comment]
The response to question 7 of the shepherd writeup doesn't really answer the question being asked.  Also, please tidy up the stuff identified in the answer to question 11.

Section 4.2.1:

* "... this field is more recent any previously-generated ..." -- s/recent/recent than/

Appendix B:

* Since this is obsoleting, not updating, RFC 6486, I think this is more like "Changes Since RFC 6486".
2022-02-01
09 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2022-02-01
09 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2022-01-31
09 Benjamin Kaduk
[Ballot discuss]
It looks like we may have a setup where a compliant RP and compliant
CA/repository fail to interoperate.  This is sufficiently surprising that …
[Ballot discuss]
It looks like we may have a setup where a compliant RP and compliant
CA/repository fail to interoperate.  This is sufficiently surprising that
I want to confirm that it's the intended behavior.  In particular, both
manifests and CRLs have thisUpdate and nextUpdate fields, and since
issuing an update to one requires issuing an update to the other (though
the CRL is always actually generated first), it is only natural for us to
give guidance that the times in question should match between manifest and
corresponding CRL.  However, we do this only as RECOMMENDED/SHOULD-level
guidance, and accompany it by guidance to RPs that they SHOULD NOT reject
a manifest of the fields do not match the CRL.  Accordingly, when a CA
violates the first SHOULD and issues manifeset+CRL with mismatched
thisUpdate/nextUpdate, and an RP violates the second SHOULD (NOT) and
rejects such a setup, the RP will be unable to get any RPKI data for that
CA.  (As a tangent, we also have one place where we give related guidance
that the validity period of the single-use EE cert that signs the manifest
match the thisUpdate/nextUpdate period, which we might want to keep in
mind if we make any changes in this space.)

It looks like RFC 6486 had a conditional MUST-level requirement that *if* a
manifest encompasses a CRL, then the "nextUpdate" fields MUST match (no
guidance on thisUpdate), which we change to a statement of fact that each
manifest does encompass a CRL and guidance that the "nextUpdate"s SHOULD
match.
Additionally, RFC 6486 had a MUST-level requirement for the validity
period of the EE cert to exactly match the thisUpdate/nextUpdate time
interval of the manifest, which we currently are relaxing to a SHOULD.

Often in this scenario we would strengthen one of the SHOULDs to be a
MUST so that interoperability is guaranteed, but I'm not sure that I see a
clear argument for which requirement is better to make the MUST.
2022-01-31
09 Benjamin Kaduk
[Ballot comment]
My reading of the changes in the diff from RFC 6486 indicate that there is
something of a fundamental shift in the processing …
[Ballot comment]
My reading of the changes in the diff from RFC 6486 indicate that there is
something of a fundamental shift in the processing model being made, but
this does not seem to be mentioned specifically in the list of changes in
Appendix B (or the introduction/abstract).  Specifically, it seems that
the old RFC 6486 model involved the manifest being a tool that's useful
for the RP and SHOULD be used, but that ultimately the RP policy decides
which signed objects from the repository to use and fundamentally places
trust in the signatures on those objects; the new model in this draft
seems to place the manifest as the primary control on what signed objects
to use, with phrasing like "MUST use the current manifest"/"files not
listed on the manifest MUST NOT be used" and the error-handling behavior
in §6.6 being to fall back to the previous cached state (at a SHOULD-level
requirement), which as I understand it would mean using the previous
cached manifest.  (Maybe I'm wrong about that last bit.) While the new
focus doesn't seem problematic per se, and it's perfectly reasonable from
a process perspective to make that sort of behavior change in a Proposed
Standard, it seems that if this was a deliberate decision it ought to be
emphasized a bit more.  The final bullet point in the change list of
removing the notion of "local policy" is perhaps related to this
fundamental shift, but seems to only cover part of the shift.

Section 3

  The CA MUST sign only one manifest with each generated private key,
  and MUST generate a new key pair for each new version of the
  manifest.  This form of use of the associated EE certificate is
  termed a "one-time-use" EE certificate [RFC6487]

Not really a comment on *this* document (6486bis), but since RFC 6487
generically defines the "sequential use" EE certificate that we are
disallowing for RPKI Manifest use, it seems reasonable to ask whether the
issues that cause us to forbid sequential use in this context might also
apply to other scenarios where "sequential use" certificates might have
been used.  (I did not make a survey of the RPKI specification corpus to
investigate whether such scenarios are likely to exist.)

Section 4.2.1

  fileHashAlg:
      This field contains the OID of the hash algorithm used to hash the
      files that the authority has placed into the repository.  The hash
      algorithm used MUST conform to the RPKI Algorithms and Key Size
      Profile specification [RFC6485].

RFC 6485 has been obsoleted by RFC 7935.

Section 5.1

  2.  Issue an EE certificate for this key pair.  The CA MUST revoke
      the EE certificate used for the manifest being replaced.

Do the mechanics of revocation still need to be undertaken even if the EE
certificate in question has expired?

Section 6.x

The old RFC 6486 procedures allowed ("MAY") the RP to verify that each
file at a publication point is listed in exactly one current manifest,
which is no longer allowed.  I think I can see how this was a problematic
thing to try, but want to confirm that it is intentionally removed.

Similarly, RFC 6486 wanted a warning produced if there were objects
present in the repository that are not listed in any manifest, which does
not seem particularly useful and I do not mind seeing removed.

RFC 6486 also wanted a warning issued if a publication point contained
both valid and invalid manifests; removing that guidance seems correct to
me.

Section 6.3

The two "proceed to Section 6.4"s seem redundant (I suggest removing the
last one).

Section 6.5

  the publication point.  If the computed hash value of a file listed
  on the manifest does not match the hash value contained in the
  manifest, then the fetch has failed and the RP MUST proceed to
  Section 6.6; otherwise proceed to Section 6.6.

This looks an awful lot like "if X; goto Y; else; goto Y", which could
just be written as "goto Y".  However, since §6.6 is the "failed fetches"
processing, in the successful verification case perhaps we don't want to
do that and should instead proceed to use the content of the files listed
in the manifest.

Section 8

Perhaps it is sufficiently obvious so as to go without saying, but I trust
that in a prolonged period of failed fetches, the human operator is
expected to go figure out (via out of band channels) what's up with the
CA/repository in question and whether an attack is underway.

                            The requirement for every repository
  publication point to contain at least one manifest allows an RP to
  determine if the manifest itself has been occluded from view.  [...]

Do we want to say anything about how these properties change during a CA
key rollover or if multiple "unrelated" CAs are publishing at the same
publication point (the latter of which would be quite unusual, if I
understand correctly)?

Section 9

I see that the latest update from IANA has the registry (entry) references
being updated from RFC 6488 to [this document], which is great and
obviates what I would otherwise have remarked upon.

Section 11.1

Now that we're obsoleting RFC 6486, that should probably bump it off into
the Informative References section.

RFCs 6482, 6493, 8209, and 8488 appear to not actually be referenced
from anywhere and thus could probably be removed.

Section 11.2

Do we really want to reference RFC 3370 ("CMS Algorithms") for "the CMS
wrapper of the object" rather than something like RFC 5652 ("CMS")?
2022-01-31
09 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2022-01-31
09 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document.

Please find below one non-blocking COMMENT points.

Special thanks to Chris Morrow for the …
[Ballot comment]
Thank you for the work put into this document.

Please find below one non-blocking COMMENT points.

Special thanks to Chris Morrow for the shepherd's write-up including the section about the WG consensus (even if I would have appreciated a justification for the PS status).

I hope that this helps to improve the document,

Regards,

-éric

-- Abstract --
In "then the RP can detect "stale" (valid) data", is "valid" really the right word to use ? I would naively expect "invalid". Or is it just an indication that the data *was* valid and is stale? The use of "(.*)" in the abstract was more to explain the previous word and this use is different and could confuse the reader.
2022-01-31
09 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2022-01-28
09 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA OK - No Actions Needed
2022-01-28
09 Amanda Baber IANA will replace references to RFC 6486 at https://www.iana.org/assignments/rpki, https://www.iana.org/assignments/smi-numbers, and https://www.iana.org/assignments/media-types/application/rpki-manifest upon approval (author has confirmed).
2022-01-27
09 Cindy Morgan Placed on agenda for telechat - 2022-02-03
2022-01-27
09 Warren Kumari Ballot has been issued
2022-01-27
09 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2022-01-27
09 Warren Kumari Created "Approve" ballot
2022-01-27
09 Warren Kumari IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2021-12-30
09 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2021-12-28
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Linda Dunbar
2021-12-28
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Linda Dunbar
2021-12-23
09 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2021-12-23
09 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-sidrops-6486bis-09, which is currently in Last Call, and has the following comments:

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

The IANA Functions Operator has reviewed draft-ietf-sidrops-6486bis-09, 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.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist
2021-12-23
09 Jean Mahoney Request for Last Call review by GENART is assigned to Suhas Nandakumar
2021-12-23
09 Jean Mahoney Request for Last Call review by GENART is assigned to Suhas Nandakumar
2021-12-21
09 Stephen Kent New version available: draft-ietf-sidrops-6486bis-09.txt
2021-12-21
09 (System) New version approved
2021-12-21
09 (System) Request for posting confirmation emailed to previous authors: Geoff Huston , Matt Lepinski , Rob Austein , Stephen Kent
2021-12-21
09 Stephen Kent Uploaded new revision
2021-12-16
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Alan DeKok
2021-12-16
08 Tero Kivinen Request for Last Call review by SECDIR is assigned to Alan DeKok
2021-12-16
08 Cindy Morgan IANA Review state changed to IANA - Review Needed
2021-12-16
08 Cindy Morgan
The following Last Call announcement was sent out (ends 2021-12-30):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sidrops-6486bis@ietf.org, morrowc@ops-netman.net, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net …
The following Last Call announcement was sent out (ends 2021-12-30):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sidrops-6486bis@ietf.org, morrowc@ops-netman.net, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Manifests for the Resource Public Key Infrastructure (RPKI)) to Proposed Standard


The IESG has received a request from the SIDR Operations WG (sidrops) to
consider the following document: - 'Manifests for the Resource Public Key
Infrastructure (RPKI)'
  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 2021-12-30. 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


  This document defines a "manifest" for use in the Resource Public Key
  Infrastructure (RPKI).  A manifest is a signed object (file) that
  contains a listing of all the signed objects (files) in the
  repository publication point (directory) associated with an authority
  responsible for publishing in the repository.  For each certificate,
  Certificate Revocation List (CRL), or other type of signed objects
  issued by the authority that are published at this repository
  publication point, the manifest contains both the name of the file
  containing the object and a hash of the file content.  Manifests are
  intended to enable a relying party (RP) to detect certain forms of
  attacks against a repository.  Specifically, if an RP checks a
  manifest's contents against the signed objects retrieved from a
  repository publication point, then the RP can detect "stale" (valid)
  data and deletion of signed objects.




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



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


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8488: RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation (Informational - Internet Engineering Task Force (IETF))



2021-12-16
08 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2021-12-16
08 Warren Kumari Last call was requested
2021-12-16
08 Warren Kumari Last call announcement was generated
2021-12-16
08 Warren Kumari Ballot approval text was generated
2021-12-16
08 (System) Changed action holders to Warren Kumari (IESG state changed)
2021-12-16
08 Warren Kumari IESG state changed to Last Call Requested from Publication Requested
2021-12-16
08 Warren Kumari Ballot writeup was changed
2021-12-16
08 Stephen Kent New version available: draft-ietf-sidrops-6486bis-08.txt
2021-12-16
08 (System) New version approved
2021-12-16
08 (System) Request for posting confirmation emailed to previous authors: Geoff Huston , Matt Lepinski , Rob Austein , Stephen Kent
2021-12-16
08 Stephen Kent Uploaded new revision
2021-10-31
07 Chris Morrow
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(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

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


Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Technical Summary:
  (NOTE: This is an update to an existing RFC - RFC6486)
  "This document defines a "manifest" for use in the Resource Public Key
  Infrastructure (RPKI).  A manifest is a signed object (file) that
  contains a listing of all the signed objects (files) in the
  repository publication point (directory) associated with an authority
  responsible for publishing in the repository.  For each certificate,
  Certificate Revocation List (CRL), or other type of signed objects
  issued by the authority that are published at this repository
  publication point, the manifest contains both the name of the file
  containing the object and a hash of the file content.  Manifests are
  intended to enable a relying party (RP) to detect certain forms of
  attacks against a repository.  Specifically, if an RP checks a
  manifest's contents against the signed objects retrieved from a
  repository publication point, then the RP can detect "stale" (valid)
  data and deletion of signed objects."

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

There was quite a long and thorough discussion of this document in the WG. With a large sea change in management of the Manifest and publication-point data repositories proposed and agreed-upon by the group and authors.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

This is a -bis for an existing document, there is quite a bit of deployed infrastructure / implementations of the prior document, and most have now shifted to this new document as a response to some operational issues experienced in the field.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd - Chris Morrow (morrowc@ops-netman.net)
Responsible AD - Warren Kumari (warren@kumari.net)

(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 had extensive review, comment and improvement by the working group members, software implementers and systems operators.

(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 extra review required

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

All IPR claims have been previously claimed, no new IPR exists.
(I believe no IPR exists for the original, too)

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

yes.

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

I believe the consensus is pretty solid, more solid than most SIDROPS work, actually.

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

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

There are 2 nits errors:
  ** Obsolete normative reference: RFC 6485 (Obsoleted by RFC 7935)
  ** Downref: Normative reference to an Informational RFC: RFC 8488

There are 4 missing reference materials:

  == Unused Reference: 'RFC6482' is defined on line 639, but no explicit
    reference was found in the text
  == Unused Reference: 'RFC6493' is defined on line 659, but no explicit
    reference was found in the text
  == Unused Reference: 'RFC8209' is defined on line 667, but no explicit
    reference was found in the text
  == Unused Reference: 'RFC8488' is defined on line 673, but no explicit
    reference was found in the text

All of the above will be fixed prior to final version to the editor.

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

none required as near as I recall.

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

2 normative references, both are captured above as needing fixes.

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

nope

(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 is 1 downward reference, to: RFC 8488
this reference appears to be proper/appropriate.

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

It should update RFC6486

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

There are no new considerations to consider.

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

none.

(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, YANG modules, etc.

none.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

no.
2021-10-31
07 Chris Morrow Responsible AD changed to Warren Kumari
2021-10-31
07 Chris Morrow IETF WG state changed to Submitted to IESG for Publication from WG Document
2021-10-31
07 Chris Morrow IESG state changed to Publication Requested from I-D Exists
2021-10-31
07 Chris Morrow IESG process started in state Publication Requested
2021-10-31
07 Chris Morrow Changed consensus to Yes from Unknown
2021-10-31
07 Chris Morrow Intended Status changed to Proposed Standard from None
2021-10-31
07 Chris Morrow
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(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

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


Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Technical Summary:
  (NOTE: This is an update to an existing RFC - RFC6486)
  "This document defines a "manifest" for use in the Resource Public Key
  Infrastructure (RPKI).  A manifest is a signed object (file) that
  contains a listing of all the signed objects (files) in the
  repository publication point (directory) associated with an authority
  responsible for publishing in the repository.  For each certificate,
  Certificate Revocation List (CRL), or other type of signed objects
  issued by the authority that are published at this repository
  publication point, the manifest contains both the name of the file
  containing the object and a hash of the file content.  Manifests are
  intended to enable a relying party (RP) to detect certain forms of
  attacks against a repository.  Specifically, if an RP checks a
  manifest's contents against the signed objects retrieved from a
  repository publication point, then the RP can detect "stale" (valid)
  data and deletion of signed objects."

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

There was quite a long and thorough discussion of this document in the WG. With a large sea change in management of the Manifest and publication-point data repositories proposed and agreed-upon by the group and authors.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

This is a -bis for an existing document, there is quite a bit of deployed infrastructure / implementations of the prior document, and most have now shifted to this new document as a response to some operational issues experienced in the field.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Document Shepherd - Chris Morrow (morrowc@ops-netman.net)
Responsible AD - Warren Kumari (warren@kumari.net)

(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 had extensive review, comment and improvement by the working group members, software implementers and systems operators.

(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 extra review required

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

All IPR claims have been previously claimed, no new IPR exists.
(I believe no IPR exists for the original, too)

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

yes.

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

I believe the consensus is pretty solid, more solid than most SIDROPS work, actually.

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

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

There are 2 nits errors:
  ** Obsolete normative reference: RFC 6485 (Obsoleted by RFC 7935)
  ** Downref: Normative reference to an Informational RFC: RFC 8488

There are 4 missing reference materials:

  == Unused Reference: 'RFC6482' is defined on line 639, but no explicit
    reference was found in the text
  == Unused Reference: 'RFC6493' is defined on line 659, but no explicit
    reference was found in the text
  == Unused Reference: 'RFC8209' is defined on line 667, but no explicit
    reference was found in the text
  == Unused Reference: 'RFC8488' is defined on line 673, but no explicit
    reference was found in the text

All of the above will be fixed prior to final version to the editor.

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

none required as near as I recall.

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

2 normative references, both are captured above as needing fixes.

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

nope

(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 is 1 downward reference, to: RFC 8488
this reference appears to be proper/appropriate.

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

It should update RFC6486

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

There are no new considerations to consider.

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

none.

(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, YANG modules, etc.

none.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

no.
2021-10-31
07 Chris Morrow Notification list changed to morrowc@ops-netman.net because the document shepherd was set
2021-10-31
07 Chris Morrow Document shepherd changed to Chris Morrow
2021-10-14
07 Stephen Kent New version available: draft-ietf-sidrops-6486bis-07.txt
2021-10-14
07 (System) New version approved
2021-10-14
07 (System) Request for posting confirmation emailed to previous authors: Geoff Huston , Matt Lepinski , Rob Austein , Stephen Kent
2021-10-14
07 Stephen Kent Uploaded new revision
2021-07-26
06 Stephen Kent New version available: draft-ietf-sidrops-6486bis-06.txt
2021-07-26
06 (System) New version approved
2021-07-26
06 (System) Request for posting confirmation emailed to previous authors: Geoff Huston , Matt Lepinski , Rob Austein , Stephen Kent
2021-07-26
06 Stephen Kent Uploaded new revision
2021-07-08
05 Stephen Kent New version available: draft-ietf-sidrops-6486bis-05.txt
2021-07-08
05 (System) New version approved
2021-07-08
05 (System) Request for posting confirmation emailed to previous authors: Geoff Huston , Matt Lepinski , Rob Austein , Stephen Kent
2021-07-08
05 Stephen Kent Uploaded new revision
2021-06-01
04 Stephen Kent New version available: draft-ietf-sidrops-6486bis-04.txt
2021-06-01
04 (System) New version approved
2021-06-01
04 (System) Request for posting confirmation emailed to previous authors: Geoff Huston , Matt Lepinski , Rob Austein , Stephen Kent
2021-06-01
04 Stephen Kent Uploaded new revision
2020-11-30
03 Randy Bush New version available: draft-ietf-sidrops-6486bis-03.txt
2020-11-30
03 (System) New version approved
2020-11-30
03 (System) Request for posting confirmation emailed to previous authors: Geoff Huston , Matt Lepinski , Rob Austein , Stephen Kent
2020-11-30
03 Randy Bush Uploaded new revision
2020-11-02
02 Randy Bush New version available: draft-ietf-sidrops-6486bis-02.txt
2020-11-02
02 (System) New version approved
2020-11-02
02 (System) Request for posting confirmation emailed to previous authors: sidrops-chairs@ietf.org, Rob Austein , Matt Lepinski , Geoff Huston , Stephen Kent
2020-11-02
02 Randy Bush Uploaded new revision
2020-11-01
01 Randy Bush New version available: draft-ietf-sidrops-6486bis-01.txt
2020-11-01
01 (System) New version approved
2020-10-31
01 (System) Request for posting confirmation emailed to previous authors: Rob Austein , Stephen Kent , Geoff Huston , Matt Lepinski
2020-10-31
01 Randy Bush Uploaded new revision
2020-08-11
00 Rob Austein New version available: draft-ietf-sidrops-6486bis-00.txt
2020-08-11
00 (System) WG -00 approved
2020-08-11
00 Rob Austein Set submitter to "Rob Austein ", replaces to (none) and sent approval email to group chairs: sidrops-chairs@ietf.org
2020-08-11
00 Rob Austein Uploaded new revision