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

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