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

[Job Snijders <[e-mail]>]

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