[Last-Call] Re: Dnsdir last call review of draft-ietf-sidrops-rpki-crl-numbers-03

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dear Geoff,

Thank you for your review, much appreciated.

On Sun, Mar 23, 2025 at 10:09:36PM -0700, Geoff Huston via Datatracker wrote:
> Reviewer: Geoff Huston
> Review result: Not Ready
> 
> There are a number of issues with this document.
> 
> 1. Introduction
> 
> "This document updates [RFC6487] with clarifications for RP implementers."
> 
> This is not a 'clarification' to the specification of CRL Number Extensions and
> Manifests, but a revision of the intended role of these two elements of the
> RPKI system. I suggest dropping the text "with clarifications for RP
> implementers"

OK, done.

> 1.2 Related Work.
> 
> It would be appropriate to also reference RFC 6486 (Manifests for the Resource
> Public Key Infrastructure (RPKI)) in the list of Related work.

Good catch! We've added RFC 9286 as a reference instead (because 6486
got obsoleted).

> 4. Security Considerations
> 
> This section contains the text: "This document clarifies that, in the RPKI,
> there is exactly one CRL appropriate and relevant for determining the
> revocation status of a given resource certificate.  It is the unique CRL object
> that is simultaneously:
> 
>    *  the target of the certificate's CRL Distribution Points extension,
>       and
> 
>    *  listed in the issuing CA's current Manifest FileList and has
>       matching hash (see Section 4.2.1 of [RFC9286])."
> 
> This does not appear to be a "Security Consideration. It is a
> commentary on the intended outcome when the changes to RFC6487 as
> listed in Section 2 are applied. This text should be inserted between
> current sections 1 and 2 as a new section 2, as it as informative
> description of the intent of the proposed changes.

We like this suggestion, the document reads better now. Thanks.

> In addition, there appears to be an implication that an RPKI
> certificate cannot be validated without recourse to the current
> manifest for the certificate's issuer to establish the current CRL to
> be used. This is an important consideration and should be explicitly
> noted in the document.

OK, this consideration has now been added.

> It also appears that this document contains a critical update to the
> certificate validation description of Section 7.2 of RFC 6487. This
> document should note that it updates RFC6487 Section 7.2, Step 5 and
> provide an updated wording of this step.

This has been added too.

Based on your review a new version has been uploaded, the diff can be
viewed here: https://author-tools.ietf.org/iddiff?url2=draft-ietf-sidrops-rpki-crl-numbers-04

A full version is here:
https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-crl-numbers-04.html

Please let us know your thoughts on these changes!

Kind regards,

Job

-- 
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux