Kdysi jsem si seriálu o SSH postěžoval, že pro klíče typu ECDSA, které OpenSSH preferuje, neexistuje podpora pro SSHFP záznamy. Toho se v den vydání chytil Ondřej Surý a téměř rok poté vyšlo i RFC 6594. Že dodnes není implementace ve vanilkovém SSH konformní s tímto RFC, přestože patche existují, to mě štve. Ale ještě víc mě naštvalo, když loni na podzim vyšlo OpenSSH 6.5 s podporou Ed25519 klíčů, přitom bez podpory SSHFP záznamů. A standard na sebe nechává čekat. The history book on the shelf, keeps always repeating itself… :(
ten dns zaznam je ovsem principalne spatne navrzeny uz id sveho vzniku.
kdyby to ondrej vzal za spravny konec, tak tu mame sshfp verze 2 a sshfp by bylo na ceste stat se osolete.
spravce mapovani by mel byt iana.
do mapy cisel by mely patrit v implementaci mandatorni algoritmy
mimo cisla by melo byt mozne poslat jeste standardizovany string opet spravovany iana popisujici volitelne implementace
melo by jit poslat nestandartni string oem/experimentalni implementace
Aha, o rozporu mezi Ed25519 a chybějící podporou pro odpovídající SSHFP jsem nevěděl.
Pamatuju si, že v TLS WG se dost bojovalo i o takovou drobnost, že Curve25519 má od první implementace wire-format souřadnic little-endian a to se nelíbilo lidem, co chtějí mít všechno v network order (big-endian).
Nakonec se to protáhlo na snahu standardizovat "formát na drátě" všech ECC.
Jen jako poznámka: NIST křivky mají standardizovaný wire-format s prvním bajtem určující jak je bod zapsán, pak data bodu:
Křivka Curve25519 je definována, aby nemusela používat znaménko (DH funkce ve větě 2.1 v původním paperu, link je v sekci "Na co je která křivka dobrá"). Bod v nekonečnu je validní bod na křivce, ale pro DH se nepoužívá.