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

[Stephen Kent <[e-mail]>]

Tim,

I'll wait to see what other WG members suggest before making this 
change, but I do not see a problem with replacing the current test with 
your proposed revision.


Steve

>> Hi,
>>
>>> On 24 Sep 2021, at 13:54, Stephen Kent<stkent=[e-mail]>  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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/sidrops
>>> _______________________________________________
>>> Sidrops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/sidrops
>
>