Re: [Sidrops] ASPA Validation section in draft-ietf-sidrops-aspa-profile-07

[Ties de Kock <[e-mail]>]

Hi Job,

> On 31 Mar 2022, at 15:36, Job Snijders <[e-mail]> wrote:
> 
> Hi Ties,
> 
> Thanks for reviewing
> 
> On Thu, Mar 31, 2022 at 02:32:28PM +0200, Ties de Kock wrote:
>> I just reviewed a parser/generator for the ASPA object profile, and I
>> realised that the ASPA validation section currently only includes a
>> single ASPA-specific validation step. I want to propose expanding this
>> section.
>> 
>> At a minimum, I would recommend that this section (also) lists checks
>> that ensure that:
>> 
>>  * The version is 0
> 
> I think this already is covered in the draft: § 3.1 states "The version
> number of the ASProviderAttestation MUST be v0."
> 
> The above type of text triggers RP developers to implement checks like
> these: https://github.com/openbsd/src/blob/326af693966ccfc600796f445a88b37549ae3e64/usr.sbin/rpki-client/roa.c#L276-L294

And if you want to be really strict, that clause is redundant as well. The
default value must not be present in a DER object, and from 6488#3.l it follows
that a non-DER object is invalid.

X.690 11.5 Set and sequence components with default value:
> The encoding of a set value or sequence value shall not include an encoding for
> any component value which is equal to its default value.

But my point here is that RPKI software is written by humans and that some level
of redundancy helps implementations to be closer to first-time-right.

>>  * The eContentType and content-type signed attribute contain the
>>  correct OID.
> 
> I think those aspects are covered through RFC 6488, specially § 2.1.3.1
> 
>   "The eContentType is an OID specifying the type of payload in this
>    signed object and MUST be specified by the Internet Standards Track
>    document that defines the object.
> 
>> Please let me know what you think.
> 
> Section 4 of draft-ietf-sidrops-aspa-profile seems to have taken
> inspiration from RFC 6493 (GBRs) and RFC 6482 (ROAs)'s section on
> validation, by referencing to RFC 6488. This makes for concise text.
> 
> Personally I think there is an advantage to making it very clear the
> RPKI signed object template model is followed, rather than (redundantly)
> outlining (a subset of) the full decision tree.
> 
> On the other hand, perhaps this type of section historically has
> suffered from brevity, and more elaboration is useful? I'm somewhat
> undecided.


I agree that it is good to be very clear that the RPKI signed object model is
followed. That is a key concept to understand when implementing.

However, there is a balance between trusting that the reader is aware of implicit
information and redundantly outlining processing steps. At this point in time I
feel like that there is a benefit to more explicitly list the MUSTs from the
other sections of the draft that we expect RPs to check.

Kind regards,
Ties