Re: [Sidrops] trying to limit RP processing variability

[Stephen Kent <[e-mail]>]

Job,
> Dear Stephen,
>
> Thank you for spearheading this initiative. It is helpful to see the
> various permuations for which a decision tree needs to be constructed
> laid out in this way.
>
> On Fri, Apr 03, 2020 at 11:40:10AM -0400, Stephen Kent wrote:
>> *Terminology*
>>
>> Valid: a signed object (other than a certificate or CRL) is deemed
>> *valid* if it is encoded in a fashion consistent with the relevant
>> RPKI RFCs (i.e., 6482, 6486, 6487, 6488, 6493) and the signed object’s
>> signature can be verified consistent with RFC 6488.
>>
>> Current: A CRL or Manifest is *current* if the current date & time is
>> before the Next Update date and the CRLNumber (or ManifestNumber) is
>> greater than any prior, valid CRLs or Manifests processed by the RP.
>>
>> Stale: A CRL or Manifest is stale if the current date & time is later
>> than the Next Update date. A stale CRL or Manifest is not “expired”
>> it’s just not as current as it is supposed to be. The case analysis
>> below examines what to do when a Manifest, or CRL, or both are stale.
>>
>> Missing: an object named in a Manifest, but not available for download
>> from a PP, is termed *missing*. An RP has no obvious way to acquire
>> missing objects, but operators SHOULD be warned about which objects
>> are missing.
>>
>> Corrupted: if an object named in a Manifest, is available for download
>> from a PP, but it’s hash does not match the corresponding value in the
>> Manifest, the object is termed *corrupted* and the object SHOULD be
>> ignored.
> Can you also provide a definition for your use of the word 'invalid'? I
> see the phrase used in the case analysis permutations.

I would call a signed object invalid if it is syntactically broken 
(e.g., bad ASN.1 encoding), or if the signature cannot be validated as 
specified in RFC 6488. This is just another way of saying that it fails 
either of the  criteria cited in definition of *valid*.

Steve