Re: [Sidrops] [Technical Errata Reported] RFC9286 (7243)

> On 9 Nov 2022, at 18:06, Geoff Huston <gih@apnic.net> wrote:
> 
> Rejected from me.
> 
> 
>>> First of all: The previous text was not explicit that thisUpdate MUST contain the current time.
> 
> 
> ? "thisUpdate: This field contains the time when the manifest was created."
> 
> 
> I believe that this text an explicit statement to that effect, and does not contain an error.

I agree that the original text was clear, however, I would still incorporate it into the normative language.
> 
> 
>>> 
>>> Second, in practice (e.g. multiple calls to a synchronous API) multiple manifests can be issued with the same thisUpdate. Under the previous text this would technically be misissuance. The propose text allows multiple manifests to be issued in the same second.
> 
> 
> Yes,  multiple manifests issued at the same time will be rejected, according to the text in RFC 9286 and its predecessor RFC6486.

Could you please point me to the section of rfc6486 specifying this? I have trouble finding it.

> imho the proposed text does NOT correct an error in the original document. This proposed text proposes a different behaviour from the original text. This is therefore not an errata per se, but a proposed revision to the protocol’s described behaviour.

Thanks for your input.

Kind regards,
Ties
> 
> 
> Geoff
> 
> 
> 
> 
> 
> 
> 
>> On 8 Nov 2022, at 11:31 am, Job Snijders <job@fastly.com> wrote:
>> 
>> Dear all,
>> 
>> I would recommend this errata be marked Verified.
>> 
>> When the specification was authored, I don't think it occurred to anyone
>> that subscribers might end up hammering the APIs of CA implementations
>> prompting issuers to issue more the frequently than once per second.
>> 
>> Although it seems somewhat unlikely for Relying Parties to see multiple
>> manifests issued within the same second (subsequent updates to the same
>> location probably coalesce); however, if an RP is faced with multiple
>> valid manifests with identical validity windows, the monotonically
>> increasing manifestNumber remains the strong tie-breaker.
>> 
>> The Errata's suggestion to substitute 'MUST be more recent' with "MUST
>> be current time" combined with "must be equal or more recent" to me
>> seems to be in spirit with the objective of adhering to a linear forward
>> progression of time when issuing products.
>> 
>> Kind regards,
>> 
>> Job
>> 
>> On Mon, Nov 07, 2022 at 08:35:22AM -0800, RFC Errata System wrote:
>>> The following errata report has been submitted for RFC9286,
>>> "Manifests for the Resource Public Key Infrastructure (RPKI)".
>>> 
>>> --------------------------------------
>>> You may review the report below and at:
>>> https://www.rfc-editor.org/errata/eid7243
>>> 
>>> --------------------------------------
>>> Type: Technical
>>> Reported by: Ties de Kock <tdekock@ripe.net>
>>> 
>>> Section: 4.2.1.  Manifest
>>> 
>>> Original Text
>>> -------------
>>>  thisUpdate:
>>>     This field contains the time when the manifest was created.  This
>>>     field has the same format constraints as specified in [RFC5280]
>>>     for the CRL field of the same name.  The issuer MUST ensure that
>>>     the value of this field is more recent than any previously
>>>     generated manifest.  Each RP MUST verify that this field value is
>>>     greater (more recent) than the most recent manifest it has
>>>     validated.  If this field in a purported "new" manifest is smaller
>>>     (less recent) than previously validated manifests, the RP SHOULD
>>>     use locally cached versions of objects, as described in
>>>     Section 6.6.
>>> 
>>> Corrected Text
>>> --------------
>>>   thisUpdate:
>>>     This field contains the time when the manifest was created. This
>>>     field has the same format constraints as specified in [RFC5280]
>>>     for the CRL field of the same name. The issuer MUST ensure that
>>>     the value of this field is equal to the current time and higher or
>>>     equal to the thisUpdate of any previously generated manifest. Each
>>>     RP MUST verify that this field value is greater or equal to (as,
>>>     or more recent) than the most recent manifest it has validated.
>>>     Suppose this field in a purported "new" manifest is smaller (less
>>>     recent) than previously validated manifests. In that case, the RP
>>>     SHOULD use locally cached versions of objects, as described in
>>>     Section 6.6.
>>> 
>>> 
>>> 
>>> Notes
>>> -----
>>> First of all: The previous text was not explicit that thisUpdate MUST contain the current time.
>>> 
>>> Second, in practice (e.g. multiple calls to a synchronous API) multiple manifests can be issued with the same thisUpdate. Under the previous text this would technically be misissuance. The propose text allows multiple manifests to be issued in the same second.
>>> 
>>> Instructions:
>>> -------------
>>> This erratum is currently posted as "Reported". If necessary, please
>>> use "Reply All" to discuss whether it should be verified or
>>> rejected. When a decision is reached, the verifying party  
>>> can log in to change the status and edit the report, if necessary. 
>>> 
>>> --------------------------------------
>>> RFC9286 (draft-ietf-sidrops-6486bis-11)
>>> --------------------------------------
>>> Title               : Manifests for the Resource Public Key Infrastructure (RPKI)
>>> Publication Date    : June 2022
>>> Author(s)           : R. Austein, G. Huston, S. Kent, M. Lepinski
>>> Category            : PROPOSED STANDARD
>>> Source              : SIDR Operations
>>> Area                : Operations and Management
>>> Stream              : IETF
>>> Verifying Party     : IESG
>>> 
>>> _______________________________________________
>>> 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