Re: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-06.txt

Howdy!
So, I think the 6486bis document authors are asking:
  "Go directly to WGLC, and please take Tim's question/comment as the
first comment in the WGLC"

Further to that I'll send a new WGLC start message... in a few moments :)

On Fri, Sep 24, 2021 at 9:07 AM Tim Bruijnzeels <tim@nlnetlabs.nl> wrote:

> Hi,
>
> > On 24 Sep 2021, at 13:54, Stephen Kent <stkent=
> 40verizon.net@dmarc.ietf.org> wrote:
> >
> > This version of the ID was published during the last IETF meeting, and
> has received no comments since then.
>
> Steve, thank you for your perseverance.
>
> I reviewed this once more. My apologies for not responding earlier.
>
> Thank you for clarifying (in -05) that the previous manifest MUST be
> revoked.
>
> What is still missing, I believe, is similar normative language when it
> comes to
> replacing existing other named files (ROA, certificates etc).
>
> If the working group feels that any replaced (non-CRL) files defined in the
> manifest scope MUST also be revoked if they are not expired then I think it
> would be good to include a sentence to this effect. Perhaps we could amend
> the
> start of the second paragraph of section 5.2:
>
> CURRENT:
>
>    An authority MUST issue a new manifest in conjunction with the
>    finalization of changes made to objects in the publication point.
>
> SUGGESTED:
>
>    An authority MUST issue a new manifest in conjunction with the
>    finalization of changes made to objects in the publication point.
>    If any named objects in the publication point were replaced then
>    the authority MUST ensure that the file hash is updated accordingly
>    in the new manifest. In addition to this the authority MUST revoke
>    the previous object, if it is of a type that can be revoked (i.e. not
>    a CRL) and it is not expired.
>
> Note that I made an argument earlier in favour of not revoking objects
> which
> section 6 now says MUST NOT be used anyway. But rather than trying to
> re-ignite,
> I have accepted people want redundancy, I am looking for clarity on all
> revocations so we don't end up with different interpretations again in
> future.
>
> Kind regards,
> Tim
>
> >
> > I'd like to initiate WGLC at this time.
> >
> > Steve
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >> This draft is a work item of the SIDR Operations WG of the IETF.
> >>
> >>         Title           : Manifests for the Resource Public Key
> Infrastructure (RPKI)
> >>         Authors         : Rob Austein
> >>                           Geoff Huston
> >>                           Stephen Kent
> >>                           Matt Lepinski
> >>      Filename        : draft-ietf-sidrops-6486bis-06.txt
> >>      Pages           : 17
> >>      Date            : 2021-07-26
> >>
> >> 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 IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/
> >>
> >> There is also an htmlized version available at:
> >> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-6486bis-06
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-6486bis-06
> >>
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
> >>
> >> _______________________________________________
> >> Sidrops mailing list
> >> Sidrops@ietf.org
> >> https://www.ietf.org/mailman/listinfo/sidrops
> >
> >
> > _______________________________________________
> > Sidrops mailing list
> > Sidrops@ietf.org
> > https://www.ietf.org/mailman/listinfo/sidrops
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops
>