How to handle incorrectly-encoded public keys

[Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost>]

I recently ran into an SSH implementation that encodes its RSA public keys
incorrectly, specifically:

0000: 00 00 01 1A                                       // string server key
                  00 00 00 0C 72 73 61 2D 73 68 61 32   // string "rsa-sha2-256"
0016: 2D 32 35 36
                  00 00 00 01 03                        // e = 3 (!!!)
                                 00 00 01 01 00 CB 56   // n = ...
0032: 00 95 5B F0 BD 66 24 F5 2C 16 A2 CA 4E D8 5F 8C ..[..f$.,...N._.

RFC 8332 says:

   Since RSA keys are not dependent on the choice of hash function, the
   new public key algorithms reuse the "ssh-rsa" public key format as
   defined in [RFC4253]:

   string    "ssh-rsa"
   mpint     e
   mpint     n

   All aspects of the "ssh-rsa" format are kept, including the encoded
   string "ssh-rsa".  This allows existing RSA keys to be used with the
   new public key algorithms, without requiring re-encoding or affecting
   already trusted key fingerprints.

What are people doing when they see this incorrect encoding?

* Reject the key as invalid?

* Rewrite the key into the correct "ssh-rsa" form so that fingerprints still
  work?  This one is a pain to do because you need to shuffle data around and
  rewrite lengths in other locations.

* Accept the key in the incorrect "rsa-sha2-256" form with fingerprints
  breaking?

Peter.