Oleg, I think this version is much better.
Yet I still have a question with Section Security Considerations: "In contrast, objects whose content hash matches the hash listed in the manifest, but that are not located in the publication directory listed in their CA certificate, will be used in the validation process (although a warning will be issued in that case).” Given these sorts of objects have been found somehow, in a different repository as described in Section 3.2.2. Manifest entries validation, your RP will take accept them anyway, using them in validation. What if this manifest is a stale one when the latest MFT has been deleted maliciously or inadvertently? A ROA found in a different repository may has been removed by the administrator and an attacker just replaces this ROA into that ‘different repository’ with poor management. There could be many risks here. I wonder why you take this approach. Di > 在 2016年7月9日，07:04，Oleg Muravskiy <[email protected]> 写道： > > This is an update to the draft-ietf-sidr-rpki-tree-validation. > > No major changes, mostly clarifications that address comments from Steve > Kent, and additional information as requested at the previous WG session. > Hope this version is more clear and close to final. > > > Oleg > > >> On 09 Jul 2016, at 00:51, [email protected] wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Secure Inter-Domain Routing of the IETF. >> >> Title : RPKI Certificate Tree Validation by a Relying Party >> Tool >> Authors : Oleg Muravskiy >> Tim Bruijnzeels >> Filename : draft-ietf-sidr-rpki-tree-validation-01.txt >> Pages : 12 >> Date : 2016-07-08 >> >> Abstract: >> This document describes the approach to validate the content of the >> RPKI certificate tree, as used by the RIPE NCC RPKI Validator. This >> approach is independent of a particular object retrieval mechanism. >> This allows it to be used with repositories available over the rsync >> protocol, the RPKI Repository Delta Protocol, and repositories that >> use a mix of both. >> >> This algorithm does not rely on content of repository directories, >> but uses the Authority Key Identifier (AKI) field of a manifest and a >> certificate revocation list (CRL) objects to discover manifest and >> CRL objects issued by a particular Certificate Authority (CA). It >> further uses the hashes of manifest entries to discover other objects >> issued by the CA. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-tree-validation/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-sidr-rpki-tree-validation-01 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-tree-validation-01 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> sidr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr >> > > _______________________________________________ > sidr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
