RFC Errata
Found 8 records.
Status: Verified (6)
RFC 5906, "Network Time Protocol Version 4: Autokey Specification", June 2010
Source of RFC: ntp (int)
Errata ID: 6402
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2021-01-20
Verifier Name: Erik Kline
Date Verified: 2022-07-27
Section Appendix J says:
CertificateSerialNumber SET { ::= INTEGER Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime } }
It should say:
CertificateSerialNumber ::= INTEGER Validity ::= SEQUENCE { notBefore UTCTime, notAfter UTCTime }
Notes:
The original ASN.1 will not compile.
Errata ID: 3345
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: liyh
Date Reported: 2012-09-12
Verifier Name: Brian Haberman
Date Verified: 2012-09-12
Section 5 says:
Certificate exchange.[...]Completion of this exchange lights the VAL bit as described below.
It should say:
Certificate exchange.[...]Completion of this exchange lights the CERT bit as described below.
Errata ID: 3346
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: liyh
Date Reported: 2012-09-12
Verifier Name: Brian Haberman
Date Verified: 2012-09-12
Section 5 says:
Identity exchange.[...] Completion of this exchange lights the IFF bit as described below.
It should say:
Identity exchange.[...] Completion of this exchange lights the VRFY bit as described below.
Errata ID: 3349
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: liyh
Date Reported: 2012-09-12
Verifier Name: Brian Haberman
Date Verified: 2012-09-12
Section 5 says:
Leapseconds exchange. [...]Completion of this exchange lights the LPT bit as described below.
It should say:
Leapseconds exchange. [...]Completion of this exchange lights the LEAP bit as described below.
Notes:
refer to 11.1
Errata ID: 4026
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Tal Mizrahi
Date Reported: 2014-06-25
Verifier Name: Brian Haberman
Date Verified: 2014-07-01
Section 10 says:
One or more extension fields follow the NTP packet header and the last followed by the MAC. The extension field parser initializes a pointer to the first octet beyond the NTP packet header and calculates the number of octets remaining to the end of the packet. If the remaining length is 20 (128-bit digest plus 4-octet key ID) or 22 (160-bit digest plus 4-octet key ID), the remaining data are the MAC and parsing is complete. If the remaining length is greater than 22, an extension field is present. If the remaining length is less than 8 or not a multiple of 4, a format error has occurred and the packet is discarded; otherwise, the parser increments the pointer by the extension field length and then uses the same rules as above to determine whether a MAC is present or another extension field.
It should say:
One or more extension fields follow the NTP packet header and the last followed by the MAC. The extension field parser initializes a pointer to the first octet beyond the NTP packet header and calculates the number of octets remaining to the end of the packet. If the remaining length is 20 (128-bit digest plus 4-octet key ID) or 24 (160-bit digest plus 4-octet key ID), the remaining data are the MAC and parsing is complete. If the remaining length is greater than 24, an extension field is present. If the remaining length is less than 8 or not a multiple of 4, a format error has occurred and the packet is discarded; otherwise, the parser increments the pointer by the extension field length and then uses the same rules as above to determine whether a MAC is present or another extension field.
Notes:
The original text stated that a MAC is present if the remaining length is 20 octets or 22 octets. This was a typo; the correct statement is that a MAC is present if the remaining length is 20 octets or *24 octets*.
Errata ID: 8204
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: RFC Editor
Date Reported: 2024-12-06
Verifier Name: RFC Editor
Date Verified: 2024-12-06
Table of Contents
13. IANA Considerations ...........................................42 13. References ....................................................42 13.1. Normative References .....................................42 13.2. Informative References ...................................43
It should say:
13. IANA Considerations ...........................................42 14. References ....................................................42 14.1. Normative References .....................................42 14.2. Informative References ...................................43
Notes:
Repeated Section 13 in the Table of Contents. (14 is correctly numbered in the body of the document.)
Status: Held for Document Update (1)
RFC 5906, "Network Time Protocol Version 4: Autokey Specification", June 2010
Source of RFC: ntp (int)
Errata ID: 3348
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: liyh
Date Reported: 2012-09-12
Held for Document Update by: Brian Haberman
Section 5 says:
Autokey exchange.[...]Completion of this exchange lights the AUT bit as described below.
It should say:
Autokey exchange.[...]Completion of this exchange lights the AUTO bit as described below.
Status: Rejected (1)
RFC 5906, "Network Time Protocol Version 4: Autokey Specification", June 2010
Source of RFC: ntp (int)
Errata ID: 3347
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: liyh
Date Reported: 2012-09-12
Rejected by: Brian Haberman
Date Rejected: 2012-09-12
Section 5 says:
Cookie exchange. The request includes the public key of the server.The response includes the server cookie encrypted with this key.
It should say:
I don't know.
Notes:
how to decrypt?
--VERIFIER NOTES--
The decryption is carried out with the private key.