On 09/30/2014 10:47 AM, Tim Ruehsen wrote: > 1. if e.g. --ssh-style-verification is given on the command line (or within > wgetrc). > > 2. --no-check-certificate is given AND the cert check (which we always > perform) fails AND wget is in 'interactive mode' (isatty()==true).
Of these two, i think i prefer 1 (the option could just be --tofu or
something), where the TOFU behavior kicks in only if the certificate
doesn't validate on the X.509 chain.
I guess a couple other corner cases are worth considering:
Are we OK with accepting a cert that validates via X.509 if a different
pubkey is found in the TOFU store? I think so; we could add an
additional flag that makes a matched-TOFU-hostname-but-different-pubkey
scenario a failed validation, but that seems like follow-on work.
In the context of a failed X.509 validation, and the peer's offered key
isn't found in the TOFU store, do we want to behave differently when a
different key is found for the peer in the TOFU store?
Do we want the user to be able to add more than one key to the TOFU
store for a given <host,service> pair?
--dkg
signature.asc
Description: OpenPGP digital signature
