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

From: Ties de Kock <[email-masked]>
Date: Thu, 31 Mar 2022 14:32:28 +0200

Hi all,

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
  * The eContentType and content-type signed attribute contain the correct OID.

Please let me know what you think.

Kind regards,

Ties

---

From: Job Snijders <[email-masked]>
Date: Thu, 31 Mar 2022 15:36:42 +0200

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.
> 

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

>   * The eContentType and content-type signed attribute contain the

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.

Kind regards,

Job

---

From: Ties de Kock <[email-masked]>
Date: Thu, 31 Mar 2022 17:49:53 +0200

Hi Job,

> On 31 Mar 2022, at 15:36, Job Snijders <[email-masked]> wrote:
> 
> Hi Ties,
> 
> Thanks for reviewing
> 

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.

> suffered from brevity, and more elaboration is useful? I'm somewhat

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

---

From: Job Snijders <[email-masked]>
Date: Thu, 31 Mar 2022 18:33:33 +0200

Dear Ties,

On Thu, Mar 31, 2022 at 05:49:53PM +0200, Ties de Kock wrote:
> 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.

A potential downside of repeating normative language from the Signed
Object Template RFC is that if there ever is an update to the template,
all the RFCs that duplicated the checklist also must be patched. But
it's worth a try to see if the spec seems improved if it is made a bit
more verbose.

Please feel free to suggest text to the document authors! :-)

The XML lives here: https://github.com/QratorLabs/ASPA

Kind regards,

Job