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

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

Hi Job,

> On 13 Jun 2023, at 10:55, Job Snijders <job=[e-mail]> wrote:
> 
> 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.

I agree with Martin's perception of the opinion of the group. Having the SET
may get us a little bit more implementation resiliency here.

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

I have implemented the current (draft 15) ASN.1 and requirements that yield a
deterministic form  for both validation and in a signer, but I do not mind
changing this to a SET.

Kind regards,
Ties