[Sidrops] Why is the SKI field included in RFC8210(bis) Router Key PDUs?

[Job Snijders <[e-mail]>]

Hi all,

RFC 6487 section 4.8.2 specifies that SKIs are not arbitary identifiers:
an SKI must be the SHA-1 hash of the Subject Public Key (SPK). This is
expected in the deployed field: a number of RPKI RP implementations does
hash the SPK and compare it to the SKI contained within the certs's
X509v3 extensions. All the Internet's deployed RPKI CA certs have their
SKI set to match the SHA-1 hash of their SPK.

Section 5.10 of draft-ietf-sidrops-8210bis-10 notes: "Also note that it
is possible, albeit very unlikely, for multiple distinct Subject Public
Key values to hash to the same SKI." - This remark gave me pause for
thought, as SHA-1 chosen-prefix collision attacks nowadays are deemed
affordable.

Side note: in context of draft-ietf-sidrops-8210bis-10, the message
to-be-digested is a DER-encoded SPKI containing an ECDSA public key, and
in context of RFC 6487, the message to-be-digested is a DER-encoded RSA
2048-bit modulus (e) 65537 public key.

In context of RFC 6487 section 4.8.3 (AKIs), the authority's SPKI is not
available for comparison in the subordinate product. Also an RSA
signature does not contain a public key. Additionally, AIAs are
unreliable [1]. But RFC 7093 notes that second-preimage resistance is
not a required property of key identifiers, and indeed; I'd expect an RP
implementation to only add an authority to the chain of trusted
authorities if-and-only-if the subordinate authority's RSA signature
validates with the public key of the trusted authority whose SPKI SHA-1
hashes to the TBS AKI. OK, phew, problem avoided - as RSA isn't broken.

Draft-ietf-sidrops-8210bis-10, as a solution to collisions, suggests to
use the SPKI (aka the full ECDSA public key, rather than the SKI) as the
primary identifier for the information structure. Good suggestion.

My question is: why does the SHA-1 collision warning in
draft-ietf-sidrops-8210bis-10 exist? Or more specifically: why at all
bother including the SKI in the RTR PDU? Why not let the RTR client hash
the SPKI (if needed, as they deem fit)?

The SKI field in 8210bis Section 5.10 RTR Router Key PDUs seems
redundant, or am I missing something?

Kind regards,

Job

[1]: https://mailarchive.ietf.org/arch/msg/sidrops/wRa88GHsJ8NMvfpuxXsT2_JXQSU/