Re: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-rsc-07.txt

[Russ Housley <[e-mail]>]

> On May 23, 2022, at 3:16 PM, Job Snijders <job=[e-mail]> wrote:
> 
> Dear all,
> 
> I'm slightly puzzled with the feedback and not entirely sure how to
> proceed. I'll try to summarize my understanding so far and re-iterate
> the direction the authors are trying to navigate towards.
> 
> I believe the ASN.1 module serves mainly two purposes: on the one hand
> it is a reference for programmers on what possible permutations might
> exist, and another use is to autogenerate code (through macros or an
> ASN.1 compiler) for use in signer/validator implementation.
> 
> With the above in mind, it seems prudent to codify as many constraints
> as possible in the ASN.1 module itself, rather than through 'decorative'
> (normative) text in the elaboration on what the ASN.1 notation means.
> 
> An example of what I mean with 'decorative text' is RFC 8209 section
> 3.1.3.5 which states "the 'inherit' element MUST NOT be specified."). I
> think constraints expressed through ASN.1 are somewhat stronger than
> what can be expressed in text for human consumption.
> 
> Context:
> ========
> 
> The draft-ietf-sidrops-rpki-rsc-06 spec did not accomodate encoding of
> inheritance and RDI (which seems accepted by this working group). Then
> some implementers asked for RSC to be more 'on the wire'-compatible with
> existing 3779 encoder/decoder higher level libcrypto functions, which
> they argued makes implementation easier. The result of these discussions
> was -07.
> 
> The -07 spec offers improved compatibility with existing 3779 functions,
> and still prohibits inheritance & RDI, and also removes the SAFI byte as
> the concept of SAFI seems not applicable to RSC. To the authors this
> seemed the best of all worlds: the voices displeased with -06 indicated
> contentment, and existing and new implementers would be able to use the
> RSC ASN.1 module from which it is clear what the constraints are.
> 
> But now, Russ, Randy, and George voice a concern about the SAFI octet!
> 
> To me it seems somewhat internally inconsistent to prohibit RDI &
> inheritance - but not the SAFI octet. Anyone encoding a SAFI octet in
> RSC eContent is creating a malformed object, subsequently a decode
> failure seems the preferred and expected outcome. Right?
> 
> Status update on running code: I believe there are three implementations
> known to adhere to the -07 format: a development version of OpenBSD
> rpki-client, Ben Maddison's rpkimancer, and Tom Harrison's RSC demo. 
> 
> options:
> 
>    1) revert back to -06 wireformat (3 implementations exist)
>    2) keep document as-is (3 implementations exist for -07)
>    3) permit SAFI byte to exist in the ASN.1 notation, add decorative
>       text that presence of SAFI octet MUST trigger failure.
>    4) ??? something I didn't think of ???
> 
> Feedback welcome!
> 
> Kind regards,
> 
> Job


Job:

Thanks for the clear explanation of the discussion to date.  I did not see anyone advocate for the inclusion of 'inherit' in the document.

I'm advocation for a one line change to the ASN.1 module:

OLD:

 addressFamily        OCTET STRING (SIZE (2)),

NEW:

 addressFamily        OCTET STRING (SIZE (2..3)),

My reason is that an implementer that has an implementation based on the RFC 3779 module might generate a 3 octet value.  While unexpected, I think that a decode failure is the wrong result.  In stead, the decode should succeed, then the recipient can decide whether to cause an error or to ignore the unexpected octet.

Russ