[dtn] IPN update text-form and CBOR-form parity with allocator zero

[Brian Sipos <[e-mail]>]

Authors of ipn-update draft,
There is a nuance to the text form specified in Appendix A [1] that
prohibits a zero-valued allocator component so that the zero-allocator can
only be represented by the two-component text form. This is in contrast to
the CDDL definition in Appendix C which does allow a zero-valued allocator
component.

A side-effect of this is that there is not a one-to-one correspondence
between text-form and CBOR-form EIDs. Certainly the semantic meaning is the
same between a zero-allocator three-component form and the two-component
form, but the lack of exact correspondence means that a trivial transcoder
needs to have some special cases for this situation. This can be seen in
the discrepancy between EIDs present in Appendix B.1 vs. D.1 and B.3 vs.
D.3. It also means that not all IPN-scheme EIDs can be written in a
three-component canonical form.

Because of this, it is possible that a CBOR-to-text-to-CBOR conversion will
lose information and the output will be different than the input. This will
have implications for things that require guarantees about re-encodings
such as BPSec processing.

I think a simple change in Appendix A from

allocator-identifier = non-zero-number

to

allocator-identifier = number

will resolve this in a way that probably is compatible with existing
three-component EID codec implementations anyway.

This also calls into question the single statement in Section 8.3; there
should probably be a stronger security statement and a requirement that
implementations must preserve the component count when transcoding IPN EIDs.

Apologies for this late feedback, but I think it will avoid a subtle
security issue and potential user headaches.

- Brian S.

[1]
https://www.ietf.org/archive/id/draft-ietf-dtn-ipn-update-10.html#appendix-A