[sidr] Terry Manderson's Discuss on draft-ietf-sidr-rpsl-sig-11: (with DISCUSS and COMMENT)

["Terry Manderson" <[e-mail]>]

Terry Manderson has entered the following ballot position for
draft-ietf-sidr-rpsl-sig-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for putting substantial effort into this document.

I have a few discusses. I hope they can be resolved quickly.

In Section 2.1. The reference to the aligned certificate  which has the
same private key that signed the RPSL object is mandatory, and defined by
a RSYNC URL or a HTTP(S) URL. My question surrounds the "or". The
architecture of RPKI (IIRC) is centered around RSYNC, and thus SIA/AIA
values MUST have a RSYNC URL, and MAY have other types. By this are you
leaving it to the issuing party to control the RPKI Distribution
mechanisms of the Replying Party? I am quite comfortable with "or"
personally, however this facet of fetching the RPSL Certificate to
validate the private key usage is seemingly orthogonal to the RPKI
architecture of RSYNC preferred and should be called out if 'or' is the
clear intention. Or, has the consensus of the WG moved on from being
wedded to RSYNC?

If it is truely "or", my observation is that the use of the RPKI
repository is one of  convenience, and that should be called out, in fact
it does appear that any valid certificate bearing RFC3779 extensions
could be used to validate the digital signature associated with the RPSL
object provided the relying party has trust anchor material that leads to
the corresponding EE certificate and therefore private key. Is this
observation correct?

The Signature expiration time field ("x") currently has no time
constraints, and I'm very surprised that it is optional with the text in
s2.5, given that the expiration time, by my reading, could not be beyond
the 'not after' time of the corresponding certificate. Can you please
instruct me as to what the consensus position on this was? A criticism of
many IRRs is that data becomes stale. have the signature expiration time
field could aide in data freshness models and reduce load on automated
import and validation of these RPSL signatures.

And lastly, IRRs tend to run over the (legacy?) whois port 43 that
doesn't provide channel layer security. This means that while signature
provide a means of detecting modification it may not stop a a MiTM event
where the entire object is omitted. Do you agree? if so that might be
appropriate for the Security Considerations section.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

one nit:

"MUST reject the signature and threat the object as a regular" I think
you mean `s/threat/treat`

Misc comments:

* Thank you for the very clear canonicalisation requirements!

* For route6 objects, where two resource holder's signatures considered
such that it might address the inability to properly sign the RPSL when
one holder possesses the ASN and another possesses the prefix? (just a
comment, nothing more)