RFC Errata
Found 4 records.
Status: Verified (2)
RFC 4255, "Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints", January 2006
Source of RFC: secsh (sec)
Errata ID: 693
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Sam Weiler
Date Reported: 2006-02-10
Section 3.1 says:
The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
type and the fingerprint of the public host key.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| algorithm | fp type | /
It should say:
[not submitted]
Notes:
Section 3.1 has a packet format picture, and the upper row of bit
numbers seems to have been shifted to the left.
from pending
Errata ID: 6266
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jonathan Neuschäfer
Date Reported: 2020-08-26
Verifier Name: Benjamin Kaduk
Date Verified: 2020-08-30
Section 3.1.1 says:
This algorithm number octet describes the algorithm of the public
key. The following values are assigned:
Value Algorithm name
----- --------------
0 reserved
1 RSA
2 DSS
Reserving other types requires IETF consensus [4].
It should say:
This algorithm number octet describes the algorithm of the public
key. The following values are assigned:
Value Algorithm name
----- --------------
0 reserved
1 RSA
2 DSA
Reserving other types requires IETF consensus [4].
Notes:
The algorithm with value 2 is given as DSS in section 3.1.1, but as DSA in section 5
Status: Held for Document Update (1)
RFC 4255, "Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints", January 2006
Source of RFC: secsh (sec)
Errata ID: 6621
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Shane Kerr
Date Reported: 2021-06-25
Held for Document Update by: Benjamin Kaduk
Date Held: 2021-07-19
Section 3.2 says:
The RDATA of the presentation format of the SSHFP resource record
consists of two numbers (algorithm and fingerprint type) followed by
the fingerprint itself, presented in hex, e.g.:
host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890
The use of mnemonics instead of numbers is not allowed.
It should say:
The RDATA of the presentation format of the SSHFP resource record
consists of two numbers (algorithm and fingerprint type) followed by
the fingerprint itself, presented in hex, e.g.:
host.example. SSHFP 2 1 123456789abcdef67890123456789abcdef67890
The use of mnemonics instead of numbers is not allowed. Whitespace is
allowed within the hexadecimal text.
Notes:
Many (most?) other DNS RFC's, for example RFC 4034, explicitly mention that whitespace is allowed in such encoded fields, whether hex or base64. RFC 4255 does not address this, so can be interpreted either way. For consistency and ease of implementation, I recommend allowing whitespace.
My proposed corrected text was copied verbatim from RFC 4034, and could possibly be edited to match the RFC 4255 text better, for example using "hex" instead of "hexadecimal text".
Status: Rejected (1)
RFC 4255, "Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints", January 2006
Source of RFC: secsh (sec)
Errata ID: 6267
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jonathan Neuschäfer
Date Reported: 2020-08-26
Rejected by: Benjamin Kaduk
Date Rejected: 2020-08-30
Throughout the document, when it says:
It should say:
Updated by: 6594, 7479, 8709
Notes:
RFCs 6594, 7479, 8709 update the IANA registries "SSHFP RR Types for public key algorithms" and "SSHFP RR type for fingerprint types", that were originally described in RFC 4255. These RFCs thus (arguably) update RFC 4255. It would be helpful to have such an "Updated by" noticed in the header of RFC 4255.
--VERIFIER NOTES--
Arguably, those RFCs do not update RFC 4255, given that much of the point of having an IANA registry is to be able to allocate new values without updating the original document. I do not believe there is a convention of using an Updates relationship solely to indicate that a codepoint has been allocated from an IANA registry.