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

From: Ties de Kock <[email-masked]>
Date: Fri, 23 Jun 2023 14:59:50 +0200

Hi all,

> On 13 Jun 2023, at 20:04, Ties de Kock <[email-masked]> wrote:
> 
> Hi Job,
> 
>> On 13 Jun 2023, at 10:55, Job Snijders <job=[email-masked]> 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.

I realised that I did not share an object for interoperability testing. I have
included a sample that is generated by a property test (so values are random) by
rpki-commons below.

rpki-commons generates and checks for version 1 with tag 0.

Kind regards,
Ties