Re: [Sidrops] I-D Action: draft-ietf-sidrops-aspa-profile-15.txt

[Job Snijders <[e-mail]>]

On Tue, Jun 13, 2023 at 03:01:56PM +0200, Martin Hoffmann wrote:
> Russ Housley wrote:
> > I do not think we want to have decode failures if the INTEGERS are
> > not in sort order.
> 
> I agree, but in the past the consensus in this group has been to
> rigorously reject objects that have something wrong with them. By that
> consensus, an ASPA with unsorted provider ASNs would be rejected on
> grounds of violating the MUST further down. In which case it might as
> well be rejected during decoding.

It seems not every deserializer implementation rejects DER during
decoding if the DER contains a SET OF (unsorted, duplicate) INTEGERS.

Example:

$ echo 310f020107020102020109020107020103 | xxd -r -ps | openssl asn1parse -inform DER
    0:d=0  hl=2 l=  15 cons: SET
    2:d=1  hl=2 l=   1 prim: INTEGER           :07
    5:d=1  hl=2 l=   1 prim: INTEGER           :02
    8:d=1  hl=2 l=   1 prim: INTEGER           :09
   11:d=1  hl=2 l=   1 prim: INTEGER           :07
   14:d=1  hl=2 l=   1 prim: INTEGER           :03
$ echo $?
0

I suspect the trouble for the deserializer in the above example is that
there is ambiguity in the input data: what encoding rules apply?

With relying parties being unable to rely on (potentially missing)
implicit behaviour of decoders, it seems better to me to specify the
structure of the ASPA eContent data using a SEQUENCE OF, and be explicit
in describing the canonical form. This will help avoid potential
inconsistencies between implementations.

Kind regards,

Job