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 |