RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata