[ { "errata_id": "495", "doc-id": "RFC2119", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "1", "orig_text": "1. MUST This word, or the terms \"REQUIRED\" or \"SHALL\", mean that the\r\n definition is an absolute requirement of the specification.\r\n\r\n", "correct_text": "1. MUST This word, or the terms \"REQUIRED\" or \"SHALL\", means that the\r\n definition is an absolute requirement of the specification.\r\n", "notes": " \r\n", "submit_date": "2001-05-31", "submitter_name": "Davidson, Malcolm", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03" }, { "errata_id": "150", "doc-id": "RFC4271", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "9.1.1", "orig_text": "The Phase 1 decision function is a separate process,f which completes \r\nwhen it has no further work to do.", "correct_text": "The Phase 1 decision function is a separate process, which completes \r\nwhen it has no further work to do.\r\n", "notes": "Clearly an editorial issue with a stray \"f\" in there. \r\n", "submit_date": "2006-01-26", "submitter_name": "Nikolai Malykh", "verifier_id": "", "verifier_name": "Ketan Talaulikar", "update_date": "2025-05-28 12:09:55" }, { "errata_id": "496", "doc-id": "RFC2119", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6", "orig_text": " In particular, they MUST only be used where it is actually required\n for interoperation or to limit behavior which has potential for\n causing harm (e.g., limiting retransmisssions) For example, they\n must not be used to try to impose a particular method on\n implementors where the method is not required for interoperability. ", "correct_text": " In particular, they MUST only be used where it is actually required\n for interoperation or to limit behavior which has potential for\n causing harm (e.g., limiting retransmissions). For example, they\n must not be used to try to impose a particular method on\n implementors where the method is not required for interoperability.\n", "notes": "", "submit_date": "2001-01-31", "submitter_name": "Kurt Zeilenga", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03" }, { "errata_id": "493", "doc-id": "RFC2119", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "1", "orig_text": "2. MUST NOT This phrase, or the phrase \"SHALL NOT\", mean that the\r\n definition is an absolute prohibition of the specification.", "correct_text": "2. MUST NOT This phrase, or the phrase \"SHALL NOT\", means that the\r\n definition is an absolute prohibition of the specification.\r\n", "notes": "", "submit_date": "2001-05-31", "submitter_name": "Davidson, Malcolm", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03" }, { "errata_id": "494", "doc-id": "RFC2119", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "6", "orig_text": "(e.g., limiting retransmisssions)", "correct_text": "(e.g., limiting retransmissions)", "notes": "", "submit_date": "2001-05-31", "submitter_name": "Davidson, Malcolm", "verifier_id": "", "verifier_name": "RFC Editor", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "497", "doc-id": "RFC2119", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "", "orig_text": "3. SHOULD This word, or the adjective \"RECOMMENDED\", mean that there\r\n may exist valid reasons in particular circumstances to ignore a\r\n particular item, but the full implications must be understood and\r\n carefully weighed before choosing a different course.\r\n\r\n4. SHOULD NOT This phrase, or the phrase \"NOT RECOMMENDED\" mean that\r\n there may exist valid reasons in particular circumstances when the\r\n particular behavior is acceptable or even useful, but the full\r\n implications should be understood and the case carefully weighed\r\n before implementing any behavior described with this label.", "correct_text": "3. SHOULD This word, or the adjective \"RECOMMENDED\", mean that there\r\n may exist valid reasons in particular circumstances to ignore a\r\n particular item, but the full implications should be understood and\r\n carefully weighed before choosing a different course.\r\n\r\n4. SHOULD NOT This phrase, or the phrase \"NOT RECOMMENDED\" mean that\r\n there may exist valid reasons in particular circumstances when the\r\n particular behavior is acceptable or even useful, but the full\r\n implications should be understood and the case carefully weighed\r\n before implementing any behavior described with this label.", "notes": "OR should say:\r\n 3. SHOULD This word, or the adjective \"RECOMMENDED\", mean that there\r\n may exist valid reasons in particular circumstances to ignore a\r\n particular item, but the full implications is understood and\r\n carefully weighed before choosing a different course.\r\n\r\n4. SHOULD NOT This phrase, or the phrase \"NOT RECOMMENDED\" mean that\r\n there may exist valid reasons in particular circumstances when the\r\n particular behavior is acceptable or even useful, but the full\r\n implications should be understood and the case carefully weighed\r\n before implementing any behavior described with this label.\r\n\r\n\r\nThe change request is \"must\" to \"should\".\r\nIt may be self definition.\r\nFor the balance of SHOULD and SHOULD NOT , it should use \"should\", not\r\n\"must\". \n --VERIFIER NOTES-- \nThe full implications MUST be understood in order to ignore a \"SHOULD\" or \"SHOULD NOT\" statement in a specification. ", "submit_date": "2006-07-10", "submitter_name": "Kiyoshi Ogawa", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "498", "doc-id": "RFC2119", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "1", "orig_text": "4. SHOULD NOT This phrase, or the phrase \"NOT RECOMMENDED\" mean that\r\n there may exist valid reasons in particular circumstances when the\r\n particular behavior is acceptable or even useful, but the full\r\n implications should be understood and the case carefully weighed\r\n before implementing any behavior described with this label.", "correct_text": "4. SHOULD NOT This phrase, or the phrase \"NOT RECOMMENDED\", means that\r\n there may exist valid reasons in particular circumstances when the\r\n particular behavior is acceptable or even useful, but the full\r\n implications should be understood and the case carefully weighed\r\n before implementing any behavior described with this label.\r\n", "notes": "", "submit_date": "2001-05-31", "submitter_name": "Davidson, Malcolm", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03" }, { "errata_id": "499", "doc-id": "RFC2119", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "Abstract", "orig_text": " The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL\r\n NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and\r\n \"OPTIONAL\" in this document are to be interpreted as described in\r\n RFC 2119.", "correct_text": " The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL\r\n NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"NOT \r\n RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this document are to \r\n be interpreted as described in RFC 2119.", "notes": "The phrase \"NOT RECOMMENDED\" is missing from this sentence.", "submit_date": "2006-01-09", "submitter_name": "Anders Langmyr", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "500", "doc-id": "RFC2119", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "1", "orig_text": "3. SHOULD This word, or the adjective \"RECOMMENDED\", mean that there\r\n may exist valid reasons in particular circumstances to ignore a\r\n particular item, but the full implications must be understood and\r\n carefully weighed before choosing a different course.", "correct_text": "3. SHOULD This word, or the adjective \"RECOMMENDED\", means that there\r\n may exist valid reasons in particular circumstances to ignore a\r\n particular item, but the full implications must be understood and\r\n carefully weighed before choosing a different course.\r\n", "notes": "", "submit_date": "2001-05-31", "submitter_name": "Davidson, Malcolm", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03" }, { "errata_id": "2390", "doc-id": "RFC5246", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "6.2.3.3", "orig_text": " The additional authenticated data, which we denote as\r\n additional_data, is defined as follows:\r\n\r\n additional_data = seq_num + TLSCompressed.type +\r\n TLSCompressed.version + TLSCompressed.length;\r\n\r\n where \"+\" denotes concatenation.\r\n\r\n The aead_output consists of the ciphertext output by the AEAD\r\n encryption operation. The length will generally be larger than\r\n TLSCompressed.length, but by an amount that varies with the AEAD\r\n cipher. Since the ciphers might incorporate padding, the amount of\r\n overhead could vary with different TLSCompressed.length values. Each\r\n AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes.\r\n Symbolically,", "correct_text": " The additional authenticated data, which we denote as\r\n additional_data, is defined as follows:\r\n\r\n additional_data = seq_num + TLSCompressed.type +\r\n TLSCompressed.version + TLSCompressed.length;\r\n\r\n where \"+\" denotes concatenation.\r\n\r\n The aead_output consists of the ciphertext output by the AEAD\r\n encryption operation. The length will generally be larger than\r\n TLSCompressed.length, but by an amount that varies with the AEAD\r\n cipher. Each AEAD cipher MUST NOT produce an expansion of greater\r\n than 1024 bytes. Symbolically,", "notes": "I suggest leaving the sentence about padding out. The value for TLSCompressed.length is required by additional_data for both encryption and decryption. Therefore, it must be possible to determine the TLSCompressed.length from the ciphertext before decryption.\r\n\r\nIn practice this is done by subtracting the integrity check value length from the ciphertext length, where the integrity check value length is defined by each AEAD cipher separately. If the cipher incorporates variable padding, it is impossible to calculate the TLSCompressed.length without an explicit value sent for each ciphertext separately. Therefore to avoid confusion, it would be better not to mention anything about padding at all.\r\n\r\n(issue discussed on tls@ietf.org and with Eric Rescorla, result of both discussions was that padding in AEAD ciphers doesn't seem to be possible with the current specification)", "submit_date": "2010-07-23", "submitter_name": "Juho Vähä-Herttua", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "7661", "doc-id": "RFC5280", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3.5", "orig_text": " (g) cross-certification: Two CAs exchange information used in\r\n establishing a cross-certificate. A cross-certificate is a\r\n certificate issued by one CA to another CA that contains a CA\r\n signature key used for issuing certificates.", "correct_text": " (g) cross-certification: Two CAs exchange information used in\r\n establishing a cross-certificate.", "notes": "The removed sentence is factually inaccurate and misleading: \"A cross-certificate is a certificate issued by one CA to another CA that contains a CA signature key used for issuing certificates.\" \r\nA \"signature key used for issuing certificates\" would be a private key. A certificate simply does not contain a private key. A definition of \"cross-certificate\" for the purpose of this RFC is already provided in section 3.2, so there is no point in elaborating here. \r\n(The definition given in section 3.2 conflicts with the narrower, and more generally used, definition given in RFC 4949, but that is beside the point.)", "submit_date": "2023-09-28", "submitter_name": "Benjamin Strauss", "verifier_id": "", "verifier_name": "Deb Cooley", "update_date": "2024-10-29 15:17:30" }, { "errata_id": "2838", "doc-id": "RFC4271", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8.2.2", "orig_text": "on page 72, description of the Established state:\r\n\r\nIf the HoldTimer_Expires event occurs (Event 10), the local system:\r\n ...[list of actions to take]...", "correct_text": "If the HoldTimer_Expires event occurs (Event 10), the local system:\r\n - deletes all routes associated with this connection\r\n ...[list of actions in original text]...\r\n", "notes": "All other transitions from Established to Idle explicitly state that all routes associated with the connection are deleted. This transition should as well.", "submit_date": "2011-06-16", "submitter_name": "Jamie Taylor", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "1005", "doc-id": "RFC5065", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "", "orig_text": "(1) obsolete reference tag - #1\r\n\r\nApparently, some reference tags have not been updated when the\r\n'References' Section (10.) has been modified to incorporate\r\ncurrent versions of the relevant documents.\r\n\r\nThe second paragraph of Section 1, on page 3 of RFC 5065, says:\r\n\r\n This scaling problem has been well documented and a number of\r\n| proposals have been made to alleviate this, such as [RFC2796] and\r\n [RFC1863] (made historic by [RFC4223]). [...]\r\n\r\nRFC 2796 has been obsoleted by RFC 4456, and Section 10.2 only\r\ncontains an entry for [RFC4456], which is only used in the\r\nsecond paragraph of Section 2, but no entry for [RFC 2796].\r\n\r\nTherefore, the above sentence should better say:\r\n\r\n This scaling problem has been well documented and a number of\r\n| proposals have been made to alleviate this, such as [RFC4456] and\r\n [RFC1863] (made historic by [RFC4223]). [...]\r\n\r\nor, if you prefer, for the sake of historical precision:\r\n\r\n This scaling problem has been well documented and a number of\r\n| proposals have been made to alleviate this, such as [RFC4456]\r\n| (first version published in [RFC 2796]) and [RFC1863] (made historic\r\n by [RFC4223]). [...]\r\n\r\nFor the latter variant, an entry for [RFC2796] must be restored into\r\nSection 10.2, as well.\r\n\r\n\r\n(2) sluggish / imprecise language\r\n\r\nThe third paragraph of Section 4, at the bottom of page 5, says:\r\n\r\n A BGP speaker receiving an AS_PATH attribute containing an autonomous\r\n| system matching its own AS Confederation Identifier SHALL treat the\r\n path in the same fashion as if it had received a path containing its\r\n own AS number.\r\n\r\nPreferably, the text should not mess up the terms 'autonomous system'\r\nand 'autonomous system number'.\r\nThus, it should say:\r\n\r\n A BGP speaker receiving an AS_PATH attribute containing an autonomous\r\n| system number matching its own AS Confederation Identifier SHALL\r\n treat the path in the same fashion as if it had received a path\r\n containing its own AS number.\r\n\r\n\r\n(3) misleading specification, with bad wording\r\n\r\nIn Section 4.1, the bullets b) 1) (on page 6) and c) 2) (on page 7)\r\nhave been amended by instructions for the case of AS_PATH segment\r\noverflow. Although the details of the action necessary according\r\nto the spirit of BGP differ in a small, but important way, the\r\nsame wording is used in both cases. That might be very misleading.\r\nI propose to explicitely specify the AS number to be inserted in\r\nboth cases, using the terms defined in Section 1.2.\r\n\r\nFurthermore, the word 'prepend' is abused in the last part of the\r\namendments and might even be misleading.\r\nI propose to use 'include' in there, as the text already does in\r\nsimilar context, for instance in the immediately subsequent bullets.\r\n\r\nTherefore, the text in bullet b) 1) (on page 6),\r\n\r\n [...]. If the act of prepending will cause an\r\n overflow in the AS_PATH segment (i.e., more than 255 ASs), it\r\n SHOULD prepend a new segment of type AS_CONFED_SEQUENCE and\r\n| prepend its own AS number to this new segment.\r\n ^^^^^^^ ^^^^^^^^^ ^^\r\nshould say:\r\n\r\n [...]. If the act of prepending will cause an\r\n overflow in the AS_PATH segment (i.e., more than 255 ASs), it\r\n SHOULD prepend a new segment of type AS_CONFED_SEQUENCE and\r\n| include its own Member-AS number in this new segment.\r\n ^^^^^^^ ^^^^^^^^^^^^^^^^ ^^\r\n\r\nSimilarly, the identical text in bullet c) 2) (on page 7),\r\n\r\n [...]. If the act of prepending will cause an\r\n overflow in the AS_PATH segment (i.e., more than 255 ASs), it\r\n| SHOULD prepend a new segment of type AS_SEQUENCE and prepend\r\n| its own AS number to this new segment.\r\n ^^^^^^^^^ ^^ ^^^^^^^\r\n\r\nshould say:\r\n\r\n [...]. If the act of prepending will cause an\r\n overflow in the AS_PATH segment (i.e., more than 255 ASs), it\r\n| SHOULD prepend a new segment of type AS_SEQUENCE and include\r\n| its own AS Condeferation Identifier in this new segment.\r\n ^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^ ^^^^^^^\r\n\r\n(4) textual enhancement\r\n\r\nStill in Section 4.1, in the lower half of pgae 7, the bullets a) and\r\nb) under headline:\r\n\r\n When a BGP speaker originates a route then:\r\n\r\ndeal with similar cases using (almost) similar wording.\r\nBullet b) says:\r\n\r\n b) the originating speaker includes its own Member-AS Number in a\r\n path segment, of type AS_CONFED_SEQUENCE, in the AS_PATH attribute\r\n of all UPDATE messages sent to BGP speakers located in neighboring\r\n| Member Autonomous Systems that are members of the local\r\n confederation. [...]\r\n\r\nTo finalize the similarity, and to remove the unnecessary repetition\r\nof the word 'member', it would perhaps have been better to say:\r\n\r\n b) the originating speaker includes its own Member-AS Number in a\r\n path segment, of type AS_CONFED_SEQUENCE, in the AS_PATH attribute\r\n of all UPDATE messages sent to BGP speakers located in neighboring\r\n| autonomous systems that are members of the local confederation.\r\n [...]\r\n\r\n\r\n(5) typo, and unnecessarily differing case\r\n\r\nThe last paragraph of the new Section 5 says:\r\n\r\n vv\r\n| It is a error for a BGP speaker to receive an update message from a\r\n confederation peer that is not in the same Member-AS that does not\r\n have AS_CONFED_SEQUENCE as the first segment. [...]\r\n\r\nTo correct the grammar, and to harmonize the case of 'UPDATE message'\r\nthroughout the whole section, it should say:\r\n\r\n vvv\r\n| It is an error for a BGP speaker to receive an UPDATE message from a\r\n confederation peer that is not in the same Member-AS that does not\r\n have AS_CONFED_SEQUENCE as the first segment. [...]\r\n\r\nAlternatively, perhaps, the obstinate double 'that' could easily be\r\nremoved as well:\r\n\r\n vvv\r\n| It is an error for a BGP speaker to receive an UPDATE message from a\r\n| confederation peer not located in the same Member-AS that does not\r\n have AS_CONFED_SEQUENCE as the first segment. [...]\r\n\r\n\r\n(6) grammar\r\n\r\nThe first paragraph of Section 6, on top of page 10, says:\r\n\r\n vv\r\n| All BGP speakers participating as members of a confederation MUST\r\n recognize the AS_CONFED_SET and AS_CONFED_SEQUENCE segment type\r\n extensions to the AS_PATH attribute.\r\n\r\nIMHO, it should be ... participating *in* ...\r\nThus, the RFC should say:\r\n vv\r\n| All BGP speakers participating as members in a confederation MUST\r\n recognize the AS_CONFED_SET and AS_CONFED_SEQUENCE segment type\r\n extensions to the AS_PATH attribute.\r\n\r\n\r\n(7) obsolete reference tag - #2\r\n\r\nSection 8 (at the bottom of page 10) says:\r\n\r\n This extension to BGP does not change the underlying security issues\r\n inherent in the existing BGP protocol, such as those described in\r\n| [RFC2385] and [BGP-VULN].\r\n ^^^^^^^^\r\n\r\nThere is no such reference tag '[BGP-VULN]' in Section 10.\r\nApparently, the RFC should say:\r\n\r\n This extension to BGP does not change the underlying security issues\r\n inherent in the existing BGP protocol, such as those described in\r\n| [RFC2385] and [RFC4272].\r\n ^^^^^^^\r\n\r\n\r\n(8) obsolete reference tag - #3\r\n\r\nThe first paragraph of Section 9, on top of page 11, says:\r\n\r\n The general concept of BGP confederations was taken from IDRP's\r\n Routing Domain Confederations [ISO10747]. Some of the introductory\r\n| text in this document was taken from [RFC2796].\r\n ^^^^\r\n\r\nAs in item (1) above, either the tag '[RFC2796]' is updated:\r\n\r\n The general concept of BGP confederations was taken from IDRP's\r\n Routing Domain Confederations [ISO10747]. Some of the introductory\r\n| text in this document was taken from [RFC4456].\r\n ^^^^\r\n\r\nor an entry for '[RFC2796]' must be restored into Section 10.2 .\r\n\r\n\r\n(9) obsolete RFCs listed as Normative References ?!?\r\n\r\nRFC 5065, on page 11, lists its obsolete predecessors as Normative\r\nReferences, [RFC1965] and [RFC3065], in Section 10.1.\r\n\r\nAccording to common sense, general practice, and the rules for\r\nNormative References, I would have preferred to see these entries\r\nplaced into Section 10.2, as Informative References.\r\n", "correct_text": "", "notes": "This proposed no normative changes, and the clarifications do not appear to be urgent.", "submit_date": "2007-08-17", "submitter_name": "Alfred Hoenes", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "1332", "doc-id": "RFC4271", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "4.5", "orig_text": " OPEN Message Error subcodes:\r\n\r\n 1 - Unsupported Version Number.\r\n 2 - Bad Peer AS.\r\n 3 - Bad BGP Identifier.\r\n 4 - Unsupported Optional Parameter.\r\n 5 - [Deprecated - see Appendix A].\r\n 6 - Unacceptable Hold Time.", "correct_text": " OPEN Message Error subcodes:\r\n\r\n 1 - Unsupported Version Number.\r\n 2 - Bad Peer AS.\r\n 3 - Bad BGP Identifier.\r\n 4 - Unsupported Optional Parameter.\r\n 5 - [Deprecated - see Appendix A].\r\n 6 - Unacceptable Hold Time.\r\n 7 - Unsupported Capability", "notes": "7 - Unsupported Capability orig from RFC3392 seems to have accidently disappeared.\r\n\r\nThanks!\r\nAaron\n --VERIFIER NOTES-- \nThe working group debated this point and concluded the following:\r\n\r\nThe functionality (specifically, BGP Capabilities) this error code applies to does not appear anywhere in RFC 4271 (or RFC 1771). As IANA records, this error subcode is defined in RFC5492/RFC3392, along with the related functionality. The IANA registry is the final authority as to code point assignments, and is correct as written. Accordingly, this erratum is rejected.", "submit_date": "2008-02-26", "submitter_name": "Aaron Hughes", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "1585", "doc-id": "RFC5246", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.4.2", "orig_text": "struct {\r\n ClientCertificateType certificate_types<1..2^8-1>;\r\n DistinguishedName certificate_authorities<0..2^16-1>;\r\n} CertificateRequest;\r\n", "correct_text": "struct {\r\n ClientCertificateType certificate_types<1..2^8-1>;\r\n SignatureAndHashAlgorithm\r\n supported_signature_algorithms<2^16-1>;\r\n DistinguishedName certificate_authorities<0..2^16-1>;\r\n} CertificateRequest;\r\n", "notes": "The definition in Section 7.4.4 (which includes the \"supported_\r\nsignature_algorithms\" field) is the correct one (confirmed\r\nby Eric Rescorla on 2009-02-27)", "submit_date": "2008-11-05", "submitter_name": "Pasi Eronen", "verifier_id": "", "verifier_name": "Pasi Eronen", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "1633", "doc-id": "RFC4271", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6.3", "orig_text": " If an optional attribute is recognized, then the value of this\r\n attribute MUST be checked. If an error is detected, the attribute\r\n MUST be discarded, and the Error Subcode MUST be set to Optional\r\n Attribute Error. The Data field MUST contain the attribute (type,\r\n length, and value).", "correct_text": " If an optional attribute is recognized, then the value of this\r\n attribute MUST be checked. If an error is detected, the Error \r\n Subcode MUST be set to Optional Attribute Error. The Data \r\n field MUST contain the attribute (type, length, and value).", "notes": "This simply removes the clause \"the attribute MUST be discarded\", which doesn't make sense since the peering is to be terminated anyway.", "submit_date": "2008-12-12", "submitter_name": "John Scudder", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "1774", "doc-id": "RFC5280", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "6.3", "orig_text": " For each distribution point (DP) in the certificate CRL distribution\r\n points extension, for each corresponding CRL in the local CRL cache,\r\n while ((reasons_mask is not all-reasons) and (cert_status is\r\n UNREVOKED)) perform the following:\r\n\r\n (a) Update the local CRL cache by obtaining a complete CRL, a\r\n delta CRL, or both, as required:\r\n", "correct_text": " For each distribution point (DP) in the certificate CRL distribution\r\n points extension, for each corresponding CRL in the local CRL cache,\r\n while ((reasons_mask is not all-reasons) and (cert_status is\r\n UNREVOKED)) perform the following:\r\n\r\n (l) Set the reasons_mask state variable to the union of\r\n its previous value and the value of the interim_reasons_mask\r\n state variable.\r\n\r\n (a) Update the local CRL cache by obtaining a complete CRL, a\r\n delta CRL, or both, as required:", "notes": "This was reported in 2002 for RFC 3280, which this document obsoletes. The correction did not make it in to RFC 5280, and therefore applies to RFC 5280 as well.\n --VERIFIER NOTES-- \nThe correction already appears as step (l), the last step in the loop.", "submit_date": "2009-05-04", "submitter_name": "Takashi Ito", "verifier_id": "", "verifier_name": "Pasi Eronen", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "4722", "doc-id": "RFC7854", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "3.1 4.8 7", "orig_text": "Stats Reports", "correct_text": "Statistics Reports", "notes": "The message of type 1 is called \"Statistics Report\" in the IANA registry https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xml#message-types (I used it as the reference) and in sections 4.1 and 10.1 but \"Stats Report\" in sections 3.1, 4.8 and 7.", "submit_date": "2016-06-28", "submitter_name": "Stéphane Bortzmeyer", "verifier_id": "", "verifier_name": "Joel Jaeggli", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "2165", "doc-id": "RFC5246", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "6.2.3.2", "orig_text": " Example: If the block length is 8 bytes, the content length\r\n (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes,\r\n then the length before padding is 82 bytes (this does not include the\r\n\r\n\r\n\r\nDierks & Rescorla Standards Track [Page 23]\r\n\f\r\nRFC 5246 TLS August 2008\r\n\r\n\r\n IV. Thus, the padding length modulo 8 must be equal to 6 in order to\r\n make the total length an even multiple of 8 bytes (the block length).\r\n The padding length can be 6, 14, 22, and so on, through 254. If the\r\n padding length were the minimum necessary, 6, the padding would be 6\r\n bytes, each containing the value 6. Thus, the last 8 octets of the\r\n GenericBlockCipher before block encryption would be xx 06 06 06 06 06\r\n 06 06, where xx is the last octet of the MAC.\r\n", "correct_text": " Example: If the block length is 8 bytes, the content length\r\n (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes,\r\n then the length before padding is 82 bytes (this does not include the\r\n\r\n\r\n\r\nDierks & Rescorla Standards Track [Page 23]\r\n\f\r\nRFC 5246 TLS August 2008\r\n\r\n\r\n IV). Thus, the padding length modulo 8 must be equal to 6 in order to\r\n make the total length an even multiple of 8 bytes (the block length).\r\n The padding length can be 6, 14, 22, and so on, through 254. If the\r\n padding length were the minimum necessary, 6, the padding would be 6\r\n bytes, each containing the value 6. Thus, the last 8 octets of the\r\n GenericBlockCipher before block encryption would be xx 06 06 06 06 06\r\n 06 06, where xx is the last octet of the MAC.\r\n", "notes": "", "submit_date": "2010-04-19", "submitter_name": "Nikolai Malykh", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "2643", "doc-id": "RFC5246", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "E.3", "orig_text": "When a TLS-capable server negotiates SSL 2.0 it SHOULD, after\r\ndecrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding\r\nbytes are 0x03. If they are not, the server SHOULD generate a random\r\nvalue for SECRET-KEY-DATA, and continue the handshake (which will\r\neventually fail since the keys will not match).", "correct_text": "When a TLS-capable server negotiates SSL 2.0 it SHOULD, after\r\ndecrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding\r\nbytes are not all 0x03. If they are, the server SHOULD generate a random\r\nvalue for SECRET-KEY-DATA, and continue the handshake (which will\r\neventually fail since the keys will not match).", "notes": "The condition is the wrong way around. When the bytes *are* all 0x03, that means the client supports TLS, so there must have been a version rollback attack in order for SSL 2.0 to be negotiated. For example, see the NSS implementation (line number may rot):\r\n\r\nhttps://mxr.mozilla.org/mozilla/source/security/nss/lib/ssl/sslcon.c#1695", "submit_date": "2010-11-22", "submitter_name": "Matt McCutchen", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "2864", "doc-id": "RFC5246", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.4.2", "orig_text": "struct {\r\n ClientCertificateType certificate_types<1..2^8-1>;\r\n DistinguishedName certificate_authorities<0..2^16-1>;\r\n} CertificateRequest;\r\n\r\n--- Fixed by errata 1585 to\r\n\r\nstruct {\r\n ClientCertificateType certificate_types<1..2^8-1>;\r\n SignatureAndHashAlgorithm\r\n supported_signature_algorithms<2^16-1>;\r\n DistinguishedName certificate_authorities<0..2^16-1>;\r\n} CertificateRequest;", "correct_text": "struct {\r\n ClientCertificateType certificate_types<1..2^8-1>;\r\n SignatureAndHashAlgorithm\r\n supported_signature_algorithms<2..2^16-2>;\r\n DistinguishedName certificate_authorities<0..2^16-1>;\r\n} CertificateRequest;", "notes": "The supported_signature_algorithms field is a variable length array. As such ceiling and floor should be specified, and they should be multiple of the base type (which is two bytes long in this case).", "submit_date": "2011-07-19", "submitter_name": "Alfredo Pironti", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "2865", "doc-id": "RFC5246", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7.4.4", "orig_text": "struct {\r\n ClientCertificateType certificate_types<1..2^8-1>;\r\n SignatureAndHashAlgorithm\r\n supported_signature_algorithms<2^16-1>;\r\n DistinguishedName certificate_authorities<0..2^16-1>;\r\n} CertificateRequest;", "correct_text": "struct {\r\n ClientCertificateType certificate_types<1..2^8-1>;\r\n SignatureAndHashAlgorithm\r\n supported_signature_algorithms<2..2^16-2>;\r\n DistinguishedName certificate_authorities<0..2^16-1>;\r\n} CertificateRequest;", "notes": "The supported_signature_algorithms field is a variable length array. As such ceiling and floor should be specified, and they should be multiple of the base type (which is two bytes long in this case). See section 7.4.1.4.1 for a valid definition of this field.", "submit_date": "2011-07-19", "submitter_name": "Alfredo Pironti", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "2969", "doc-id": "RFC2119", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "1,3,4", "orig_text": "(1) \"The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and \"OPTIONAL\" mean\r\n\r\n(2) 1. MUST This word, or the terms \"REQUIRED\" or \"SHALL\", mean\r\n\r\n(3) 3. SHOULD This word, or the adjective \"RECOMMENDED\", mean\r\n\r\n(4) 4. SHOULD NOT This phrase, or the phrase \"NOT RECOMMENDED\" mean\r\n", "correct_text": "(1) \"The key words \"MUST\", \"MUST NOT\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", and \"MAY\" means\r\n\r\n(2) 1. MUST This word, or the term \"SHALL\", means\r\n\r\n(3) 3. SHOULD This word means\r\n\r\n(4) 4. SHOULD NOT This phrase means\r\n\r\nEditorial note: The use of \"mean\" after a singular subject is simply wrong. Subordinate phrases like \", or the term BLATHER,\" do nothing to change that.\r\n\r\n\r\n ", "notes": "RFC 2026, to which RFC 2119 should be subordinate, carefully distinguishes between Technical Specifications (TS) and Applicability Statements (AS). Its Section 3.3 prescribes specific language to be used in ASs, with categories \"Required\", \"Recommended\", \"Elective\", \"Limited Use\", and \"Not Recommended\", while 2119's language, especially in its Section 6, fairly clearly apply to interoperability requirements within TS documents. Use of terms that 2026 requires for AS documents in a TS context (as synonyms for other, unambiguous, terms) is just an invitation to confusion, especially if the IETF continues to have hair-splitting arguments about the nature of requirements in particular contexts. Consequently, while the change proposed in erratum 419 (altering the definition phrase to reflect the language of Section 4) appears reasonable from an editorial standpoint, the correct fix is to remove the 2026 AS terms as acceptable synonyms from 2119 entirely. If people want to say \"SHOULD NOT\" and give it specific meaning, they should say \"SHOULD NOT\" rather than trying to use nearly-synonymous terms and hoping that the reader will figure out what was really met.", "submit_date": "2011-09-12", "submitter_name": "John Klensin", "verifier_id": "", "verifier_name": "Russ Housley", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3031", "doc-id": "RFC4271", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "9.1.2", "orig_text": "The Phase 2 decision function is blocked from running while the Phase\r\n3 decision function is in process.", "correct_text": "The Phase 3 decision function is blocked from running while the Phase\r\n2 decision function is in process.", "notes": "I believe that is what was intended; the text as is confuses me no end.\n --VERIFIER NOTES-- \n It is accepted that the RFC text is confusing, but the proposed errata text is incorrect because this proposed revision implies that Phase 2 can begin running while Phase 3 is still running this contradicts other text in the RFC (9.1.2) which states that \"The Phase 3 Routing Decision function is blocked from running whilst the Phase 2 decision function is in process.\"\r\n\r\nIt is anticipated that the IDR WG will publish material clarifying mutual exclusion in RFC4271.\r\n\r\n ", "submit_date": "2011-11-14", "submitter_name": "Kireeti Kompella", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3122", "doc-id": "RFC5246", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.4.", "orig_text": " enum {\r\n hello_request(0), client_hello(1), server_hello(2),\r\n certificate(11), server_key_exchange (12),\r\n certificate_request(13), server_hello_done(14),\r\n certificate_verify(15), client_key_exchange(16),\r\n finished(20)\r\n (255)\r\n } HandshakeType;\r\n", "correct_text": " enum {\r\n hello_request(0), client_hello(1), server_hello(2),\r\n certificate(11), server_key_exchange (12),\r\n certificate_request(13), server_hello_done(14),\r\n certificate_verify(15), client_key_exchange(16),\r\n finished(20),\r\n (255)\r\n } HandshakeType;\r\n", "notes": "The comma after finished(20) is missing in the original text.", "submit_date": "2012-02-16", "submitter_name": "Daniel Otte", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3085", "doc-id": "RFC5280", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "A.1", "orig_text": "BuiltInStandardAttributes ::= SEQUENCE {\r\n country-name CountryName OPTIONAL,\r\n administration-domain-name AdministrationDomainName OPTIONAL,\r\n network-address [0] IMPLICIT NetworkAddress OPTIONAL,\r\n -- see also extended-network-address\r\n terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL,\r\n private-domain-name [2] PrivateDomainName OPTIONAL,\r\n organization-name [3] IMPLICIT OrganizationName OPTIONAL,\r\n -- see also teletex-organization-name\r\n numeric-user-identifier [4] IMPLICIT NumericUserIdentifier\r\n OPTIONAL,\r\n personal-name [5] IMPLICIT PersonalName OPTIONAL,\r\n -- see also teletex-personal-name\r\n organizational-unit-names [6] IMPLICIT OrganizationalUnitNames\r\n OPTIONAL }\r\n -- see also teletex-organizational-unit-names\r\n", "correct_text": "BuiltInStandardAttributes ::= SEQUENCE {\r\n country-name CountryName OPTIONAL,\r\n administration-domain-name AdministrationDomainName OPTIONAL,\r\n network-address [0] IMPLICIT NetworkAddress OPTIONAL,\r\n -- see also extended-network-address\r\n terminal-identifier [1] IMPLICIT TerminalIdentifier OPTIONAL,\r\n private-domain-name [2] IMPLICIT PrivateDomainName OPTIONAL,\r\n organization-name [3] IMPLICIT OrganizationName OPTIONAL,\r\n -- see also teletex-organization-name\r\n numeric-user-identifier [4] IMPLICIT NumericUserIdentifier\r\n OPTIONAL,\r\n personal-name [5] IMPLICIT PersonalName OPTIONAL,\r\n -- see also teletex-personal-name\r\n organizational-unit-names [6] IMPLICIT OrganizationalUnitNames\r\n OPTIONAL }\r\n -- see also teletex-organizational-unit-names\r\n", "notes": "Seems to me that private-domain-name ought to be tagged IMPLICIT just like everything else?\n --VERIFIER NOTES-- \nPrivateDomainName (unlike the other tagged components) is an untagged\r\nCHOICE type.\r\n\r\n\r\nQuote from X.680:\r\n\r\n'30.8 The IMPLICIT alternative shall not be used if the type defined\r\nby \"Type\" is an untagged choice type or an untagged open type or an untagged\r\n\"DummyReference\" (see ITU-T Rec. X.683 | ISO/IEC 8824-4, 8.3).' ", "submit_date": "2012-01-06", "submitter_name": "Jim Wigginton", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3090", "doc-id": "RFC6125", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "6.4.3", "orig_text": "6.4.3. Checking of Wildcard Certificates\r\n\r\n A client employing this specification's rules MAY match the reference\r\n identifier against a presented identifier whose DNS domain name\r\n portion contains the wildcard character '*' as part or all of a label\r\n (following the description of labels and domain names in\r\n [DNS-CONCEPTS]).\r\n\r\n For information regarding the security characteristics of wildcard\r\n certificates, see Section 7.2.\r\n\r\n If a client matches the reference identifier against a presented\r\n identifier whose DNS domain name portion contains the wildcard\r\n character '*', the following rules apply:\r\n\r\n 1. The client SHOULD NOT attempt to match a presented identifier in\r\n which the wildcard character comprises a label other than the\r\n left-most label (e.g., do not match bar.*.example.net).\r\n\r\n 2. If the wildcard character is the only character of the left-most\r\n label in the presented identifier, the client SHOULD NOT compare\r\n against anything but the left-most label of the reference\r\n identifier (e.g., *.example.com would match foo.example.com but\r\n not bar.foo.example.com or example.com).\r\n\r\n 3. The client MAY match a presented identifier in which the wildcard\r\n character is not the only character of the label (e.g.,\r\n baz*.example.net and *baz.example.net and b*z.example.net would\r\n be taken to match baz1.example.net and foobaz.example.net and\r\n buzz.example.net, respectively). However, the client SHOULD NOT\r\n attempt to match a presented identifier where the wildcard\r\n character is embedded within an A-label or U-label [IDNA-DEFS] of\r\n an internationalized domain name [IDNA-PROTO].", "correct_text": "[ no firm test suggestions just as yet, please see below ]", "notes": "RFC6125 bug: Checking of Wildcard Certs lacks spec of how many labels in presented identifier\r\n\r\nsection 6.4.3 does not specify how many labels must be in a wildcarded presented identifier. I.e., it leaves open the possibility that the following presented identifiers could be matched against actual domain names..\r\n\r\n *\r\n *.\r\n *.com i.e. *. e.g.: *.uk or *.co.uk\r\n *U i.e. * e.g.: will match AU, EDU, CU \r\n\r\n etc. etc. \r\n\r\n \r\nIf actual TLS/SSL implementations (e.g. web browsers) were to make valid matches as shown above, then someone could ostensibly obtain a cert (c.f. diginotar) for one of them and then go and MITM large swaths of domain name space. \r\n\r\nNote that the discussion of wildcards in Section 7.2 of security considerations identifies the public suffix issue in passing, but only as one of a set of issues why the spec discourages use of wildcard certs.\r\n\r\nNote also that this issue begs the question of being able to determine what constitutes a so-called domain name \"public suffix\" (e.g. \".com\", \".co.uk\") -- we can't simply write into the spec \"the wildcard must be in the left-most label position and there must be at least one? two? three? labels to the right of the wildcard's position\". \r\n\r\nLikely the approach will need to consist of a \"SHOULD\" declaration and some hand-waving about how \"matching wildcards on presented identifiers with less than N (?) labels to the right of the wildcard has various increasing risks as N approaches zero, and that implementors should perhaps consider leveraging some of the available public suffix identification mechanisms, but that those are out of scope and have their own operational and security considerations.\"\r\n\r\nPSA: This issue needs to be addressed, but doing so by means of an erratum is not the best way to go about having this conversation. Marking as \"Hold For Document Update\" to make sure we don't lose track of the issue. -- Peter Saint-Andre", "submit_date": "2012-01-13", "submitter_name": "Jeff Hodges", "verifier_id": "", "verifier_name": "Peter Saint-Andre", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3123", "doc-id": "RFC5246", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.4.2.", "orig_text": " struct {\r\n select (KeyExchangeAlgorithm) {\r\n case dh_anon:\r\n ServerDHParams params;\r\n case dhe_dss:\r\n case dhe_rsa:\r\n ServerDHParams params;\r\n digitally-signed struct {\r\n opaque client_random[32];\r\n opaque server_random[32];\r\n ServerDHParams params;\r\n } signed_params;\r\n case rsa:\r\n case dh_dss:\r\n case dh_rsa:\r\n struct {} ;\r\n /* message is omitted for rsa, dh_dss, and dh_rsa */\r\n /* may be extended, e.g., for ECDH -- see [TLSECC] */\r\n } ServerKeyExchange;\r\n", "correct_text": " struct {\r\n select (KeyExchangeAlgorithm) {\r\n case dh_anon:\r\n ServerDHParams params;\r\n case dhe_dss:\r\n case dhe_rsa:\r\n ServerDHParams params;\r\n digitally-signed struct {\r\n opaque client_random[32];\r\n opaque server_random[32];\r\n ServerDHParams params;\r\n } signed_params;\r\n case rsa:\r\n case dh_dss:\r\n case dh_rsa:\r\n struct {} ;\r\n /* message is omitted for rsa, dh_dss, and dh_rsa */\r\n /* may be extended, e.g., for ECDH -- see [TLSECC] */\r\n };\r\n } ServerKeyExchange;\r\n", "notes": "The '};' which belongs to 'select (KeyExchangeAlgorithm) {' is missing in the original text.", "submit_date": "2012-02-16", "submitter_name": "Daniel Otte", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3791", "doc-id": "RFC5065", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "7", "orig_text": " Additionally, confederations (as well as route reflectors), by\r\n excluding different reachability information from consideration at\r\n different locations in a confederation, have been shown [RFC3345] to\r\n cause permanent oscillation between candidate routes when using the\r\n tie-breaking rules required by BGP [BGP-4].", "correct_text": " Additionally, confederations (as well as route reflectors), by\r\n excluding different reachability information from consideration at\r\n different locations in a confederation, have been shown [RFC3345] to\r\n cause persistent oscillation between candidate routes when using the\r\n tie-breaking rules required by BGP [BGP-4].", "notes": "s/permanent/persistent\r\n\r\nRFC 3345 nowhere refers to this oscillation as \"permanent\". It consistently refers to it as \"persistent\" only.\r\n\r\n\"Permanent\" is a much stronger word than \"persistent\", and I believe is not applicable here.", "submit_date": "2013-11-08", "submitter_name": "Ramakrishna DTV", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3191", "doc-id": "RFC5246", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "Meta-Data", "orig_text": "Obsoletes: 3268, 4346, 4366\r\nUpdates: 4492", "correct_text": "Updates: 4492", "notes": "\"Obsoletes: 4366\" is factually incorrect, because it is impossible to implement TLSv1.1 (rfc4346) or TLSv1.0(rfc2246) from the TLSv1.2 spec alone. (IPv6 does not obsolete IPv4 and HTTP/1.1 does not obsolete HTTP/1.0 either).\r\n\r\n\"Obsoletes: 4366\" is factually incorrect, because some of the TLS extensions defined in rfc4366 do NOT appear in rfc5246 (and were updated by rfc6066). On top of that, in order to implement TLS extensions for TLSv1.0 or TLSv1.1, rfc4366 is indispensible, because it describes the necessary changes to the TLSv1.0 & TLSv1.1 PDUs, information that would be cumbersome to extract from rfc5246 compared to simply using rfc4366.\r\n\r\n\"Obsoletes: 3268\" is factually incorrect, because 3268 is the document needed to implement the AES ciphersuites in implementations of TLS _prior_ to TLSv1.2,\r\nsuch as TLSv1.0(rfc2246) and TLSv1.1(rfc4346), i.e. to add support for AES ciphersuites to an existing implementation of TLSv1.0, one would use TLSv1.0(rfc2246) plus rfc3268, rather than TLSv1.0 plus some undefined fragments of rfc5246.\n --VERIFIER NOTES-- \nIf you're looking to implement TLS 1.1 or TLS 1.0 you should be looking in those earlier specifications not RFC 5246.\r\n\r\nOne RFC can be obsoleted by more than RFC.", "submit_date": "2012-04-12", "submitter_name": "Martin Rex", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3200", "doc-id": "RFC5280", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.1.2.2", "orig_text": " The serial number MUST be a positive integer assigned by the CA to\r\n each certificate. It MUST be unique for each certificate issued by a\r\n given CA (i.e., the issuer name and serial number identify a unique\r\n certificate). CAs MUST force the serialNumber to be a non-negative\r\n integer.", "correct_text": " The serial number MUST be a positive non-zero integer assigned by the\r\n CA to each certificate. It MUST be unique for each certificate issued\r\n by a given CA (i.e., the issuer name and serial number identify a\r\n unique certificate). CAs MUST force the serialNumber to be a positive\r\n integer.", "notes": "\"positive\" and \"non-negative\" do not mean the same thing. I used the third paragraph of the section as a tie-breaker to decide which of the two terms was intended:\r\n\r\n Note: Non-conforming CAs may issue certificates with serial numbers\r\n that are negative or zero. Certificate users SHOULD be prepared to\r\n gracefully handle such certificates.", "submit_date": "2012-04-24", "submitter_name": "David Mandelberg", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3264", "doc-id": "RFC4271", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "In Appendix F.3", "orig_text": "Implementations that combine update messages (as described above in\r\nSection 6.1) may prefer to see all path attributes presented in a\r\nknown order.", "correct_text": "Implementations that combine update messages (as described above in\r\nAppendix F.1) may prefer to see all path attributes presented in a\r\nknown order.", "notes": "Section 6.1 does not say anything about combining update messages.\r\n\r\nAppendix F.1 is the correct reference.", "submit_date": "2012-06-19", "submitter_name": "Anmol Khirbat", "verifier_id": "", "verifier_name": "Ketan Talaulikar", "update_date": "2025-05-28 12:11:12" }, { "errata_id": "3268", "doc-id": "RFC4252", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "5.1", "orig_text": " A request that requires further messages to be exchanged will be\r\n aborted by a subsequent request. A client MUST NOT send a subsequent\r\n request if it has not received a response from the server for a\r\n previous request. A SSH_MSG_USERAUTH_FAILURE message MUST NOT be\r\n sent for an aborted method.\r\n", "correct_text": " A request that requires further messages to be exchanged will be\r\n aborted by a subsequent request. In this case a client MUST NOT \r\n send a subsequent request if it has not received a response from \r\n the server for a previous request. A SSH_MSG_USERAUTH_FAILURE \r\n message MUST NOT be sent for an aborted method.\r\n", "notes": "The ambiguous wording, which can be confusing. See previous paragraph", "submit_date": "2012-06-28", "submitter_name": "Nikolai Malykh", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "4455", "doc-id": "RFC7607", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "5.1", "orig_text": "N/A", "correct_text": "N/A", "notes": "The normative reference to RFC 7606 is dangling (7606 has not been published).\r\n\r\n===\r\n\r\n(Alvaro Retana) rfc7606 is a valid reference.\n --VERIFIER NOTES-- \nrfc7606 is a valid reference. ", "submit_date": "2015-08-26", "submitter_name": "Stéphane Bortzmeyer", "verifier_id": "", "verifier_name": "Alvaro Retana", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3366", "doc-id": "RFC4271", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "8.2.2", "orig_text": "If a TcpConnectionFails event (Event 18) is received, the local\r\n system:\r\n\r\n - closes the BGP connection,\r\n\r\n - restarts the ConnectRetryTimer,\r\n\r\n - continues to listen for a connection that may be initiated by\r\n the remote BGP peer, and\r\n\r\n - changes its state to Active.", "correct_text": "If a TcpConnectionFails event (Event 18) is received, the local\r\n system:\r\n\r\n - closes the BGP connection,\r\n\r\n - sets the HoldTimer to 0,\r\n\r\n - restarts the ConnectRetryTimer,\r\n\r\n - continues to listen for a connection that may be initiated by\r\n the remote BGP peer, and\r\n\r\n - changes its state to Active.", "notes": "HoldTimer should only be used to control time in between BGP packets. \r\nAlso in this case it can lead to case in ACTIVE state where HoldTimer expires before the ConnectRetryTimer leading to IDLE state.\n --VERIFIER NOTES-- \n This represents a technical change to RFC4271 and is outside the scope of the errata system. The submitter is welcome to submit a draft proposing the change to RFC 4271 and work for consensus for the change in the IDR WG.", "submit_date": "2012-09-26", "submitter_name": "Shashank Tyagi", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3459", "doc-id": "RFC4271", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "6.8", "orig_text": "If a pair of BGP speakers try to establish a BGP connection with each\r\nother simultaneously, then two parallel connections well be formed.", "correct_text": "If a pair of BGP speakers try to establish a BGP connection with each\r\nother simultaneously, then two parallel connections will be formed.", "notes": "This edit will replace the \"well\" with \"will\".", "submit_date": "2013-01-16", "submitter_name": "Lawrence Hui", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3466", "doc-id": "RFC5280", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4.2.1.6", "orig_text": " If the subjectAltName extension is present, the sequence MUST contain\r\n at least one entry. Unlike the subject field, conforming CAs MUST\r\n| NOT issue certificates with subjectAltNames containing empty\r\n GeneralName fields. For example, an rfc822Name is represented as an\r\n IA5String. While an empty string is a valid IA5String, such an\r\n rfc822Name is not permitted by this profile. ", "correct_text": " If the subjectAltName extension is present, the sequence MUST contain\r\n at least one entry. Unlike the subject field, conforming CAs MUST\r\n| NOT issue certificates with subjectAltName extensions containing empty\r\n GeneralName fields. For example, an rfc822Name is represented as an\r\n IA5String. While an empty string is a valid IA5String, such an\r\n rfc822Name is not permitted by this profile. ", "notes": "Certificates do not have \"subjectAltNames\" but only \"subjectAltName extensions\", which is the correct wording that is thoroughly used in the document.", "submit_date": "2013-01-18", "submitter_name": "Annie Yousar", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3579", "doc-id": "RFC5280", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.2.1.4", "orig_text": "certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation", "correct_text": "CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation", "notes": "ASN.1 type references must begin with an upper case character. Schema in A.2 is correct.", "submit_date": "2013-04-03", "submitter_name": "Timothy J. Miller", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3693", "doc-id": "RFC5280", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "4.2.1.10", "orig_text": " DNS name restrictions are expressed as host.example.com. Any DNS\r\n name that can be constructed by simply adding zero or more labels to\r\n the left-hand side of the name satisfies the name constraint. For\r\n example, www.host.example.com would satisfy the constraint but\r\n host1.example.com would not.\r\n", "correct_text": "[Add this to the paragraph]\r\n\r\n If an implementation extracts DNS names from the subject\r\n distinguished name, DNS name restrictions MUST be applied\r\n to these names as well.\r\n", "notes": "When used with TLS and HTTP (according to RFC 2818), section 4.2.1.10, Name Constraints, is technically a NOP that doesn't constraint the CA that has this attribute because RFC 2818 mandates processing of the common name attribute in the subject distinguished name. Consequentially, the constraint can be bypassed by issuing a certificate without a subject alternative name. The fix is to apply the DNS name restrictions to the relevant parts of the subject distinguished name, too, as implemented here:\r\n\r\nhttps://bugzilla.mozilla.org/show_bug.cgi?id=394919\n --VERIFIER NOTES-- \nThe suggested change is not editorial; it represents a significant\r\ntechnical change. It also does not accurately reflect the intent of the WG. ", "submit_date": "2013-08-12", "submitter_name": "Florian Weimer", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3673", "doc-id": "RFC4271", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "5", "orig_text": "Path attributes fall into four separate categories:\r\n\r\n 1. Well-known mandatory.\r\n 2. Well-known discretionary.\r\n 3. Optional transitive.\r\n 4. Optional non-transitive.\r\n", "correct_text": "Path attributes fall into five separate categories:\r\n\r\n 1. Well-known mandatory.\r\n 2. Well-known discretionary.\r\n 3. Well-known.\r\n 4. Optional transitive.\r\n 5. Optional non-transitive.", "notes": "Local pref is only a \"well-known\" attribute as it fails the definition for the behavior as a mandatory attribute and it is not exactly discretionary per 5.1.5's definition of local pref and section 5's definition of discretionary which states:\r\n\r\n\"5.1.5. LOCAL_PREF\r\n\r\n LOCAL_PREF is a well-known attribute that SHALL be included in all\r\n UPDATE messages that a given BGP speaker sends to other internal\r\n peers.\"\r\n\r\nSection 5's definition of discretionary:\r\n\r\n\" [...]Others are discretionary and MAY\r\n or MAY NOT be sent in a particular UPDATE message.\"\r\n\r\nAs a well-known mandatory attribute would result in a NOTIFICATION per section 6.3, it cannot be well-known mandatory because it is only for internal peers. Thus, it is a separate category.\r\n\r\n6.3\r\n\" If any of the well-known mandatory attributes are not present, then\r\n the Error Subcode MUST be set to Missing Well-known Attribute. The\r\n Data field MUST contain the Attribute Type Code of the missing,\r\n well-known attribute.\"\r\n\r\nIn a future revision, a new term would probably be best to describe this. However, the categorization of attributes is misleading for now and the simplest approach is to add the new category already used by 5.1.5.\n --VERIFIER NOTES-- \nThis erratum was discussed on the IDR list.\r\n\r\nThe consensus was that whilst an alternative is to revert \r\nfrom OpenSent to Idle on event 18 at that point, this was not \r\nwhat was decided when RFC4271 was being produced, and\r\nno one saw a good engineering reason to change it at this \r\nstage.\r\n\r\nOn a matter of process, this proposal is not an Erratum \r\nas the IETF sees it but an engineering change.\r\n\r\nThe submitter is, of course, welcome to submit a draft \r\nproposing this change to RFC 4271 and the to discuss the \r\nmerits of the change with the IDR Working Group.", "submit_date": "2013-06-28", "submitter_name": "William McCall", "verifier_id": "", "verifier_name": "Stewart Bryant", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3674", "doc-id": "RFC5280", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "6.3.3", "orig_text": "If the distribution point name is present in the IDP CRL \r\nextension and the distribution field is present in the DP, \r\nthen verify that one of the names in the IDP matches one \r\nof the names in the DP.", "correct_text": "If the distribution point name is present in the IDP CRL \r\nextension and the distributionPoint field is present in \r\nthe DP, then verify that one of the names in the IDP \r\nmatches one of the names in the DP.", "notes": "Original text refers to the non existent field \"distribution\" in DP.", "submit_date": "2013-06-28", "submitter_name": "Piyush Jain", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3754", "doc-id": "RFC5280", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "A.1", "orig_text": "-- Naming attributes of type X520countryName (digraph from IS 3166)", "correct_text": "-- Naming attributes of type X520countryName (digraph from ISO 3166)", "notes": "typo in ASN.1 comment (\"IS\", should be \"ISO\")", "submit_date": "2013-10-16", "submitter_name": "Michal Bozon", "verifier_id": "", "verifier_name": "Sean Turner", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3809", "doc-id": "RFC4271", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "6", "orig_text": " Before the invalid routes are deleted\r\n from the system, it advertises, to its peers, either withdraws for\r\n the routes marked as invalid, or the new best routes before the\r\n invalid routes are deleted from the system.", "correct_text": " Before the invalid routes are deleted\r\n from the system, it advertises, to its peers, either withdraws for\r\n the routes marked as invalid, or the new best routes.", "notes": "The phrase \"Before the invalid routes are deleted from the system\" is unnecessarily repeated in the same sentence.", "submit_date": "2013-11-21", "submitter_name": "Ramakrishna DTV", "verifier_id": "", "verifier_name": "Ketan Talaulikar", "update_date": "2025-05-28 12:12:27" }, { "errata_id": "3877", "doc-id": "RFC4254", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "6.10", "orig_text": "6.10. Returning Exit Status\r\n\r\n When the command running at the other end terminates, the following\r\n message can be sent to return the exit status of the command.\r\n Returning the status is RECOMMENDED. No acknowledgement is sent for\r\n this message. The channel needs to be closed with\r\n SSH_MSG_CHANNEL_CLOSE after this message.\r\n\r\n The client MAY ignore these messages.", "correct_text": "6.10. Returning Exit Status\r\n\r\n When the command running at the other end terminates, the following\r\n message can be sent to return the exit status of the command.\r\n Returning the status is RECOMMENDED. No acknowledgement is sent for\r\n this message. The channel needs to be closed by the server with\r\n SSH_MSG_CHANNEL_CLOSE after this message.\r\n\r\n The client MAY ignore these messages.", "notes": "Even though it can arguably be inferred from the text as written I think it'd make it more clear if the RFC explicitly said that the server is the one that should be sending the SSH_MSG_CHANNEL_CLOSE message.", "submit_date": "2014-02-02", "submitter_name": "Jim Wigginton", "verifier_id": "", "verifier_name": "Kathleen Moriarty", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3878", "doc-id": "RFC4254", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5.2", "orig_text": " The maximum amount of data allowed is determined by the maximum\r\n packet size for the channel, and the current window size, whichever\r\n is smaller. The window size is decremented by the amount of data\r\n sent. Both parties MAY ignore all extra data sent after the allowed\r\n window is empty.", "correct_text": " The maximum amount of data allowed is determined by the maximum\r\n packet size for the channel, and the current window size, whichever\r\n is smaller. The window size is decremented by the length of the data\r\n sent, length field included. Both parties MAY ignore all extra data\r\n sent after the allowed window is empty.", "notes": "This is the data transfer packet:\r\n\r\n byte SSH_MSG_CHANNEL_DATA\r\n uint32 recipient channel\r\n string data\r\n\r\nSince string's are defined by RFC4251 as being \"stored as a uint32 containing its length (number of bytes that follow) and zero (= empty string) or more bytes that are the value of the string\" it's unclear weather or not the uint32 length field contributes to the total or not. In my interoperability testing it seems that it does but it doesn't seem that this is all that clear from this RFC.\r\n\r\nIt is also unclear from this RFC whether or not SSH_MSG_CHANNEL_EXTENDED_DATA should be decrementing from the window size or not. A strict interpretation would suggest it does not since the RFC makes no mention of it.", "submit_date": "2014-02-02", "submitter_name": "Jim Wigginton", "verifier_id": "", "verifier_name": "Stephen Farrell", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "3986", "doc-id": "RFC5280", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.1.1.3", "orig_text": "4.1.1.3. signatureValue\r\n\r\n The signatureValue field contains a digital signature computed upon\r\n the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded\r\n tbsCertificate is used as the input to the signature function. This\r\n signature value is encoded as a BIT STRING and included in the\r\n signature field. The details of this process are specified for each\r\n of the algorithms listed in [RFC3279], [RFC4055], and [RFC4491].", "correct_text": "4.1.1.3. signatureValue\r\n\r\n The signatureValue field contains a digital signature computed upon\r\n the ASN.1 DER encoded tbsCertificate. The ASN.1 DER encoded\r\n tbsCertificate is used as the input to the signature function. The \r\n output of the signature function is encoded as a BIT STRING and \r\n included in the signatureValue field. The details of this process \r\n are specified for each of the algorithms listed in [RFC3279], \r\n [RFC4055], and [RFC4491].", "notes": "The \"included in the signature field\" should have been \"included in the signatureValue field\". A field called \"signature\" does exist in the 5280 structure, but it is not intended to hold the value of the result of the signature function. The sentence was reworded for word flow (and to avoid using \"signature value\" and \"signatureValue\" in the same sentence).\r\n\r\nVerifier note: Hold for document update to prevent potential ASN.1 breaks", "submit_date": "2014-05-13", "submitter_name": "Sandra Murphy", "verifier_id": "", "verifier_name": "Deb Cooley", "update_date": "2024-10-29 15:14:39" }, { "errata_id": "4007", "doc-id": "RFC5246", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "7.3.", "orig_text": "Note: To help avoid pipeline stalls, ChangeCipherSpec is an\r\n independent TLS protocol content type, and is not actually a TLS\r\n handshake message.\r\n", "correct_text": "Note: To avoid ChangeCipherSpec being transmitted in mix with\r\n other handshake fragments in one record, ChangeCipherSpec is\r\n an independent TLS protocol content type, and is not actually\r\n a TLS handshake message. To help avoid pipeline stalls, \r\n ChangeCipherSpec is sent from both the server and the client.\r\n", "notes": "The original text can be read like we can handle ChangeCipherSpec asynchronously.\r\nThis is harmful and may be a cause of CCS Injection vulnerability.", "submit_date": "2014-06-06", "submitter_name": "KIKUCHI Masashi", "verifier_id": "", "verifier_name": "Stephen Farrell", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "4109", "doc-id": "RFC5246", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.4.2", "orig_text": " opaque ASN.1Cert<2^24-1>;\r\n", "correct_text": " opaque ASN.1Cert<1..2^24-1>;", "notes": "The appendix definition of ASN.1Cert leaves out the floor of the variable-length vector, which must be specified according to the vector syntax specification in section 4.3. Fortunately, the original definition of ASN.1Cert in section 7.4.2 does specify the floor as 1, so the definition in A.4.2 should be updated to match.", "submit_date": "2014-09-11", "submitter_name": "Christopher Armstrong", "verifier_id": "", "verifier_name": "Stephen Farrell", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "4493", "doc-id": "RFC4271", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.5", "orig_text": " Message Header Error subcodes:\r\n\r\n 1 - Connection Not Synchronized.\r\n 2 - Bad Message Length.\r\n 3 - Bad Message Type.\r\n\r\n OPEN Message Error subcodes:\r\n\r\n 1 - Unsupported Version Number.\r\n 2 - Bad Peer AS.\r\n 3 - Bad BGP Identifier.\r\n 4 - Unsupported Optional Parameter.\r\n 5 - [Deprecated - see Appendix A].\r\n 6 - Unacceptable Hold Time.\r\n\r\n UPDATE Message Error subcodes:\r\n\r\n 1 - Malformed Attribute List.\r\n 2 - Unrecognized Well-known Attribute.\r\n 3 - Missing Well-known Attribute.\r\n 4 - Attribute Flags Error.\r\n 5 - Attribute Length Error.\r\n 6 - Invalid ORIGIN Attribute.\r\n 7 - [Deprecated - see Appendix A].\r\n 8 - Invalid NEXT_HOP Attribute.\r\n 9 - Optional Attribute Error.\r\n 10 - Invalid Network Field.\r\n 11 - Malformed AS_PATH.", "correct_text": " Message Header Error subcodes:\r\n\r\n 0 - Unspecific.\r\n 1 - Connection Not Synchronized.\r\n 2 - Bad Message Length.\r\n 3 - Bad Message Type.\r\n\r\n OPEN Message Error subcodes:\r\n\r\n 0 - Unspecific.\r\n 1 - Unsupported Version Number.\r\n 2 - Bad Peer AS.\r\n 3 - Bad BGP Identifier.\r\n 4 - Unsupported Optional Parameter.\r\n 5 - [Deprecated - see Appendix A].\r\n 6 - Unacceptable Hold Time.\r\n\r\n UPDATE Message Error subcodes:\r\n\r\n 0 - Unspecific.\r\n 1 - Malformed Attribute List.\r\n 2 - Unrecognized Well-known Attribute.\r\n 3 - Missing Well-known Attribute.\r\n 4 - Attribute Flags Error.\r\n 5 - Attribute Length Error.\r\n 6 - Invalid ORIGIN Attribute.\r\n 7 - [Deprecated - see Appendix A].\r\n 8 - Invalid NEXT_HOP Attribute.\r\n 9 - Optional Attribute Error.\r\n 10 - Invalid Network Field.\r\n 11 - Malformed AS_PATH.", "notes": "RFC 4271 defines a use and a name for Error subcode 0:\r\n- §4.5 (any error code): \r\n If no appropriate Error Subcode is defined, then a zero\r\n (Unspecific) value is used for the Error Subcode field.\r\n\r\n- §6.2 (OPEN error code): \r\n If one of the Optional Parameters in the OPEN message is recognized,\r\n but is malformed, then the Error Subcode MUST be set to 0\r\n (Unspecific).\r\n\r\nThe \"IANA Considerations\" section would also need to be updated \r\naccordingly (says \"0 Reserved”). However, IANA has corrected the \r\ncorresponding registry at http://www.iana.org/assignments/bgp-parameters.\r\n", "submit_date": "2015-10-06", "submitter_name": "Bruno Decraene", "verifier_id": "", "verifier_name": "Alvaro Retana", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "4496", "doc-id": "RFC4271", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "9.1.1", "orig_text": "... If the return value indicates the route is\r\n ineligible, the route MAY NOT serve as an input to the next phase\r\n of route selection; ...", "correct_text": "... If the return value indicates the route is\r\n ineligible, the route MUST NOT serve as an input to the next phase\r\n of route selection; ...", "notes": "RFC 2119 does not define special word MAY NOT. Obviously, ineligible route must not be used in route selection.\r\n====", "submit_date": "2015-10-10", "submitter_name": "Alexander Okonnikov", "verifier_id": "", "verifier_name": "Alvaro Retana", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "7073", "doc-id": "RFC8446", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.4", "orig_text": "These messages are encrypted under keys derived from the [sender]_handshake_traffic_secret.", "correct_text": "These messages are encrypted under keys derived from the [sender]_handshake_traffic_secret, except for post-handshake authentication", "notes": "There's an exception", "submit_date": "2022-08-06", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-10-17 18:40:02" }, { "errata_id": "4507", "doc-id": "RFC5246", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "7.4.1.2", "orig_text": "After sending the ClientHello message, the client waits for a\r\nServerHello message. Any handshake message returned by the server,\r\nexcept for a HelloRequest, is treated as a fatal error.\r\n", "correct_text": "After sending the ClientHello message, the client waits for a\r\nServerHello message. Any other handshake message returned by the\r\nserver, except for a HelloRequest, is treated as a fatal error.", "notes": "A ServerHello received after a ClientHello should not be treated as a fatal error.\r\n\r\nPaul Wouters (AD): TLS 1.2 has been obsoleted by TLS 1.3 RFC8446. The language in that RFC does not contain the same issue (see https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.2). As such, this is marked as Verified.", "submit_date": "2015-10-19", "submitter_name": "Benjamin Kaduk", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-01-16 02:33:56" }, { "errata_id": "4274", "doc-id": "RFC5280", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "A.1", "orig_text": "-- Naming attributes of type X520CommonName:\r\n-- X520CommonName ::= DirectoryName (SIZE (1..ub-common-name))\r\n\r\n...\r\n\r\n-- Naming attributes of type X520LocalityName:\r\n-- X520LocalityName ::= DirectoryName (SIZE (1..ub-locality-name))\r\n\r\n...\r\n\r\n-- Naming attributes of type X520StateOrProvinceName:\r\n-- X520StateOrProvinceName ::= DirectoryName (SIZE (1..ub-state-name))\r\n\r\n...\r\n\r\n-- Naming attributes of type X520OrganizationName:\r\n-- X520OrganizationName ::=\r\n-- DirectoryName (SIZE (1..ub-organization-name))\r\n\r\n...\r\n\r\n-- Naming attributes of type X520OrganizationalUnitName:\r\n-- X520OrganizationalUnitName ::=\r\n-- DirectoryName (SIZE (1..ub-organizational-unit-name))\r\n\r\n...\r\n\r\n-- Naming attributes of type X520Title:\r\n-- X520Title ::= DirectoryName (SIZE (1..ub-title))\r\n\r\n...\r\n\r\n-- Naming attributes of type X520Pseudonym:\r\n-- X520Pseudonym ::= DirectoryName (SIZE (1..ub-pseudonym))\r\n", "correct_text": "-- Naming attributes of type X520CommonName:\r\n-- X520CommonName ::= DirectoryString (SIZE (1..ub-common-name))\r\n\r\n...\r\n\r\n-- Naming attributes of type X520LocalityName:\r\n-- X520LocalityName ::= DirectoryString (SIZE (1..ub-locality-name))\r\n\r\n...\r\n\r\n-- Naming attributes of type X520StateOrProvinceName:\r\n-- X520StateOrProvinceName ::=\r\n-- DirectoryString (SIZE (1..ub-state-name))\r\n\r\n...\r\n\r\n-- Naming attributes of type X520OrganizationName:\r\n-- X520OrganizationName ::=\r\n-- DirectoryString (SIZE (1..ub-organization-name))\r\n\r\n...\r\n\r\n-- Naming attributes of type X520OrganizationalUnitName:\r\n-- X520OrganizationalUnitName ::=\r\n-- DirectoryString (SIZE (1..ub-organizational-unit-name))\r\n\r\n...\r\n\r\n-- Naming attributes of type X520Title:\r\n-- X520Title ::= DirectoryString (SIZE (1..ub-title))\r\n\r\n...\r\n\r\n-- Naming attributes of type X520Pseudonym:\r\n-- X520Pseudonym ::= DirectoryString (SIZE (1..ub-pseudonym))\r\n", "notes": "Appendix B. ASN.1 Notes says that:\r\n\r\n For many of the attribute types defined in [X.520], the\r\n AttributeValue uses the DirectoryString type. Of the attributes\r\n specified in Appendix A, the name, surname, givenName, initials,\r\n generationQualifier, commonName, localityName, stateOrProvinceName,\r\n organizationName, organizationalUnitName, title, and pseudonym\r\n attributes all use the DirectoryString type. X.520 uses a\r\n parameterized type definition [X.683] of DirectoryString to specify\r\n the syntax for each of these attributes. The parameter is used to\r\n indicate the maximum string length allowed for the attribute. In\r\n Appendix A, in order to avoid the use of parameterized type\r\n definitions, the DirectoryString type is written in its expanded form\r\n for the definition of each of these attribute types. So, the ASN.1\r\n in Appendix A describes the syntax for each of these attributes as\r\n being a CHOICE of TeletexString, PrintableString, UniversalString,\r\n UTF8String, and BMPString, with the appropriate constraints on the\r\n string length applied to each of the types in the CHOICE, rather than\r\n using the ASN.1 type DirectoryString to describe the syntax.\r\n\r\nThere is nothing about DirectoryName type here. So comments in ASN.1 in\r\nA.1 are wrong and DirectoryName should be fixed to DirectoryString.\r\n\r\nFrom Expert PKIX reviewers:\r\nThe errata calls for changing \"DirectoryName\" to \"DirectoryString\" in the comments\r\nof the ASN.1. Nobody seems to disagree with this correction.\r\n\r\nThis message triggered a lot of discussion about whether to remove the string size limits.\r\nThat discussion ended with consensus to retain the size limits.", "submit_date": "2015-02-19", "submitter_name": "Ilya V. Matveychikov", "verifier_id": "", "verifier_name": "Kathleen Moriarty", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "5218", "doc-id": "RFC8259", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "12", "orig_text": "JSON is a subset of JavaScript", "correct_text": "JSON is nearly a subset of JavaScript", "notes": "JSON is not a subset of JavaScript: there are syntactically valid JSON texts that are not syntactically valid JavaScript. Namely, JSON strings can contain unescaped U+2028 LINE SEPARATOR or U+2029 PARAGRAPH SEPARATOR characters, while JavaScript string literals cannot. Thus, a sequence of characters U+0022 U+2028 U+0022 matches this RFC's 'string' production, but does not match ECMA-262's 'Expression' production.", "submit_date": "2017-12-28", "submitter_name": "Vasiliy Faronov", "verifier_id": "", "verifier_name": "Andy Newton", "update_date": "2026-05-28 18:33:08" }, { "errata_id": "5853", "doc-id": "RFC8259", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "11", "orig_text": "Note: No \"charset\" parameter is defined for this registration.\r\n Adding one really has no effect on compliant recipients.", "correct_text": "Note: No \"charset\" parameter is defined for this registration.\r\n JSON text is encoded as described in RFC 8259, Section 8.1.", "notes": "Last sentence of last note of section 11 should be amended, as it introduces confusion by going against other explicit statements, like the followings:\r\n * RFC8259 sect. 8.1 defines that inner encoding is UTF-8\r\n * RFC8259 sect. 11 defines no formal (optional/required) parameters for this registered type\r\n * RFC6838 sect. 4.2.1 defines the common usage of a \"charset\" parameter as a \"required\" one (which isn't the case here)\r\n * RFC6838 sect. 4.2.1 defines that \"charset\" should not be used if the inner payload already transports charset information (e.g. mandatory UTF-8, which is the case here)\r\n * RFC6838 sect. 4.2.1 defines a \"charset\" parameter only for subtypes of the \"text/*\" hierarchy (which isn't the case here)", "submit_date": "2019-09-05", "submitter_name": "Luca BRUNO", "verifier_id": "", "verifier_name": "Andy Newton", "update_date": "2026-05-28 18:34:26" }, { "errata_id": "7600", "doc-id": "RFC8259", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6", "orig_text": "The representation of numbers is similar to that used in most\r\n programming languages. A number is represented in base 10 using\r\n decimal digits. It contains an integer component that may be\r\n prefixed with an optional minus sign, which may be followed by a\r\n fraction part and/or an exponent part. Leading zeros are not\r\n allowed.", "correct_text": "The representation of numbers is similar to that used in most\r\n programming languages. A number is represented in base 10 using\r\n decimal digits. It contains an integer component that may be\r\n prefixed with an optional minus sign, which may be followed by a\r\n fraction part and/or an exponent part. Leading zeros in the\r\n integer component beyond the units digit are not allowed.", "notes": "The original wording about leading zeros contradicts the documented ABNF grammar for JSON numbers in the following cases:\r\n- If the integer component is equal to 0 and the fractional component exists. (Examples: 0.1, 0.001)\r\n- In the exponent part, after the letter E or e or the optional sign. (Example: 1E01)", "submit_date": "2023-08-11", "submitter_name": "Guillaume Fortin-Debigaré", "verifier_id": "", "verifier_name": "Andy Newton", "update_date": "2026-05-28 18:36:09" }, { "errata_id": "4382", "doc-id": "RFC5246", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "4.3", "orig_text": "In the following example, Datum is defined to be three consecutive\r\n bytes that the protocol does not interpret, while Data is three\r\n consecutive Datum, consuming a total of nine bytes.\r\n\r\n opaque Datum[3]; /* three uninterpreted bytes */\r\n Datum Data[9]; /* 3 consecutive 3 byte vectors */\r\n", "correct_text": "In the following example, Datum is defined to be three consecutive\r\n bytes that the protocol does not interpret, while Data is three\r\n consecutive Datum, consuming a total of nine bytes.\r\n\r\n opaque Datum[3]; /* three uninterpreted bytes */\r\n Datum Data[3]; /* 3 consecutive 3 byte vectors */\r\n", "notes": "The 9 in \"Datum Data[9]\" should be a 3 because Datum is a data type that consumes 3 bytes, so as written the Data vector is 27 bytes long. To make it a 9 byte vector the 9 must change to a 3.\n --VERIFIER NOTES-- \n This is not correct. The value here is the number of bytes, not the count of items.", "submit_date": "2015-05-29", "submitter_name": "Laura Corcoran", "verifier_id": "", "verifier_name": "EKR", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "4538", "doc-id": "RFC6793", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "8", "orig_text": "If the BGP4-MIB [RFC4273] is supported, there are no additional\r\nmanageability concerns that arise from the use of four-octet AS\r\nnumbers, since the InetAutonomousSystemNumber textual convention\r\n[RFC4001] is defined as Unsigned32.", "correct_text": "If the BGP4-MIBv2 [draft-ietf-idr-bgp4-mibv2] is supported, there are \r\nno additional manageability concerns that arise from the use of \r\nfour-octet AS numbers, since the InetAutonomousSystemNumber \r\ntextual convention [RFC4001] is defined as Unsigned32.", "notes": "I do not have corrected text. RFC4273 does not use InetAutonomousSystemNumber for AS numbers:\r\nbgpPeerRemoteAs OBJECT-TYPE\r\n SYNTAX Integer32 (0..65535)\r\n MAX-ACCESS read-only\r\n STATUS current\r\n DESCRIPTION\r\n \"The remote autonomous system number received in\r\n the BGP OPEN message.\"\r\n REFERENCE\r\n \"RFC 4271, Section 4.2.\"\r\n ::= { bgpPeerEntry 9 }\r\n\r\nThis uses \"Integer32 (0...65535)\" (note, Integer, not Unsigned Int). \r\nIt is unclear to me how to fix this, I know some folk are simply treating it as a UInt32.\r\n\r\n=====\r\nThe report is correct, rfc4273 can't support 4-byte ASNs.\r\n\r\nAfter consulting with the authors and the WG, it seems like the correct reference should have been \r\ndraft-ietf-idr-bgp4-mibv2 (BGP4 MIBv2). Besides the corrected text above, an Informative Reference should be added to draft-ietf-idr-bgp4-mibv2.", "submit_date": "2015-11-19", "submitter_name": "Warren Kumari", "verifier_id": "", "verifier_name": "Alvaro Retana", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "7080", "doc-id": "RFC8416", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "3.4.2", "orig_text": " The above is expressed as a value of the \"bgpsecAssertions\" member,\r\n as an array of zero or more objects. Each object MUST contain one\r\n each of all of the following members:\r\n\r\n o An \"asn\" member, whose value is a number.\r\n\r\n o An \"SKI\" member, whose value is the Base64 encoding without\r\n trailing '=' (Section 5 of [RFC4648]) of the certificate's Subject\r\n Key Identifier as described in Section 4.8.2 of [RFC6487] (This is\r\n the value of the ASN.1 OCTET STRING without the ASN.1 tag or\r\n length fields.)\r\n\r\n o A \"routerPublicKey\" member, whose value is the Base64 encoding\r\n without trailing '=' (Section 5 of [RFC4648]) of the equivalent to\r\n the subjectPublicKeyInfo value of the router certificate's public\r\n key, as described in [RFC8208]. This is the full ASN.1 DER\r\n encoding of the subjectPublicKeyInfo, including the ASN.1 tag and\r\n length values of the subjectPublicKeyInfo SEQUENCE.\r\n", "correct_text": " The above is expressed as a value of the \"bgpsecAssertions\" member,\r\n as an array of zero or more objects. Each object MUST contain one\r\n each of all of the following members:\r\n\r\n o An \"asn\" member, whose value is a number.\r\n\r\n o An \"SKI\" member, whose value is the Base64 encoding without\r\n trailing '=' (Section 5 of [RFC4648]) of the certificate's Subject\r\n Key Identifier as described in Section 4.8.2 of [RFC6487] (This is\r\n the value of the ASN.1 OCTET STRING without the ASN.1 tag or\r\n length fields.)\r\n\r\n o A \"routerPublicKey\" member, whose value is the Base64 encoding\r\n without trailing '=' (Section 5 of [RFC4648]) of the equivalent to\r\n the subjectPublicKeyInfo value of the router certificate's public\r\n key, as described in [RFC8208]. This is the full ASN.1 DER\r\n encoding of the subjectPublicKeyInfo, including the ASN.1 tag and\r\n length values of the subjectPublicKeyInfo SEQUENCE.\r\n\r\n In addition, each object MAY contain one optional \"comment\" member,\r\n whose value is a string.\r\n", "notes": "The \"comment\" member is allowed to appear in every other structure defined by the document, and was clearly intended to be allowed here too, since it appears in the examples presented in sections 3.4.2 and 3.5\r\n\r\n[Warren Kumari: See thread https://mailarchive.ietf.org/arch/msg/sidrops/uEc7K01ex0GJ6tE_FqfDwDTZTws/\r\n\r\nWe are not aware of any implementations which will choke on comments] ", "submit_date": "2022-08-10", "submitter_name": "Ben Maddison", "verifier_id": "", "verifier_name": "Warren Kumari (Ops AD)", "update_date": "2022-10-07 16:22:20" }, { "errata_id": "7107", "doc-id": "RFC9110", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "6.5.1", "orig_text": "For example, the chunked transfer coding in HTTP/1.1\r\nallows a trailer section to be sent after the content\r\n(Section 7.1.2 of [HTTP/1.1]).", "correct_text": "For example, the chunked transfer coding in HTTP/1.1\r\nallows a trailer section to be sent after the content\r\n(Section ?.?.? of [HTTP/1.1]).", "notes": "Section 7.1.2 does not exist. It isn't clear to me which section is the intended target of the reference.\n --VERIFIER NOTES-- \nErrata rejected per Julian Reschke. Section 7.1.2 does exist.\r\nSee .\r\n", "submit_date": "2022-08-31", "submitter_name": "James Synge", "verifier_id": "", "verifier_name": "RFC Editor", "update_date": "2022-10-12 21:39:50" }, { "errata_id": "7695", "doc-id": "RFC9111", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "4.3.2", "orig_text": " The proper evaluation of conditional requests by a cache depends on\r\n the received precondition header fields and their precedence. In\r\n summary, the If-Match and If-Unmodified-Since conditional header\r\n fields are not applicable to a cache, and If-None-Match takes\r\n precedence over If-Modified-Since. See Section 13.2.2 of [HTTP] for\r\n a complete specification of precondition precedence.", "correct_text": " The proper evaluation of conditional requests by a cache depends on\r\n the received precondition header fields and their precedence. In\r\n summary, the If-Match and If-Unmodified-Since conditional header\r\n fields are not applicable to a cache and hence such requests MUST\r\n be forwarded to the origin, and If-None-Match takes precedence\r\n over If-Modified-Since. See Section 13.2.2 of [HTTP] for a complete\r\n specification of precondition precedence.", "notes": "Correction:\r\n\"the If-Match and If-Unmodified-Since conditional header fields are not applicable\r\n to a cache [and hence such requests MUST be forwarded to the origin]\"\r\n\r\nThis is based upon the reading of RFC 9111#section-4.3.2-3[1]:\r\n \r\n A cache MUST NOT evaluate conditional header fields that only apply\r\n to an origin server, occur in a request with semantics that cannot be\r\n satisfied with a cached response, or occur in a request with a target\r\n resource for which it has no stored responses; such preconditions are\r\n likely intended for some other (inbound) server.\r\n\r\n\r\nCurrent RFC 9110#section-13.1.1-13[2], RFC 9110#section-13.2.2[3] and RFC \r\n9111#section-4.3.2-4[4] does not explicitly provide clear direction to cache servers as to \r\nhow to deal with If-Match and If-Unmodified-Since conditional headers[5].\r\n\r\nThe correction intends to provide more clarity for If-Match and If-Unmodified-Since\r\nheader as to how a cache server should handle conditional header which are meant\r\nfor origin server based on the reading of above produced section of \r\nthe RFC 9111#section-4.3.2-3.\r\n\r\nIf cache nodes have to ignore If-Match and If-Unmodified-Since header as per \r\nRFC 9110#section-13.1.1-13 then in scenarios where they have a cached non-expired\r\ncontent representation which can be satisfied sans If-Match and If-Unmodified-Since\r\nheaders the same will be returned back by cache and intermediary servers. \r\n\r\nCaching layers with multiple content representation cached in the network may \r\nreturn invalid response back causing higher requests errors when dealing with origin \r\napplicable conditional headers that are sent to intermediary cache nodes from \r\nedge cache nodes for cache hydration. \r\n\r\nConsider the below scenario:\r\n\r\n1. A caching system consisting of 2 cache layers with 3 servers each,\r\nServer nodes \"A\" representing Edge cache nodes(A1, A2, A3),\r\nServer nodes \"B\" representing intermediary cache nodes(B1, B2, B3), and an \r\norigin server\r\n\r\n2. All cache servers (A and B) make use of If-Match and If-Unmodified-Since to \r\nhydrate their own cached content representation as per RFC 9110#section-13.1.1-12 [6]\r\n\r\n3. All cache servers make use of 5MiB chunk ranges for cache hydration of large \r\nfiles \r\n\r\n4. Origin server contains a file foo with size 20MiB, with content \r\nrepresentation Etag E1 \r\n\r\n5. A client C1 who sends a range request for file foo with range 10-20MiB to edge node A1\r\n\r\n6. For initial set of requests sent by edge node A1 the representation E1 gets \r\ncached on 2 of the intermediary nodes B1 and B2 (because of 2 requests for \r\n5MiB chunk each) \r\n\r\n6. Content representation for file foo changes to Etag E2 on origin \r\n\r\n7. A client C2 who sends a range request for file foo with range 10-20MiB to edge node A2\r\n\r\n8. Requests to edge node A2 which does not have a cached representation causes it \r\nto send 2 range requests for 5MiB each, in this case lets assume it is sent to \r\nintermediary cache nodes B1(range:10-15MiB) and B3(range:15-20MiB), \r\nB3 node faces cache-miss and hydrates its own cache from Range 15Mib-20MiB\r\nwith content representation E2. B1 node already has a cached representation E1\r\nfor requested range so it returns it back. A2 node which has now cached 10-15MiB E1\r\nrepresentation received from B1 has to returns error and performs a cache reset for\r\nitself because of mixed representation for the whole user requested range.\r\n\r\nIn such a case where intermediary cache severs/nodes may end up with multiple \r\ncontent representation an edge node who is trying to hydrate its own cache \r\nwill find it hard to do so, i.e. the first 5MiB \r\nchunk may end up being served by intermediary cache nodes with representation \r\nE1 and the other half of the chunk by nodes who have a content representation \r\nE2. The error rates will be higher whenever content representation changes at\r\nthe origin server for such range requests.\r\n\r\n\r\n[1]: https://www.rfc-editor.org/rfc/rfc9111#section-4.3.2-3\r\n[2]: https://www.rfc-editor.org/rfc/rfc9110#section-13.1.1-13\r\n[3]: https://www.rfc-editor.org/rfc/rfc9110#section-13.2.2\r\n[4]: https://www.rfc-editor.org/rfc/rfc9111#section-4.3.2-4\r\n[5]: https://github.com/httpwg/http-core/issues/1111\r\n[6]: https://www.rfc-editor.org/rfc/rfc9110#section-13.1.1-12\n --VERIFIER NOTES-- \nThe suggestion is not a desired solution for the problematic text.\r\n\r\nThis part is not an error in the specification. Even when If-Match and If-Unmodified-Since are not applicable to a cache, their presence does not imply that the request must be forwarded to the origin. It will depend on other factors in the request and how/where the cache has been configured.\r\n\r\nSee https://mailarchive.ietf.org/arch/msg/httpbisa/k8UTKPDMQQZ-H5sHyJb7dldew7I/ for details.", "submit_date": "2023-11-07", "submitter_name": "Dron Rathore", "verifier_id": "", "verifier_name": "Francesca Palombini", "update_date": "2024-01-16 14:58:15" }, { "errata_id": "7109", "doc-id": "RFC9110", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "15.4.9", "orig_text": " The 308 (Permanent Redirect) status code indicates that the target\r\n resource has been assigned a new permanent URI and any future\r\n references to this resource ought to use one of the enclosed URIs.", "correct_text": " The 308 (Permanent Redirect) status code indicates that the target\r\n resource has been assigned a new permanent URI and any future\r\n references to this resource ought to use one of the enclosed URIs.\r\n The user agent MUST NOT change the request method if it performs\r\n an automatic redirection to that URI.\r\n\r\nand/or add note as is present in RFC 7538, e.g.:\r\n\r\n Note: This status code is similar to 301 (Moved Permanently)\r\n (Section 15.4.2), except that it does not allow changing\r\n the request method from POST to GET.", "notes": "The current text in this section for 308 Permanent Redirect does not include any mention of the user agent not changing the request method. I am suggesting that similar wording be used as in 15.4.8. 307 Temporary Redirect and/or a note added similar to the one present in RFC 7538 but excluded from this section's current text. Whichever is chosen, it would be good to make the wording/notes consistent across both the 307 and 308 status code sections.", "submit_date": "2022-08-31", "submitter_name": "Gary Wilson Jr.", "verifier_id": "", "verifier_name": "Francesca Palombini", "update_date": "2022-11-09 08:33:22" }, { "errata_id": "4750", "doc-id": "RFC5246", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.3 Vectors", "orig_text": "The length of\r\n an encoded vector must be an even multiple of the length of a single\r\n element (for example, a 17-byte vector of uint16 would be illegal).", "correct_text": "The length of\r\n an encoded vector must be a whole multiple of the length of a single\r\n element (for example, a 17-byte vector of uint16 would be illegal).", "notes": "Original text implies vectors can only contain even (0,2,4,6,8...) numbers of elements. The example does not resolve this but indicates the intent is that parts of elements are not allowed. It is clear from other examples that odd numbers of elements are permitted.\r\n\r\nPaul Wouters (AD): As TLS 1.2 is obsoleted by TLS 1.3, this errata is closed as Verified. In TLS 1.3 in RFC 8447 the text states more clearly: Here, T' occupies n bytes in the data stream, where n is a multiple of the size of T. \r\n\r\n", "submit_date": "2016-07-27", "submitter_name": "Adrien de Croy", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-01-16 02:41:39" }, { "errata_id": "7603", "doc-id": "RFC8259", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "1", "orig_text": "A string is a sequence of zero or more Unicode characters [UNICODE].", "correct_text": "A string is a sequence of zero or more Unicode code points [UNICODE].", "notes": "Surrogate code points are not Unicode characters, as explained here: https://www.unicode.org/glossary/#surrogate_character\r\n\r\nHowever, a surrogate code point outside of a surrogate pair is allowed in JSON strings both in escaped and unescaped forms according to the ABNF grammar in section 7 and the warning in section 8.2, despite an UTF-8 incompatibility for the unescaped form. In addition, the original text contradicts ECMA-404 section 9, which states: \"A string is a sequence of Unicode code points wrapped with quotation marks (U+0022). All code points may be placed within the quotation marks except for the code points that must be escaped: quotation mark (U+0022), reverse solidus (U+005C), and the control characters U+0000 to U+001F. \"", "submit_date": "2023-08-13", "submitter_name": "Guillaume Fortin-Debigaré", "verifier_id": "", "verifier_name": "Andy Newton", "update_date": "2026-05-28 18:37:21" }, { "errata_id": "7105", "doc-id": "RFC9110", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "B.1.", "orig_text": "B.1. Changes from RFC 2818\r\n\r\n None.", "correct_text": "B.1. Changes from RFC 2818\r\n\r\n The use of CN-ID has been deprecated.", "notes": "In RFC2818:\r\n\r\n If a subjectAltName extension of type dNSName is present, that MUST\r\n be used as the identity. Otherwise, the (most specific) Common Name\r\n field in the Subject field of the certificate MUST be used.\r\n\r\nCN-ID may be used (when a subjectAltName of type dNSName is not present).\r\n\r\nIn RFC9110:\r\n\r\n A reference identity of type CN-ID MUST NOT be used by clients.\r\n\r\nCN-ID is not used at all. It is a change from RFC2818.", "submit_date": "2022-08-26", "submitter_name": "Tomoyuki Sahara", "verifier_id": "", "verifier_name": "Francesca Palombini", "update_date": "2022-11-01 15:53:42" }, { "errata_id": "4830", "doc-id": "RFC7854", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.9", "orig_text": "Peer Down Notification\r\n\r\n This message is used to indicate that a peering session was\r\n terminated.\r\n\r\n 0 1 2 3\r\n 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\r\n +-+-+-+-+-+-+-+-+\r\n | Reason |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Data (present if Reason = 1, 2 or 3) |\r\n ~ ~\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", "correct_text": "Peer Down Notification\r\n\r\n This message is used to indicate that a peering session was\r\n terminated. Following the common BMP header and per-peer header is \r\n the following:\r\n\r\n 0 1 2 3\r\n 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\r\n +-+-+-+-+-+-+-+-+\r\n | Reason |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Data (present if Reason = 1, 2 or 3) |\r\n ~ ~\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", "notes": "What: \r\n\r\nFor Peer Down Notification: To the programmer implementing the RFC, it is not clear if the Peer Down message consists of per peer header", "submit_date": "2016-10-12", "submitter_name": "Suhas Anand", "verifier_id": "", "verifier_name": "Joel Jaeggli", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "7703", "doc-id": "RFC7854", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2", "orig_text": " * The L flag, if set to 1, indicates that the message reflects\r\n the post-policy Adj-RIB-In (i.e., its path attributes reflect\r\n the application of inbound policy). It is set to 0 if the\r\n message reflects the pre-policy Adj-RIB-In. Locally sourced\r\n routes also carry an L flag of 1. See Section 5 for further\r\n detail. This flag has no significance when used with route\r\n mirroring messages (Section 4.7).", "correct_text": " * The L flag, if set to 1, indicates that the message reflects\r\n the post-policy Adj-RIB-In (i.e., its path attributes reflect\r\n the application of inbound policy). It is set to 0 if the\r\n message reflects the pre-policy Adj-RIB-In. Locally sourced\r\n routes also carry an L flag of 1. See Section 5 for further\r\n detail. This flag has significance only when used with Route\r\n Monitoring messages.", "notes": "The L flag is used to indicate whether the route monitoring update reflects Adj-RIB-In pre-policy or post-policy (RFC 7854), or Adj-RIB-Out pre-policy or post-policy (RFC 8671). It does not apply to any message other than the Route Monitoring message.\r\n", "submit_date": "2023-11-16", "submitter_name": "Dhananjay S. Patki", "verifier_id": "", "verifier_name": "Warren Kumari (Ops AD)", "update_date": "2023-12-11 16:50:18" }, { "errata_id": "4847", "doc-id": "RFC5280", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "A.1", "orig_text": " id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }\r\n -- arc for policy qualifier types\r\n id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }\r\n| -- arc for extended key purpose OIDS\r\n id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }\r\n -- arc for access descriptors", "correct_text": " id-qt OBJECT IDENTIFIER ::= { id-pkix 2 }\r\n -- arc for policy qualifier types\r\n id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }\r\n| -- arc for extended key purpose OIDs\r\n id-ad OBJECT IDENTIFIER ::= { id-pkix 48 }\r\n -- arc for access descriptors", "notes": "\"Object Identifiers\" are abbreviated as \"OIDs\" and not as \"OIDS\".", "submit_date": "2016-10-30", "submitter_name": "Annie Yousar", "verifier_id": "", "verifier_name": "Stephen Farrell", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "4912", "doc-id": "RFC5246", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "A.4.1", "orig_text": " SignatureAndHashAlgorithm\r\n supported_signature_algorithms<2..2^16-1>;\r\n", "correct_text": " SignatureAndHashAlgorithm\r\n supported_signature_algorithms<2..2^16-2>;\r\n", "notes": "Error in last sentence. See errata ID 2865.\r\n\r\nPaul Wouters (AD): From errata ID 2865: The supported_signature_algorithms field is a variable length array. As such ceiling and floor should be specified, and they should be multiple of the base type (which is two bytes long in this case). See section 7.4.1.4.1 for a valid definition of this field.\r\nThis is already fixed in TLS 1.3 RFC8446", "submit_date": "2017-01-18", "submitter_name": "Nikolai Malykh", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-01-16 02:47:43" }, { "errata_id": "4885", "doc-id": "RFC5246", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "6.1.", "orig_text": " server random\r\n A 32-byte value provided by the server.\r\n\r\n These parameters are defined in the presentation language as:\r\n\r\n enum { server, client } ConnectionEnd;", "correct_text": " server random\r\n A 32-byte value provided by the server.\r\n\r\n These parameters are defined in the presentation language as:\r\n\r\n enum { server, client } ConnectionEnd;", "notes": "The line \"These parameters are ...\" after the list of parameters is at the same indentation level as the list of parameters, instead of coming back left by one level.", "submit_date": "2016-12-13", "submitter_name": "Wail Yahyaoui", "verifier_id": "", "verifier_name": "Stephen Farrell", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "5001", "doc-id": "RFC4271", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "5", "orig_text": " BGP implementations MUST recognize all well-known attributes. Some\r\n of these attributes are mandatory and MUST be included in every\r\n UPDATE message that contains NLRI. Others are discretionary and MAY\r\n or MAY NOT be sent in a particular UPDATE message.\r\n", "correct_text": " BGP implementations MUST recognize all well-known attributes. Some\r\n of these attributes are mandatory and MUST be included in every\r\n UPDATE message that contains NLRI. Others are discretionary and may\r\n or may not be sent in a particular UPDATE message.", "notes": "The original text uses \"MAY NOT\" capitalized as if it were an RFC 2119 keyword. However, RFC 2119 does not have any defined meaning for \"MAY NOT\". In context, it is unlikely the reader would be at risk of misinterpreting the text, but nonetheless it's a misuse of RFC 2119 terminology and difficult to parse if reading closely.\r\n\r\n(The replacement text was suggested by Eric Rosen; thanks.)\r\n\r\n=====\r\nI updated the Corrected Text to simply use lower case wording, eliminating any rfc2119-related confusion. -- Alvaro.", "submit_date": "2017-04-19", "submitter_name": "John Scudder", "verifier_id": "", "verifier_name": "Alvaro Retana", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "5000", "doc-id": "RFC4271", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "9.1.1", "orig_text": " If the route is learned from an external peer, then the local BGP\r\n speaker computes the degree of preference based on preconfigured\r\n policy information. If the return value indicates the route is\r\n ineligible, the route MAY NOT serve as an input to the next phase\r\n of route selection; otherwise, the return value MUST be used as\r\n the LOCAL_PREF value in any IBGP readvertisement.\r\n", "correct_text": " If the route is learned from an external peer, then the local BGP\r\n speaker computes the degree of preference based on preconfigured\r\n policy information. If the return value indicates the route is\r\n ineligible, the route MUST NOT serve as an input to the next phase\r\n of route selection; otherwise, the return value MUST be used as\r\n the LOCAL_PREF value in any IBGP readvertisement.\r\n", "notes": "The original text uses \"MAY NOT\" capitalized as if it were an RFC 2119 keyword. However, RFC 2119 does not have any defined meaning for \"MAY NOT\". If a reader were to interpret this text as suggesting it is optional -- meaning, in effect, \"the route MAY serve as an input to the next phase of route selection\" -- that would be wrong and potentially problematic.\r\n\r\nThe minimal correction would be to use lower-case \"may not\", which makes the proper meaning reasonably clear. However, the English construct \"may not\" is notoriously ambiguous, therefore the proposed correction is \"MUST NOT\".\r\n\r\n=====\r\nAfter consultation with the idr WG, it was confirmed that the correct interpretation (based on implementation experience) is \"MUST NOT\". --- Alvaro.", "submit_date": "2017-04-19", "submitter_name": "John Scudder", "verifier_id": "", "verifier_name": "Alvaro Retana", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "5022", "doc-id": "RFC8174", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "GLOBAL", "orig_text": "by clarifying that only UPPERCASE usage of the key words have the\r\ndefined special meanings.", "correct_text": "by clarifying that only UPPERCASE usage of the key words has the\r\ndefined special meanings.", "notes": "The text appears in both \"Abstract\" and Section 1. The verb should be \"has\" because \"usage\" is a singular noun.", "submit_date": "2017-05-19", "submitter_name": "Xiaoyin Liu", "verifier_id": "", "verifier_name": "Ben Campbell", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "5036", "doc-id": "RFC5246", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "7.4.1.2", "orig_text": "The ClientHello Structure indicates that a SessionID could be present.\r\nHowever if I take a wireshark of a TLS session I always see a \"Session \r\nID Length\" field, either with value 0 or value 32", "correct_text": "In the ClientHello structure and ServerHello structure, include \r\na 1 byte \"Session ID Length\" field.", "notes": "The ClientHello Structure indicates that a SessionID could be present.\r\nHowever if I take a wireshark of a TLS session I always see a \r\n\"Session ID Length\" field, either with value 0 or value 32.\n --VERIFIER NOTES-- \nThis erratum is incorrect.\r\n\r\nHere is the definition of SessionID:\r\n opaque SessionID<0..32>;\r\n\r\nThe angle brackets mean that it is variable length and the 0..32 means that there is\r\na one-byte length field.", "submit_date": "2017-06-09", "submitter_name": "Stefan Goeman", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-18 04:06:12" }, { "errata_id": "7617", "doc-id": "RFC8259", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "6", "orig_text": "Note that when such software is used, numbers that are integers and\r\n are in the range [-(2**53)+1, (2**53)-1] are interoperable in the\r\n sense that implementations will agree exactly on their numeric\r\n values.", "correct_text": "Note that when such software parses numbers as rational numbers in\r\n decimal or scientific notation, they are interoperable in the sense\r\n that implementations will agree exactly on their numeric values. In\r\n particular, when such software is used, numbers that are integers and\r\n are in the range [-(2**53)+1, (2**53)-1] are interoperable in that\r\n sense.", "notes": "IEEE 754 does not consider negative zero and positive zero to be the same numeric value, even though it considers them equal. Despite this, JavaScript serializes negative zero as the JSON text \"0\", which contradicts the original text.\r\n\r\nMy suggested correction mentions \"rational numbers in decimal or scientific notation\" since it's never explicitly mentioned in the document how a number should be interpreted when parsed to maximize interoperability. This version addresses that concern at the same time.", "submit_date": "2023-08-25", "submitter_name": "Guillaume Fortin-Debigaré", "verifier_id": "", "verifier_name": "Andy Newton", "update_date": "2026-05-28 18:38:09" }, { "errata_id": "5101", "doc-id": "RFC2119", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "5", "orig_text": "5. MAY This word, or the adjective \"OPTIONAL\", mean that an item is\r\n truly optional. One vendor may choose to include the item because a\r\n particular marketplace requires it or because the vendor feels that\r\n it enhances the product while another vendor may omit the same item.\r\n An implementation which does not include a particular option MUST be\r\n prepared to interoperate with another implementation which does\r\n include the option, though perhaps with reduced functionality. In the\r\n same vein an implementation which does include a particular option\r\n MUST be prepared to interoperate with another implementation which\r\n does not include the option (except, of course, for the feature the\r\n option provides.)", "correct_text": "5. MAY This word, or the adjective \"OPTIONAL\", mean that an item is\r\n truly optional. One vendor may choose to include the item because a\r\n particular marketplace requires it or because the vendor feels that\r\n it enhances the product while another vendor may omit the same item.\r\n An implementation which does not include a particular option MUST be\r\n prepared to interoperate with another implementation which does\r\n include the option, though perhaps with reduced functionality. In the\r\n same vein an implementation which does include a particular option\r\n MUST be prepared to interoperate with another implementation which\r\n does not include the option (except, of course, for the feature the\r\n option provides).", "notes": "Full stop should appear outside the parentheses in the last sentence.", "submit_date": "2017-08-29", "submitter_name": "Jim Tonti", "verifier_id": "", "verifier_name": "Warren Kumari", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "5196", "doc-id": "RFC6480", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "6", "orig_text": " 3. For each manifest, verify that certificates and CRLs issued\r\n under the corresponding CA certificate match the hash values\r\n contained in the manifest. Additionally, verify that no\r\n certificate or manifest listed on the manifest is missing from\r\n the repository. If the hash values do not match, or if any\r\n certificate or CRL is missing, notify the appropriate\r\n repository administrator that the repository data has been\r\n corrupted.\r\n", "correct_text": " 3. For each manifest, verify that certificates and CRLs issued\r\n under the corresponding CA certificate match the hash values\r\n contained in the manifest. Additionally, verify that no\r\n certificate or CRL listed on the manifest is missing from\r\n the repository. If the hash values do not match, or if any\r\n certificate or CRL is missing, notify the appropriate\r\n repository administrator that the repository data has been\r\n corrupted.\r\n", "notes": "On the fourth line: it should read \"certificate or CRL\" instead of \"certificate or manifest\".", "submit_date": "2017-12-05", "submitter_name": "Nikolai Malykh", "verifier_id": "", "verifier_name": "Alvaro Retana", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "5206", "doc-id": "RFC2119", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "5", "orig_text": "MAY This word, or the adjective \"OPTIONAL\", mean", "correct_text": "MAY This word, or the adjective \"OPTIONAL\", means", "notes": "This correction is analogous to that pointed out by Erratas 495, 498, 500 and 2969 for sections 1, 3 and 4, but for section. The correction replaces \"mean\" with \"means\"", "submit_date": "2017-12-14", "submitter_name": "Hugo Gabriel Eyherabide", "verifier_id": "", "verifier_name": "Lars Eggert", "update_date": "2021-03-11 07:35:30" }, { "errata_id": "7133", "doc-id": "RFC7854", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "5", "orig_text": " In BMP's normal operating mode, after the BMP session is up, Route\r\n Monitoring messages are used to provide a snapshot of the Adj-RIB-In\r\n of each monitored peer. This is done by sending all routes stored in\r\n the Adj-RIB-In of those peers using standard BGP Update messages,\r\n encapsulated in Route Monitoring messages. There is no requirement\r\n on the ordering of messages in the peer dumps. When the initial dump\r\n is completed for a given peer, this MUST be indicated by sending an\r\n End-of-RIB marker for that peer (as specified in Section 2 of\r\n [RFC4724], plus the BMP encapsulation header). See also Section 9.\r\n", "correct_text": "Regrettably, there is no straightforward correction. Please see the notes for details.", "notes": "BMP is specified in the indicated text as sending \"an End-of-RIB marker for that peer\". The problem is that End-of-RIB (EoR) markers aren't specified in RFC 4724 as being per-peer, but per address family (AF), thus it doesn't make sense to talk about sending a single EoR to indicate BMP completion, except in the special case where BMP is only transporting routes for a single address family. \r\n\r\nThis problem also occurs in Section 3.3:\r\n\r\n encapsulated in Route Monitoring messages. Once it has sent all the\r\n routes for a given peer, it MUST send an End-of-RIB message for that\r\n peer; when End-of-RIB has been sent for each monitored peer, the\r\n initial table dump has completed. (A monitoring station that only\r\n wants to gather a table dump could close the connection once it has\r\n gathered an End-of-RIB or Peer Down message corresponding to each\r\n Peer Up message.)\r\n\r\nbut the underlying fault is in Section 5, so that's what I've referenced above.\r\n\r\nThere are various fixes that could be applied. Some of them include:\r\n\r\n1. Remove all references to EoR. Don't require that an EoR be sent in §5, don't talk about what to do with it in §3.3. I'm not very fond of this option, its only merit is that it's simple to specify the textual changes.\r\n\r\n2. Update §5 to note that an EoR has to be sent per AF, and update §3.3 similarly, including in the parenthetical comment noting that the station would have to gather an EoR per AF that's supported on the session.\r\n\r\n3. Introduce a new BMP message \"end of initial BMP convergence\" to provide the functionality. Probably this would be in addition to the fixes in #2, since it's still useful to know that a given AF dump has completed. But introduction of the new message would provide a simpler and probably more reliable way for the monitoring station to know that BMP-level synchronization had completed.\r\n\r\nIt seems to me that the best way to address this will be with either a new spec that updates RFC 7854, or an rfc7854bis. For this reason, I suggest this erratum should be verified as \"hold for document update\", since the solution requires more WG discussion and consensus than an erratum can provide.\r\n\r\nThis issue was first reported by Vincent Bernat in https://mailarchive.ietf.org/arch/msg/idr/FOEcdxtI03CdgDrn497NBFSpz-s/, and see also https://mailarchive.ietf.org/arch/msg/grow/o16w8s5Ba9J4MdIipbxIqDiZrCI/\r\n\r\n===Verifier notes\r\n\r\nSee also https://mailarchive.ietf.org/arch/msg/grow/7ZFA52R3KI9pgpAN302xLl9MBBA/", "submit_date": "2022-09-14", "submitter_name": "John Scudder", "verifier_id": "", "verifier_name": "Mohamed Boucadair", "update_date": "2025-06-02 04:39:32" }, { "errata_id": "5352", "doc-id": "RFC5246", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "6.2.3.3.", "orig_text": "struct {\r\n opaque nonce_explicit[SecurityParameters.record_iv_length];\r\n aead-ciphered struct {\r\n opaque content[TLSCompressed.length];\r\n };\r\n} GenericAEADCipher;", "correct_text": "struct {\r\n opaque nonce_explicit[SecurityParameters.record_iv_length];\r\n aead-ciphered struct {\r\n opaque content[TLSCiphertext.length];\r\n };\r\n} GenericAEADCipher;", "notes": "6.2.3.3. says: \"The aead_output consists of the ciphertext output by the AEAD encryption operation. The length will generally be larger than TLSCompressed.length, [...]\".\r\n\r\nThe definition is duplicated at A.1., and needs the same adjustment.\n --VERIFIER NOTES-- \naead-ciphered is an operator that takes content as the input.", "submit_date": "2018-05-09", "submitter_name": "Loic Etienne", "verifier_id": "", "verifier_name": "Eric Rescorla", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "5369", "doc-id": "RFC4271", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "9.2.2.2", "orig_text": " route MUST have the ORIGIN attribute with the value EGP. In\r\n all other cases,, the value of the ORIGIN attribute of the\r\n aggregated route is IGP.", "correct_text": " route MUST have the ORIGIN attribute with the value EGP. In\r\n all other cases, the value of the ORIGIN attribute of the\r\n aggregated route is IGP.", "notes": "Extra comma after 'cases'.", "submit_date": "2018-05-25", "submitter_name": "Eric Osborne", "verifier_id": "", "verifier_name": "RFC Editor", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "7138", "doc-id": "RFC9110", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "12.5.1", "orig_text": "The media type quality factor associated with a given type is \r\ndetermined by finding the media range with the highest precedence \r\nthat matches the type. For example,\r\n\r\nAccept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,\r\n text/plain;format=fixed;q=0.4, */*;q=0.5\r\n\r\nwould cause the following values to be associated:\r\n\r\nTable 5: \r\n\r\nMedia Type\t Quality Value\r\ntext/plain;format=flowed\t 1\r\ntext/plain\t 0.7\r\ntext/html\t 0.3\r\nimage/jpeg\t 0.5\r\ntext/plain;format=fixed\t 0.4\r\ntext/html;level=3\t 0.7", "correct_text": "The media type quality factor associated with a given type is \r\ndetermined by finding the media range with the highest precedence \r\nthat matches the type. For example,\r\n\r\nAccept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed,\r\n text/plain;format=fixed;q=0.4, */*;q=0.5\r\n\r\nwould cause the following values to be associated:\r\n\r\nTable 5: \r\n\r\nMedia Type\t Quality Value\r\ntext/plain;format=flowed\t 1\r\ntext/plain\t 0.7\r\ntext/html\t 0.3\r\nimage/jpeg\t 0.5\r\ntext/plain;format=fixed\t 0.4\r\ntext/html;level=3\t 0.3", "notes": "To illustrate how the media type quality factor associated with a given type is determined, the following example is given: \r\n\r\nAccept: text/*;q=0.3, text/plain;q=0.7, text/plain;format=flowed, text/plain;format=fixed;q=0.4, */*;q=0.5\r\n\r\nThe last row of the result table (table 5) presenting the values to be associated cannot be deduced (MediaType: text/html;level=3, Quality Value: 0.7), since only \"text/*;q=0.3\" and \"*/*;q=0.5\" are possible values and as explained in the RFC \"text/*;q=0.3\" should take precedence. \r\n\r\nIn section 5.3.2 of RFC7231, a similar example is given, where the last row of the table is correct (text/html;level=3 | 0.7) since in that example the accept header contains (text/html;q=0.7).", "submit_date": "2022-09-23", "submitter_name": "Yousouf Taghzouti", "verifier_id": "", "verifier_name": "Francesca Palombini", "update_date": "2022-11-09 08:34:16" }, { "errata_id": "5409", "doc-id": "RFC5246", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "Appendix A.5", "orig_text": " Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are\r\n reserved to avoid collision with Fortezza-based cipher suites in\r\n SSL 3.", "correct_text": " Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are\r\n reserved to avoid collision with Fortezza-based cipher suites in\r\n SSL 3. The cipher suite value { 0x00, 0x1E } firstly also assigned to\r\n Fortezza has been released and has since been be reassigned. ", "notes": "RFC 2712 (Addition of Kerberos Cipher Suites to Transport Layer Security) in its Draft 01 version introduces three new cipher suites colliding with the three Fortezza ones. The Draft 02 version partially corrects that, by moving the Kerberos cipher suites values by two.\r\nThis omission of the third cipher suite has never been corrected, and this remains in the same state in the final RFC 2712, RFC 2246 and its successors including this one.\r\n\r\nChanging the first Kerberos cipher suite value, or moving all of them, would now not make any sense. Enhancing the note as suggested is probably enough to mention how one Fortezza cipher suite disappeared.\n --VERIFIER NOTES-- \n RFC 5246 is not the appropriate location to document this conflict.", "submit_date": "2018-06-26", "submitter_name": "Eugene Adell", "verifier_id": "", "verifier_name": "Benjamin Kaduk", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "5421", "doc-id": "RFC4271", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "8.2.2", "orig_text": "If the local system receives a KeepaliveTimer_Expires event (Event\r\n 11), the local system:\r\n\r\n - sends a KEEPALIVE message,\r\n\r\n - restarts the KeepaliveTimer, and\r\n\r\n - remains in the OpenConfirmed state.", "correct_text": "If the local system receives a KeepaliveTimer_Expires event (Event\r\n 11), the local system:\r\n\r\n - sends a KEEPALIVE message,\r\n\r\n - restarts the KeepaliveTimer, and\r\n\r\n - remains in the OpenConfirm state.", "notes": "", "submit_date": "2018-07-15", "submitter_name": "Greg Skinner", "verifier_id": "", "verifier_name": "Alvaro Retana", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "5483", "doc-id": "RFC8446", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2.8.2", "orig_text": "For X25519 and X448, the contents of the public value are the byte\r\nstring inputs and outputs of the corresponding functions defined in\r\n[RFC7748]: 32 bytes for X25519 and 56 bytes for X448.", "correct_text": "For X25519 and X448, the contents of the public value are the byte\r\nstring outputs of the corresponding functions defined in [RFC7748]: 32\r\nbytes for X25519 and 56 bytes for X448.", "notes": "Per Section 7.4.2 of this RFC and Section 6 of RFC7748, the byte string inputs to the corresponding ECDH scalar multiplication function are the private key and the u-coordinate of the standard public base point, the former of which of course must not be transmitted and the latter of which is a known constant.\r\n\r\nPaul Wouters (AD): Resolved but with the following Corrected Text:\r\n\r\nFor X25519 and X448, the contents of the public value is the K_A or\r\nK_B value described in Section 6 of [RFC7748]. This is 32 bytes for\r\nX25519 and 56 bytes for X448.\r\n\r\nFrom another perspective, including the byte string inputs in the contents of the public value would contradict the resulting content sizes given at the end of the cited paragraph as well as the statement in Section 7.4.2 that the public key put into the KeyShareEntry is the output of ECDH scalar multiplication function.", "submit_date": "2018-08-28", "submitter_name": "Patrick Kelsey", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-29 00:57:07" }, { "errata_id": "5535", "doc-id": "RFC5246", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "4.7", "orig_text": " In DSA, the 20 bytes of the SHA-1 hash are run directly through the\r\n Digital Signing Algorithm with no additional hashing. ...", "correct_text": " In DSA, the bytes of the selected hash are run directly through the\r\n Digital Signing Algorithm with no additional hashing. ...", "notes": "In 2246 and 4346 this statement (then using the less-accurate spellings DSS and SHA) was correct because only SHA1 was used for DSA (and ECDSA, in 4492, versus SHA1+MD5 for RSA), but 5246 changed this to allow specifying one of several hashes, with selection constrained by the signature_algorithms extension (if present) or CertificateRequest field from the peer.\r\n\r\nFIPS 186 actually defines the hashing step as part of signature generation and verification, so it might be even better to make this something like \"For DSA, signature generation applies the selected hash [to the contents] and then computes two values, r and s.\" similar to the way the preceding paragraph of 5246 \"In RSA signing\" differs from the 2246 and 4346 versions by no longer treating the hashing as separate, but that is a bigger change to an obsoleted document, and arguably problematic because the normative reference is FIPS 186-2; as indicated in Appendix B on page 80, 186-3 which officially allowed DSA to use FIPS 180-3 hashes (not only SHA-1) was released in draft before 5246 but not finalized until after (2006-03 to 2009-06 versus 2008-08).\n --VERIFIER NOTES-- \n As described in the reported Notes, at the time of publication, the DSA specification in force only allowed for the usage of SHA-1. So the document was correct at time of publication and an errata is not appropriate, even though subsequent events have allowed for the usage of a broader set of hash algorithms with DSA.", "submit_date": "2018-10-19", "submitter_name": "Dave Thompson", "verifier_id": "", "verifier_name": "Benjamin Kaduk", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "7164", "doc-id": "RFC5280", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "5.2.5", "orig_text": " If the distributionPoint field is absent, the CRL MUST contain\r\n entries for all revoked unexpired certificates issued by the CRL\r\n issuer, if any, within the scope of the CRL.", "correct_text": " If the distributionPoint field is absent, the CRL MUST contain\r\n entries for all revoked unexpired certificates issued by the CRL\r\n issuer.", "notes": "The removed phrase does not appear in the original text that this requirement is derived from, ITU-T Rec. X.509 (08/2005) Section 8.6.2.2: \"If the issuing distribution point field, the AA issuing distribution point field, and the CRL scope field are all absent, the CRL shall contain entries for all revoked unexpired public-key certificates issued by the CRL issuer.\"\r\n\r\nThe removed phrase does not serve to create a stricter requirement; rather it creates a looser requirement which allows a CRL which does contain entries for all revoked unexpired certificates *within its scope* to not include the distributionPoint field. Given that the distributionPoint field serves an important security purpose in preventing substitution attacks, it is unlikely that this loosening was the intent of the original authors.\n --VERIFIER NOTES-- \n Verifier notes: Discussed here: https://mailarchive.ietf.org/arch/msg/pkix/YuErTrIPYt7MzTKE6R_KRqNouto/", "submit_date": "2022-10-14", "submitter_name": "Aaron Gable", "verifier_id": "", "verifier_name": "Deb Cooley", "update_date": "2024-10-29 15:35:05" }, { "errata_id": "5563", "doc-id": "RFC4252", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8.", "orig_text": " SSH_MSG_USERAUTH_FAILURE without partial success - The password\r\n has not been changed. Either password changing was not supported,\r\n or the old password was bad. Note that if the server has already\r\n sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports\r\n changing the password.\r\n\r\n SSH_MSG_USERAUTH_CHANGEREQ - The password was not changed because\r\n the new password was not acceptable (e.g., too easy to guess).", "correct_text": " SSH_MSG_USERAUTH_FAILURE without partial success - The password\r\n has not been changed. Either password changing was not supported,\r\n or the old password was bad. Note that if the server has already\r\n sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports\r\n changing the password.\r\n\r\n SSH_MSG_USERAUTH_PASSWD_CHANGEREQ - The password was not changed \r\n because the new password was not acceptable (e.g., too easy to \r\n guess).", "notes": "SSH_MSG_USERAUTH_PASSWD_CHANGEREQ seems to have been truncated to SSH_MSG_USERAUTH_CHANGEREQ for no apparent reason.", "submit_date": "2018-11-27", "submitter_name": "Benoît Morgan", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2023-07-28 17:59:44" }, { "errata_id": "5627", "doc-id": "RFC8446", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4.2.11", "orig_text": "In TLS versions prior to TLS 1.3, the Server Name Identification\r\n(SNI) value ", "correct_text": "In TLS versions prior to TLS 1.3, the Server Name Indication\r\n(SNI) value ", "notes": "RFC 6066 and many other places indicate that the correct expansion for \"SNI\" is \"Server Name Indication\", not \"Server Name Identification\".", "submit_date": "2019-02-08", "submitter_name": "Daniel Kahn Gillmor", "verifier_id": "", "verifier_name": "Benjamin Kaduk", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "5654", "doc-id": "RFC6125", "errata_status_code": "Reported", "errata_type_code": "Technical", "section": "7.4", "orig_text": " A more recent approach, formally specified in [TLS-EXT], is for the\r\n client to use the TLS \"Server Name Indication\" (SNI) extension when\r\n sending the client_hello message, stipulating the DNS domain name it\r\n desires or expects of the service. The service can then return the\r\n appropriate certificate in its Certificate message, and that\r\n certificate can represent a single DNS domain name.", "correct_text": " A more recent approach, formally specified in [TLS-EXT], is for the\r\n client to use the TLS \"Server Name Indication\" (SNI) extension when\r\n sending the client_hello message, stipulating the DNS domain name it\r\n desires or expects of the service. The service can then return the\r\n appropriate certificate in its Certificate message, and that\r\n certificate can represent a single DNS domain name. The client SHOULD\r\n include the \"source domain\" in the SNI extension and SHOULD NOT\r\n include the “derived domain”.\r\n", "notes": "There is nothing wrong with the text, however its missing some clarifying text.\r\n\r\nWhen a client discovers a service using SRV, when it is doing TLS it should include the \"source domain\" in the SNI extension and SHOULD NOT include the “derived domain” in SNI. Now, this is obviously the correct thing to do. However, it doesnt explicitly state this anywhere in the RFC, or in RFC6066.", "submit_date": "2019-03-13", "submitter_name": "Owen Friel", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03" }, { "errata_id": "5673", "doc-id": "RFC6125", "errata_status_code": "Reported", "errata_type_code": "Editorial", "section": "GLOBAL", "orig_text": " If the certificate will be used for only a single type of application\r\n service, then the service provider is encouraged to request a\r\n certificate that includes a DNS-ID and, if appropriate for the\r\n application service type, an SRV-ID or URI-ID that limits the\r\n deployment scope of the certificate to only the defined application\r\n service type.", "correct_text": " If the certificate will be used for only a single type of application\r\n service, the service provider is encouraged to request a\r\n certificate that includes a DNS-ID and, if appropriate for the\r\n application service type, an SRV-ID or URI-ID that limits the\r\n deployment scope of the certificate to only the defined application\r\n service type.", "notes": "All the sentences in the RFC (not just the one above) are written as pseudo code using IF...THEN. Normative English sentence structure the IF is a Conjunction for a Subordinating Clause. The THEN after the comma should be dropped to start the subject or main clause of the sentence.", "submit_date": "2019-03-25", "submitter_name": "Michael James", "verifier_id": "", "verifier_name": null, "update_date": "2019-09-10 16:09:03" }, { "errata_id": "5682", "doc-id": "RFC8446", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.3.2, B.3.2", "orig_text": " struct {\r\n opaque certificate_request_context<0..2^8-1>;\r\n Extension extensions<2..2^16-1>;\r\n } CertificateRequest;", "correct_text": " struct {\r\n opaque certificate_request_context<0..2^8-1>;\r\n Extension extensions<0..2^16-1>;\r\n } CertificateRequest;", "notes": "The length of this vector can never 2. It is either 0, if the vector is empty, or >=4, if the vector has at least one extension. Nothing elsewhere in the spec requires a non-zero number of extensions here, so this syntax should allow a zero-length vector.\r\n\r\nPaul Wouters (AD): There are two places in the mentioned sections that need this one liner fix.", "submit_date": "2019-04-01", "submitter_name": "Richard Barnes", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-01-22 18:29:40" }, { "errata_id": "5717", "doc-id": "RFC8446", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "2.2.", "orig_text": " Figure 3 shows a pair of handshakes in which the first handshake\r\n establishes a PSK and the second handshake uses it:\r\n \r\n Client Server\r\n \r\n Initial Handshake:\r\n ClientHello\r\n + key_share -------->\r\n ServerHello\r\n + key_share\r\n {EncryptedExtensions}\r\n {CertificateRequest*}\r\n {Certificate*}\r\n {CertificateVerify*}\r\n {Finished}\r\n <-------- [Application Data*]\r\n {Certificate*}\r\n {CertificateVerify*}\r\n {Finished} -------->\r\n <-------- [NewSessionTicket]\r\n [Application Data] <-------> [Application Data]\r\n \r\n \r\n Subsequent Handshake:\r\n ClientHello\r\n + key_share*\r\n + pre_shared_key -------->\r\n ServerHello\r\n + pre_shared_key\r\n + key_share*\r\n {EncryptedExtensions}\r\n {Finished}\r\n <-------- [Application Data*]\r\n {Finished} -------->\r\n [Application Data] <-------> [Application Data]\r\n \r\n Figure 3: Message Flow for Resumption and PSK\r\n", "correct_text": " Figure 3 shows a pair of handshakes in which the first handshake\r\n establishes a PSK and the second handshake uses it:\r\n \r\n Client Server\r\n \r\n Initial Handshake:\r\n ClientHello\r\n + key_share -------->\r\n ServerHello\r\n + key_share\r\n {EncryptedExtensions}\r\n {CertificateRequest*}\r\n {Certificate*}\r\n {CertificateVerify*}\r\n {Finished}\r\n <-------- [Application Data*]\r\n {Certificate*}\r\n {CertificateVerify*}\r\n {Finished} -------->\r\n <-------- [NewSessionTicket]\r\n [Application Data] <-------> [Application Data]\r\n \r\n \r\n Subsequent Handshake:\r\n ClientHello\r\n + key_share*\r\n + psk_key_exchange_modes \r\n + pre_shared_key -------->\r\n\r\n ServerHello\r\n + pre_shared_key\r\n + key_share*\r\n {EncryptedExtensions}\r\n {Finished}\r\n <-------- [Application Data*]\r\n {Finished} -------->\r\n [Application Data] <-------> [Application Data]\r\n \r\n Figure 3: Message Flow for Resumption and PSK\r\n", "notes": "The pre_shared_key requires the pre_share_key extension.\r\n\r\nThis Issue and PR should address this erratum:\r\nhttps://github.com/tlswg/tls13-spec/issues/1344\r\nhttps://github.com/tlswg/tls13-spec/pull/1345\r\n", "submit_date": "2019-05-03", "submitter_name": "Daniel Migault", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-29 01:17:26" }, { "errata_id": "5736", "doc-id": "RFC7854", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4.2", "orig_text": " 0 1 2 3\r\n 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\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Peer Type | Peer Flags |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Peer Distinguisher (present based on peer type) |\r\n | |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Peer Address (16 bytes) |\r\n ~ ~\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Peer AS |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Peer BGP ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Timestamp (seconds) |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Timestamp (microseconds) |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", "correct_text": " 0 1 2 3\r\n 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\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Peer Type | Peer Flags |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Peer Distinguisher (present based on peer type) |\r\n | |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Peer Address (16 bytes) |\r\n ~ ~\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Peer AS |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Peer BGP ID |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Timestamp (seconds) |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\r\n | Timestamp (microseconds) |\r\n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", "notes": "The OLD figure may be misinterpreted as if there are unused bits between the \"Peer Flags\" and \"Peer Distinguisher\".\r\nWK: This also makes is consistent with other diagrams in this RFC.", "submit_date": "2019-05-23", "submitter_name": "Mohamed Boucadair", "verifier_id": "", "verifier_name": "Warren Kumari (Ops AD)", "update_date": "2019-09-10 16:09:03" }, { "errata_id": "7530", "doc-id": "RFC9110", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "15.5.2.", "orig_text": "The 401 (Unauthorized) status code indicates that the request has not\r\nbeen applied because it lacks valid authentication credentials for\r\nthe target resource.", "correct_text": "The 401 (Unauthorized) status code indicates that the request has not\r\nbeen processed because it lacks valid authentication credentials for\r\nthe target resource.", "notes": "\"applying a request\" is not a standard expression. Usually, requests are \"treated\", \"granted\" or \"processed\".\r\n\r\nThis phrasing was imported in Apache Tomcat; thanks to Mark Thomas for pointing out it came from this RFC.\n --VERIFIER NOTES-- \n A method is applied to a resource to have an effect that results in a response. Any web search on \"method applied\" will show you that it is quite common in standard English. The request has already been processed, at least partially, in order to make a decision that resulted in a 401 error", "submit_date": "2023-05-29", "submitter_name": "Philippe Cloutier", "verifier_id": "", "verifier_name": "RFC Editor", "update_date": "2023-07-07 21:22:25" }, { "errata_id": "5766", "doc-id": "RFC4271", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "9.2", "orig_text": " If, due to the limits on the maximum size of an UPDATE message (see\r\n Section 4), a single route doesn't fit into the message, the BGP\r\n speaker MUST not advertise the route to its peers and MAY choose to\r\n log an error locally.\r\n", "correct_text": " If, due to the limits on the maximum size of an UPDATE message (see\r\n Section 4), a single route doesn't fit into the message, the BGP\r\n speaker MUST NOT advertise the route to its peers and MAY choose to\r\n log an error locally.\r\n", "notes": "The Normative text should be \"MUST NOT\", and not \"MUST not\" -- both words should be capitalized.", "submit_date": "2019-06-28", "submitter_name": "Alvaro Retana", "verifier_id": "", "verifier_name": "Ketan Talaulikar", "update_date": "2025-05-28 12:13:20" }, { "errata_id": "7194", "doc-id": "RFC7854", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "10.8", "orig_text": " Information type values 0 through 32767 MUST be assigned using the\r\n \"Standards Action\" policy, and values 32768 through 65530 using the\r\n \"Specification Required\" policy, defined in [RFC5226]. Values 65531\r\n through 65534 are Experimental, and values 0 and 65535 are Reserved.", "correct_text": " Information type values 0 through 127 MUST be assigned using the\r\n \"Standards Action\" policy, and values 128 through 250 using the\r\n \"Specification Required\" policy, defined in [RFC5226]. Values 251\r\n through 254 are Experimental, and values 0 and 255 are Reserved.", "notes": "In Section 4.9 Peer Down Notification. The \"Reason\" field is defined as one octet, while the IANA consideration section is defining values as 2-octets range. This errata suggests updating the IANA registry, instead of the size of the \"Reason\" field in the Peer Down Notification message to avoid breaking existing implementations that use one-octet reason.\r\n\r\n[WK]: See thread https://mailarchive.ietf.org/arch/msg/grow/s-qcQpAkFVK3beirNYqY4MYfbFw/ for tracking. IANA has confirmed that they can update registries from verified errata.", "submit_date": "2022-10-30", "submitter_name": "Ahmed Elhassany", "verifier_id": "", "verifier_name": "Warren Kumari (Ops AD)", "update_date": "2022-11-03 11:17:40" }, { "errata_id": "5802", "doc-id": "RFC5280", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2.1.12", "orig_text": " id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }\r\n -- TLS WWW server authentication\r\n -- Key usage bits that may be consistent: digitalSignature,\r\n -- keyEncipherment or keyAgreement\r\n\r\n id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }\r\n -- TLS WWW client authentication\r\n -- Key usage bits that may be consistent: digitalSignature\r\n -- and/or keyAgreement", "correct_text": " id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }\r\n -- TLS server authentication\r\n -- Key usage bits that may be consistent: digitalSignature,\r\n -- keyEncipherment or keyAgreement\r\n\r\n id-kp-clientAuth OBJECT IDENTIFIER ::= { id-kp 2 }\r\n -- TLS client authentication\r\n -- Key usage bits that may be consistent: digitalSignature\r\n -- and/or keyAgreement", "notes": "The proposed change removes the WWW part of the description. In practice these object identifiers are used for server and client applications, but not necessarily web applications. In particular:\r\n - openssl verification considers them unconditionally even if the server is not a web server or the client a web client\r\n - There is no object identifier that can be used for protocols like SMTP, IMAP, POP3, LDAP, radius, ...; in practice all these protocols are deployed with the identifiers for WWW\r\n - Standards like common criteria assume that these object identifiers are for generic server and clients [0].\r\n\r\n[0]. https://www.niap-ccevs.org/MMO/PP/-442-/#FCS_TLSC_EXT.1.1", "submit_date": "2019-08-06", "submitter_name": "Nikos Mavrogiannopoulos", "verifier_id": "", "verifier_name": "Deb Cooley", "update_date": "2024-10-29 15:19:26" }, { "errata_id": "5868", "doc-id": "RFC8446", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2.3", "orig_text": " ECDSA algorithms: Indicates a signature algorithm using ECDSA\r\n [ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA]\r\n and FIPS 186-4 [DSS], and the corresponding hash algorithm as\r\n defined in [SHS]. The signature is represented as a DER-encoded\r\n [X690] ECDSA-Sig-Value structure.", "correct_text": " ECDSA algorithms: Indicates a signature algorithm using ECDSA\r\n [ECDSA], the corresponding curve as defined in ANSI X9.62 [ECDSA]\r\n and FIPS 186-4 [DSS], and the corresponding hash algorithm as\r\n defined in [SHS]. The signature is represented as a DER-encoded\r\n [X690] ECDSA-Sig-Value structure as defined in [RFC4492].", "notes": "There is a possibility for confusion as the ECDSA-Sig-Value has two conflicting definitions in authoritative standards. TLS always used the following (see RFC4492):\r\n\r\n ECDSA-Sig-Value ::= SEQUENCE {\r\n r INTEGER,\r\n s INTEGER\r\n }\r\n\r\nbut the publicly accessible SECG SEC1 v2.0 (https://www.secg.org/sec1-v2.pdf) defines it like this:\r\n\r\nECDSA-Sig-Value ::= SEQUENCE {\r\n r INTEGER,\r\n s INTEGER,\r\n a INTEGER OPTIONAL,\r\n y CHOICE { b BOOLEAN, f FieldElement } OPTIONAL\r\n}\r\n\r\nI think using the RFC5480 in the Corrected Text would be cleaner than RFC4492, but the former is not an existing reference, so we would need to update section 12 also.", "submit_date": "2019-10-02", "submitter_name": "Hubert Kario", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-21 03:24:17" }, { "errata_id": "5874", "doc-id": "RFC8446", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "5.1", "orig_text": "...\r\n\r\n Application Data messages contain data that is opaque to TLS.\r\n Application Data messages are always protected. Zero-length\r\n fragments of Application Data MAY be sent, as they are potentially\r\n useful as a traffic analysis countermeasure. Application Data\r\n fragments MAY be split across multiple records or coalesced into a\r\n single record.", "correct_text": "...\r\n\r\n Application Data messages contain data that is opaque to TLS.\r\n Application Data messages are always protected. Zero-length\r\n fragments of Application Data (i.e. those encapsulating an\r\n TLSInnerPlaintext record having a content field of length zero)\r\n MAY be sent, as they are potentially useful as a traffic analysis\r\n countermeasure. Application Data fragments MAY be split across\r\n multiple records or coalesced into a single record.", "notes": "In the interest of clarity, it may be prudent to specify the type of record for\r\nwhich a fragment of length zero is being considered - it cannot be that of the\r\nTLSCiphertext itself, for \"Application Data messages are always protected,\"\r\ntherefore I infer this relates to the TLSInnerPlaintext content field (of\r\nlength \"TLSPlaintext.length\") - i.e. to the TLSPlaintext fragment.\r\n\r\nNote: This comment also applies to previous versions of the TLS specification,\r\nin particular with the introduction of the respective text concerning zero-length\r\nfragments in RFC 5246. In TLS 1.2, this would be the GenericXXCipher content\r\nfield of length \"TLSCompressed.length\" - i.e. to the TLSCompressed fragment.\r\n\r\nNote: The implications of zero-length records must be considered with respect to\r\npotential vectors for denial of service.\r\n\r\nPaul Wouters(AD): Currently discussed at:\r\n\r\nhttps://github.com/tlswg/tls13-spec/issues/1346\r\nhttps://github.com/tlswg/tls13-spec/pull/1347", "submit_date": "2019-10-12", "submitter_name": "Mr Laurie Perrin", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-04-05 12:46:18" }, { "errata_id": "5876", "doc-id": "RFC5280", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.2.1.6", "orig_text": " When the subjectAltName extension contains an iPAddress, the address\r\n MUST be stored in the octet string in \"network byte order\", as\r\n specified in [RFC791]. ", "correct_text": " When the subjectAltName extension contains an IP address, the address\r\n MUST be stored in the iPAddress (an octet string). The address \r\n MUST be stored in the octet string in \"network byte order\", as\r\n specified in [RFC791]. ", "notes": "For email addresses and domain names, this section is very prescriptive:\r\n\r\n When the subjectAltName extension contains an Internet mail address,\r\n the address MUST be stored in the rfc822Name. \r\n...\r\n When the subjectAltName extension contains a domain name system\r\n label, the domain name MUST be stored in the dNSName…\r\n\r\nHowever, for IP addresses, it's possible to interpret the current wording as saying that *if* you happen to choose the iPAddress form for an IP address, then you must represent that as big-endian. I suspect this was a poor choice of wording and the intent was to say that you MUST use the iPAddress form for an IP address.", "submit_date": "2019-10-16", "submitter_name": "David Woodhouse", "verifier_id": "", "verifier_name": "Benjamin Kaduk", "update_date": "2019-10-20 23:44:06" }, { "errata_id": "5976", "doc-id": "RFC8446", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "11", "orig_text": " This document updates an entry in the TLS Certificate Types registry\r\n originally created in [RFC6091] and updated in [RFC8447]. IANA has\r\n updated the entry for value 1 to have the name \"OpenPGP_RESERVED\",\r\n \"Recommended\" value \"N\", and comment \"Used in TLS versions prior\r\n to 1.3.\"\r\n", "correct_text": " This document updates two entries in the TLS Certificate Types registry\r\n originally created in [RFC6091] and updated in [RFC8447]. IANA has\r\n updated the entry for value 1 to have the name \"OpenPGP_RESERVED\",\r\n \"Recommended\" value \"N\", and comment \"Used in TLS versions prior\r\n to 1.3.\" IANA has updated the entry for value 0 to have the name\r\n \"X509\", \"Recommended\" value \"Y\", and comment \"Was X.509 before TLS 1.3\".", "notes": "The protocol description language changed the spelling used for \"X509\", and the registry should be updated to match.", "submit_date": "2020-02-04", "submitter_name": "Rich Salz", "verifier_id": "", "verifier_name": "Benjamin Kaduk", "update_date": "2020-03-07 03:01:36" }, { "errata_id": "6204", "doc-id": "RFC8446", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "E.1", "orig_text": "Implementations MUST NOT combine external PSKs with certificate-based authentication of either the client or the server unless negotiated by some extension.", "correct_text": "Implementations MUST NOT combine external PSKs with certificate-based authentication of either client or the server. Future specifications MAY provide an extension to permit this. ", "notes": "The existing text can be misread as permitting this combination upon negotiation of the \"post_handshake_auth\" extension, which would be incorrect. [1] describes an attack that can occur based on this misinterpretation. The proposed text aims to make clear that a *new* extension is required for this combination. \r\n\r\nPaul Wouters(AD): See https://mailarchive.ietf.org/arch/msg/tls/uDjERicvcTimiecyhiSrYA0H1Sc/\r\n[1] https://link.springer.com/article/10.1007%2Fs11416-020-00352-0", "submit_date": "2020-06-03", "submitter_name": "Chris Wood", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-29 01:13:30" }, { "errata_id": "5938", "doc-id": "RFC5280", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6.1", "orig_text": "The primary goal of path validation is to verify the binding between\r\na subject distinguished name or a subject alternative name and\r\nsubject public key, as represented in the target certificate, based\r\non the public key of the trust anchor. In most cases, the target", "correct_text": " The primary goal of path validation is to verify the binding between\r\n| a subject distinguished name and/or a subject alternative name and\r\n subject public key, as represented in the target certificate, based\r\n on the public key of the trust anchor. In most cases, the target", "notes": "The correction conforms to the first paragraph, Sec. 6, \"Certification \r\npath processing verifies the binding between the subject distinguished\r\nname and/or subject alternative name and subject public key.\" \r\n\r\nIn addition, it is not very clear in RFC 5280, given a certificate with\r\na non-empty subject DN and an SAN extension instance (critical or \r\nnon-critical), which one (the subject DN, the SAN extension, or they \r\nboth) should be bound to the subject public key during path validation.\r\nMore explanations are needed.", "submit_date": "2019-12-15", "submitter_name": "Yuting Chen", "verifier_id": "", "verifier_name": "Deb Cooley", "update_date": "2024-10-29 15:21:21" }, { "errata_id": "5941", "doc-id": "RFC7606", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "7.16", "orig_text": " An UPDATE message with a malformed ATTR_SET attribute SHALL be\r\n handled using the approach of \"treat as withdraw\".\r\n", "correct_text": " An UPDATE message with a malformed ATTR_SET attribute SHALL be\r\n handled using the approach of \"treat-as-withdraw\".\r\n", "notes": "All 20 other instances of \"treat-as-withdraw\" in the document use the hyphenated form.", "submit_date": "2019-12-18", "submitter_name": "Benjamin Kaduk", "verifier_id": "", "verifier_name": "Alvaro Retana", "update_date": "2019-12-18 18:10:56" }, { "errata_id": "5967", "doc-id": "RFC5280", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "4.2.2.1.", "orig_text": "The authority information access extension indicates how to access information and services for the issuer of the certificate in which the extension appears.", "correct_text": "The authority information access extension indicates how to access information and services of the issuer of the certificate in which the extension appears.", "notes": "When you use \"access services for the issuer\" you refer to grandparent node for the certificate in certification path. But actually you mean here the parent node in certification path (the services of the CA that has issued the certificate) and that would be \"services of the issuer\".\n --VERIFIER NOTES-- \n\"the issuer of the certificate in which the extension appears\" is a precise indication of the parent node and does not refer to the grandparent node.", "submit_date": "2020-01-27", "submitter_name": "Maxim", "verifier_id": "", "verifier_name": "Benjamin Kaduk", "update_date": "2020-02-02 05:23:49" }, { "errata_id": "5997", "doc-id": "RFC5280", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.2.1.10", "orig_text": " DNS name restrictions are expressed as host.example.com. Any DNS\r\n name that can be constructed by simply adding zero or more labels to\r\n the left-hand side of the name satisfies the name constraint. For\r\n example, www.host.example.com would satisfy the constraint but\r\n host1.example.com would not.\r\n", "correct_text": " For DNS names, restrictions MUST use the dNSName syntax in\r\n Section 4.2.1.6. Any DNS name that can be constructed by simply\r\n adding zero or more labels to the left-hand side of the name satisfies\r\n the name constraint. For example, if the constraint contains\r\n host.example.com, then www.host.example.com would satisfy the\r\n constraint but host1.example.com would not.", "notes": "Currently, the syntax for a dNSName nameConstraint is left implicit, and thus has resulted in ambiguities in encoding and processing that have resulted in ineroperability issues.\r\n\r\nOne interpretation is that the dNSName nameConstraint must be a valid \"host name\" (as discussed in RFC 8499), which is to say must be a Fully-Qualified Domain Name in the preferred name syntax. This interpretation is supported by Section 4.2.1.6, which explicitly states that for the subjectAltName. As 4.2.1.10 does not define an exception to this (as discussed in Appendix B), the interpretation, along with the existing example, would conclude that this field uses preferred name syntax, and that \"DNS name\" here matches the \"host name\" interpretation from RFC 8499\r\n\r\nA different interpretation is that the dNSName nameConstraint uses the modified syntax similar to the URI nameConstraint. That is, it explicitly permits a leading period to indicate that one or more labels preceding is required in order to satisfy the constraint. This allows subdomains, but does not allow the base domain to match. While the language for the DNS name constraint makes it clear that a host name with no preceding period matches both that host and sub-domains, the existence of a preceding period would constraint it to only subdomains.\r\n\r\nAligning with Section 4.2.1.6 would prohibit the latter interpretation, as the preferred name syntax does not permit leading periods. Alternatively, if the latter interpretation is intended, this section would benefit from making that explicit.\r\n\r\nThis has been a source of interoperability issues, with additional information and discussion captured at:\r\n- https://github.com/golang/go/issues/16347\r\n- https://rt.openssl.org/Ticket/Display.html?id=3562\r\n\r\nWhile \"running code\" has aligned in being permissive with a leading period, implementations have gone and seemingly aligned on a third interpretation:\r\n\r\nThe syntax of a dNSName MUST be as described in Section 4.2.1.6, with the exception that it MAY contain a leading period. Any DNS name that can be constructed by simply adding zero or more labels to the left-hand side of the name, ignoring any leading period, satisfies the name constraint.\r\n\r\nThis seems to support implementations expecting the first interpretation in the certificates they receive, and seeing leading period as an encoding mistake, not an explicit desire for the second interpretation.", "submit_date": "2020-02-27", "submitter_name": "Ryan Sleevi", "verifier_id": "", "verifier_name": "Benjamin Kaduk", "update_date": "2020-03-17 05:13:33" }, { "errata_id": "6256", "doc-id": "RFC4271", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "5.1.3", "orig_text": "3) When sending a message to an external peer X, and the peer is\r\nmultiple IP hops away from the speaker (aka \"multihop EBGP\"):\r\n...\r\n- By default, the BGP speaker SHOULD use the IP address of the interface that the speaker uses in the NEXT_HOP attribute to establish the BGP connection to peer X.", "correct_text": "3) When sending a message to an external peer X, and the peer is\r\nmultiple IP hops away from the speaker (aka \"multihop EBGP\"):\r\n...\r\n- By default, the BGP speaker SHOULD use the IP address of the interface that the speaker uses to establish the BGP connection to peer X in the NEXT_HOP attribute.", "notes": "confusing incorrect word order:\r\nreading the original text, the reader might think that the BGP speaker is using the NEXT_HOP attribute as part of establishing a connection with the peer", "submit_date": "2020-08-12", "submitter_name": "Anton Yushkov", "verifier_id": "", "verifier_name": "Alvaro Retana", "update_date": "2020-08-18 18:00:52" }, { "errata_id": "6120", "doc-id": "RFC8446", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "1", "orig_text": "the underlying transport is a reliable, in-order data stream\r\n\r\n", "correct_text": "the underlying transport layer is a reliable, in-order stream delivery service\r\n\r\nor\r\n\r\nthe underlying transport protocol is a reliable, in-order stream delivery service\r\n\r\nor similar", "notes": "Similar elsewhere\n --VERIFIER NOTES-- \n rejected by WG.", "submit_date": "2020-04-24", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-10-17 18:46:02" }, { "errata_id": "6121", "doc-id": "RFC8446", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "1", "orig_text": "cryptographic modes", "correct_text": "cryptographic algorithms", "notes": "\n --VERIFIER NOTES-- \n rejected by WG", "submit_date": "2020-04-24", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-10-17 18:46:48" }, { "errata_id": "6122", "doc-id": "RFC8446", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "1.2", "orig_text": "The key derivation functions have been redesigned.", "correct_text": "The key derivation function has been redesigned.", "notes": "", "submit_date": "2020-04-24", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-21 03:27:21" }, { "errata_id": "6123", "doc-id": "RFC8446", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2", "orig_text": "The handshake protocol allows peers to negotiate a protocol version, select cryptographic algorithms, optionally authenticate each other, and establish shared secret keying material.", "correct_text": "", "notes": "Only client authentication is optional (albeit, server authentication is implicit for PSK-only key exchange mode)\r\n\r\nPaul Wouters(AD): corrected with the following text:\r\n\r\nThe handshake protocol allows peers to negotiate a protocol version, select cryptographic algorithms, authenticate each other (with client authentication being optional), and establish shared secret keying material.", "submit_date": "2020-04-24", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-29 00:59:40" }, { "errata_id": "6124", "doc-id": "RFC8446", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "2", "orig_text": " In the Key Exchange phase, the client sends the ClientHello \r\n (Section 4.1.2) message, which contains a random nonce \r\n (ClientHello.random); its offered protocol versions; a list of \r\n symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key \r\n shares (in the \"key_share\" (Section 4.2.8) extension), a set of \r\n pre-shared key labels (in the \"pre_shared_key\" (Section 4.2.11) \r\n extension), or both; and potentially additional extensions. ", "correct_text": " In the Key Exchange phase, the client sends the ClientHello \r\n (Section 4.1.2) message, which contains a random nonce \r\n (ClientHello.random); its offered protocol versions; a list of \r\n symmetric cipher/Hash algorithm pairs; either a set of Diffie-Hellman key \r\n shares (in the \"key_share\" (Section 4.2.8) extension), a set of \r\n pre-shared key labels (in the \"pre_shared_key\" (Section 4.2.11) \r\n extension), or both; and potentially additional extensions. \r\n\r\nor\r\n\r\n In the Key Exchange phase, the client sends the ClientHello \r\n (Section 4.1.2) message, which contains a random nonce \r\n (ClientHello.random); its offered protocol versions; a list of \r\n symmetric cipher/Hash algorithm (to be used with HKDF) pairs; either a set of Diffie-Hellman key \r\n shares (in the \"key_share\" (Section 4.2.8) extension), a set of \r\n pre-shared key labels (in the \"pre_shared_key\" (Section 4.2.11) \r\n extension), or both; and potentially additional extensions. ", "notes": "\n --VERIFIER NOTES-- \n rejected by WG", "submit_date": "2020-04-24", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-10-17 18:48:22" }, { "errata_id": "6125", "doc-id": "RFC8446", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "GLOBAL", "orig_text": "PSKs are referred to as out-of-band and external", "correct_text": "Referring to PSKs as either out-of-band xor external would help at least one reader", "notes": " This got incorporated into the bis document, but not exactly as suggested.", "submit_date": "2020-04-24", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-21 03:16:30" }, { "errata_id": "6126", "doc-id": "RFC8446", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "4.1.1", "orig_text": "Note that if the PSK can be used without (EC)DHE, then\r\nnon-overlap in the \"supported_groups\" parameters need not be fatal, \r\nas it is in the non-PSK case discussed in the previous paragraph.", "correct_text": "Note that if the PSK can be used without (EC)DHE, then\r\nnon-overlap in the \"supported_groups\" parameters need not be fatal, \r\nas it is in the non-PSK case discussed in the previous paragraph, \r\nbecause PSK-only key exchange mode does not need supported_groups.", "notes": "If \"the PSK can be used without (EC)DHE\", then PSK-only key exchange mode can be used, which doesn't require supported_groups. This is perhaps worthy of explanation.\n --VERIFIER NOTES-- \n rejected by WG", "submit_date": "2020-04-24", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-10-17 18:49:11" }, { "errata_id": "6127", "doc-id": "RFC8446", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "4.1.2.", "orig_text": "If a \"key_share\" extension was supplied in the HelloRetryRequest,\r\nreplacing the list of shares with a list containing a single\r\nKeyShareEntry from the indicated group.", "correct_text": "If a \"key_share\" extension was supplied in the HelloRetryRequest,\r\nreplacing the list of shares with a list containing a single\r\nKeyShareEntry from the indicated group. Note: A \"key_share\" \r\nextension may not be supplied in a HelloRetryRequest message \r\nwhen a server receives an \"early_data\" (Section 4.2.10).", "notes": "\n --VERIFIER NOTES-- \n rejected by WG", "submit_date": "2020-04-24", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-10-17 18:49:58" }, { "errata_id": "6128", "doc-id": "RFC8446", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "GLOBAL", "orig_text": "terminate and abort are used interchangeable, but this isn't explained until after such use.\r\n\r\nIn Section 6.2, we have: In the rest of this specification, when the phrases \"terminate the connection\" and \"abort the handshake\" are used without a specific alert it means that the implementation SHOULD send the alert indicated by the\r\ndescriptions below. ", "correct_text": "Perhaps explain terminology earlier. At the very least, in Section 6.2, open the above sentence with \"Throughout this specification\"\r\n\r\n", "notes": " This got incorporated into the bis document, but not exactly as suggested.", "submit_date": "2020-04-24", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-21 03:17:06" }, { "errata_id": "6135", "doc-id": "RFC8446", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "Global", "orig_text": "list, series, set, and vector are seemingly used as synonyms. ", "correct_text": "Using list, series, set, xor vector would help at least one reader. \r\n", "notes": "Additionally, consistent usage is desirable, e.g., page 31 uses \"A list of extensions\" whereas \"A set of \r\nextensions\" is used on page 60. Elsewhere inconsistently usage causes confusion, e.g., \r\nPage 48:\r\n\r\n client_shares: A list of offered KeyShareEntry values in descending\r\n order of client preference.\r\n\r\n This vector MAY be empty if the client is requesting a\r\n\r\n(Replace \"vector\" with \"list\", or vice versa.)\r\n\r\nPaul Wouters (AD): This got incorporated into the bis document, but not exactly as suggested.", "submit_date": "2020-04-28", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-21 03:20:06" }, { "errata_id": "6136", "doc-id": "RFC8446", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.1.4", "orig_text": " Upon receipt of a HelloRetryRequest, the client MUST check the\r\n legacy_version, legacy_session_id_echo, cipher_suite, and \r\n legacy_compression_method as specified in Section 4.1.3 ", "correct_text": "", "notes": "Section 4.1.3 defines no checks for legacy_version nor legacy_compression_method\r\n --VERIFIER NOTES-- \r\n It does have the listed fields and values it should contain (to check) in the previous 4.1.3 section.\r\n\r\nThis is being addressed; see https://github.com/tlswg/tls13-spec/pull/1364/files\r\n\r\n", "submit_date": "2020-04-28", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-10-18 18:41:57" }, { "errata_id": "6137", "doc-id": "RFC8446", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "4.2.10", "orig_text": "symmetric cipher suite", "correct_text": "cipher suite", "notes": "\n --VERIFIER NOTES-- \n rejected by WG", "submit_date": "2020-04-28", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-10-17 19:07:04" }, { "errata_id": "6138", "doc-id": "RFC8446", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4.2.10", "orig_text": " For externally \r\n provisioned PSKs, the associated values are those provisioned along \r\n with the key. For PSKs established via a NewSessionTicket message, \r\n the associated values are those which were negotiated in the \r\n connection which established the PSK. \r\n\r\n ...\r\n\r\n For externally established \r\n PSKs, the associated values are those provisioned along with the key.\r\n For PSKs established via a NewSessionTicket message, the associated \r\n values are those negotiated in the connection during which the ticket\r\n was established. ", "correct_text": " For externally \r\n provisioned PSKs, the associated values are those provisioned along \r\n with the key. For PSKs established via a NewSessionTicket message, \r\n the associated values are those which were negotiated in the \r\n connection which established the PSK. ", "notes": "Drop largely verbatim duplicated text\r\n\r\nPaul Wouters (AD): This got incorporated into the bis document, but not exactly as suggested.", "submit_date": "2020-04-28", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-21 03:21:32" }, { "errata_id": "6139", "doc-id": "RFC8446", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.4.2.2.", "orig_text": "As servers MAY require the presence of the \"server_name\" extension, clients\r\nSHOULD send this extension, when applicable.", "correct_text": "As servers MAY require the presence of the \"server_name\" extension, client\r\nSHOULD send this extension.", "notes": "Since it is unclear when it is applicable for a server to send the extension, dropping \"when applicable\"\r\nseems appropriate. Alternatively, giving some extra guidance would be useful.\r\n\r\nPaul Wouters(AD): Resolved with alternative Corrected Text:\r\n\r\nAs servers MAY require the presence of the \"server_name\" extension, clients SHOULD send this extension when the server is identified by name.\r\n", "submit_date": "2020-04-29", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-29 01:11:01" }, { "errata_id": "6140", "doc-id": "RFC8446", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.4.2.2.", "orig_text": "This fallback chain SHOULD NOT use the deprecated SHA-1 hash\r\nalgorithm in general, but MAY do so if the client's advertisement\r\npermits it, and MUST NOT do so otherwise.", "correct_text": "This fullback chain MUST NOT use the deprecated SHA-1 hash,\r\nexcept if advertised by the client, in which case it MAY.", "notes": "The original text is difficult to read, eliminating the unnecessary \"SHOULD NOT\" seems to make it \r\neasier.\r\n\r\nPaul Wouters(SEC AD): accepted with slightly different text, keeping the SHOULD NOT -> MUST NOT change proposed here", "submit_date": "2020-04-29", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-10-17 19:13:51" }, { "errata_id": "6141", "doc-id": "RFC8446", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.4.3", "orig_text": " - The context string", "correct_text": " - The context string (defined below)", "notes": "", "submit_date": "2020-04-29", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-21 03:27:54" }, { "errata_id": "6142", "doc-id": "RFC8446", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.6.1.", "orig_text": "Clients MUST NOT cache tickets for longer than 7 days", "correct_text": "Clients MUST NOT use tickets for longer than 7 days", "notes": "\"MUST NOT cache\" is surely overly zealous and may unnecessarily result in non-compliant implementations", "submit_date": "2020-04-29", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-21 03:24:56" }, { "errata_id": "6143", "doc-id": "RFC8446", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "4.2.7", "orig_text": "As of TLS 1.3, servers are permitted to send the \"supported_groups\"\r\nextension to the client.", "correct_text": "", "notes": "It is unclear whether servers are permitted to send the \"supported_groups\" extension to \r\nthe client without solicitation, i.e., when the client does not first send the extension to the \r\nserver. Clarification would be useful.\n --VERIFIER NOTES-- \n rejected by WG", "submit_date": "2020-04-29", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-10-17 18:58:40" }, { "errata_id": "6144", "doc-id": "RFC8446", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "4.2.8.", "orig_text": "Upon receipt of this extension in a HelloRetryRequest, the client\r\nMUST verify that...the selected_group field does not\r\ncorrespond to a group which was provided in the \"key_share\" extension\r\nin the original ClientHello.", "correct_text": "Upon receipt of this extension in a HelloRetryRequest, the client\r\nMUST verify that...a key share was not offered (in the \"key_share\" \r\nextension in the original ClientHello) for the group in the \r\nselected_group field.", "notes": "The original text requires knowledge of the \"key_share\" extension and is rather hard to read,\r\nthe proposed text should be easier to understand.\n --VERIFIER NOTES-- \n rejected by WG", "submit_date": "2020-04-29", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-10-17 19:17:20" }, { "errata_id": "6145", "doc-id": "RFC8446", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "4.2.10.", "orig_text": "When a PSK is used and early data is allowed for that PSK", "correct_text": "", "notes": "I couldn't find restrictions that forbid early data for a PSK. Explaining where such restrictions\r\ncould exist would be useful. E.g., PSKs might be associated with data that forbids early data.\n --VERIFIER NOTES-- \n rejected by WG", "submit_date": "2020-04-29", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-10-17 18:59:57" }, { "errata_id": "6146", "doc-id": "RFC8446", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2.10.", "orig_text": "The TLS version number", "correct_text": "The selected TLS version number", "notes": "", "submit_date": "2020-04-29", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-21 03:26:21" }, { "errata_id": "6147", "doc-id": "RFC8446", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4.2.10.", "orig_text": "In order to accept early data, the server MUST have accepted a PSK\r\ncipher suite....In addition, it MUST verify that the\r\nfollowing values are the same as those associated with the\r\nselected PSK:\r\n\r\n...\r\n\r\n- The selected cipher suite", "correct_text": "", "notes": "Accepting the \"PSK cipher suite\" surely implies the PSK is associated with the cipher suite, hence, \r\n\"The selected cipher suite\" can be dropped.\r\n\r\nPaul Wouters(SEC AD): The text was changed a little to solve this issue", "submit_date": "2020-04-29", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-10-17 19:19:36" }, { "errata_id": "6148", "doc-id": "RFC8446", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "4.2.10", "orig_text": "The selected ALPN [RFC7301] protocol, if any", "correct_text": "The selected ALPN [RFC7301] protocol, if extension application_layer_protocol_negotiation is present", "notes": "\n --VERIFIER NOTES-- \n rejected by WG", "submit_date": "2020-04-29", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-10-17 19:21:40" }, { "errata_id": "6150", "doc-id": "RFC8446", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "GLOBAL", "orig_text": "Note that certificate-based client authentication is not available \r\nin PSK handshake flows (including 0-RTT). ", "correct_text": "Note that certificate-based client authentication is not available \r\nin PSK handshake flows (including 0-RTT), post-handshake \r\ncertificate-based client authentication is possible.", "notes": "\n --VERIFIER NOTES-- \n rejected by WG", "submit_date": "2020-04-29", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-10-17 19:23:09" }, { "errata_id": "6151", "doc-id": "RFC8446", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.4", "orig_text": " | Post- | ClientHello ... client | client_application_traffic_ |\r\n | Handshake | Finished + | secret_N |\r\n | | CertificateRequest | |", "correct_text": " | Post- | ClientHello ... client | [sender]_application_traffic|\r\n | Handshake | Finished + | _secret_N |\r\n | | CertificateRequest | |", "notes": "", "submit_date": "2020-04-30", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-10-17 18:37:19" }, { "errata_id": "6152", "doc-id": "RFC8446", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "4", "orig_text": "Clients MUST check for [\"supported_versions\"] prior to\r\nprocessing the rest of the ServerHello (although they will have to \r\nparse the ServerHello in order to read the extension). -- Section 4.2.1.\r\n\r\nUpon receipt of a HelloRetryRequest, the client MUST check the\r\nlegacy_version, legacy_session_id_echo, cipher_suite, and\r\nlegacy_compression_method as specified in Section 4.1.3 and then\r\nprocess the extensions, starting with determining the version using\r\n\"supported_versions\". -- Section 4.1.4\r\n\r\nUpon receiving a message with type server_hello, implementations MUST\r\nfirst examine the Random value... -- Section 4.1.3.\r\n", "correct_text": "", "notes": "These requirements are seemingly conflicting. I suspect checking for \"supported_versions\" must \r\ncome first, since that may influence subsequent steps, e.g., checking legacy_compression_method \r\nand the Random value. It doesn't seem to matter whether legacy_version, legacy_session_id_echo, \r\ncipher_suite, and legacy_compression_method are checked before the Random value, so it doesn't\r\nseem to matter which check is second and which is third. (Noting, as per one of my earlier reports,\r\ndated 28 Apr, Section 4.1.3 defines no checks for legacy_version nor legacy_compression_method. \r\nPerhaps the latter should be checked to be zero, aborting with alert illegal_parameter if it isn't, as per\r\nSection 4.1.2.)\n --VERIFIER NOTES-- \n rejected by WG", "submit_date": "2020-05-01", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-10-17 19:06:00" }, { "errata_id": "6205", "doc-id": "RFC8446", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "4.3.2", "orig_text": " Servers which are authenticating with a PSK MUST NOT send the\r\n CertificateRequest message in the main handshake, though they MAY\r\n send it in post-handshake authentication (see Section 4.6.2) provided\r\n that the client has sent the \"post_handshake_auth\" extension (see\r\n Section 4.2.6).", "correct_text": " Servers which are authenticating with a resumption PSK MUST NOT send the\r\n CertificateRequest message in the main handshake, though they MAY\r\n send it in post-handshake authentication (see Section 4.6.2) provided\r\n that the client has sent the \"post_handshake_auth\" extension (see\r\n Section 4.2.6). Servers which are authenticating with an external PSK\r\n MUST NOT send the CertificateRequest message either in the main handshake\r\n or request post-handshake authentication. Future specifications MAY\r\n provide an extension to permit this. ", "notes": "The lack of qualification on \"authenticating with a PSK\" implies that the statement applies equally to both external and resumption PSKs. However, there are two conditions being governed: whether a certificate can be requested during the handshake, and whether a certificate can be requested post-handshake. The latter of these requires different rules depending on the type of PSK.\r\n\r\nWe know from the analysis of resumption (see https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/) that combining a PSK handshake of either type with a client certificate is not safe. Thus, the prohibition on CertificateRequest during the handshake applies equally to both resumption and external PSKs.\r\n\r\nFor post-handshake, Appendix E.1 already discusses the risks of combining PSKs with certificates, citing the same analysis as above.\r\n\r\n [...] It is unsafe to use certificate-based client\r\n authentication when the client might potentially share the same\r\n PSK/key-id pair with two different endpoints.\r\n\r\nFor this reason an external PSK is not safe to use with post-handshake authentication. A resumption PSK does not have this property, so the same prohibition doesn't apply.\r\n\r\nSplitting the requirements as proposed makes this split clearer.", "submit_date": "2020-06-04", "submitter_name": "Martin Thomson", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-01-17 00:59:14" }, { "errata_id": "6208", "doc-id": "RFC8259", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "8.1", "orig_text": "In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark rather than treating it as an error.", "correct_text": "In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark or MAY interpret a byte order mark to indicate an alternate encoding rather than treating it as an error.", "notes": "The original line is copied from previous RFCs that specifically allowed alternate encodings. In the context of a new, UTF-8 only restriction, interoperability provisions should also address interpreting legacy formats that predate the restriction. By omission, readers may conclude that the *only* option for a BOM is to ignore or error.\n --VERIFIER NOTES-- \n This is asking to revisit what we have consensus on, not a report of an error in the RFC.\r\nThe working group had extensive discussions on BOMs, and chose this particular working purposefully.", "submit_date": "2020-06-10", "submitter_name": "David Golden", "verifier_id": "", "verifier_name": "Barry Leiba", "update_date": "2020-06-10 14:38:37" }, { "errata_id": "6325", "doc-id": "RFC6125", "errata_status_code": "Reported", "errata_type_code": "Editorial", "section": "10.2", "orig_text": " [X.520] International Telecommunications Union, \"Information\r\n Technology - Open Systems Interconnection - The\r\n Directory: Selected attribute types\", ITU-\r\n T Recommendation X.509, ISO Standard 9594-6,\r\n August 2005.\r\n", "correct_text": " [X.520] International Telecommunications Union, \"Information\r\n Technology - Open Systems Interconnection - The\r\n Directory: Selected attribute types\", ITU-\r\n T Recommendation X.520, ISO Standard 9594-6,\r\n August 2005.\r\n", "notes": "Selected attribute types is X.520 not X.509", "submit_date": "2020-11-06", "submitter_name": "tom petch", "verifier_id": "", "verifier_name": null, "update_date": null }, { "errata_id": "6244", "doc-id": "RFC5246", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "6.2.3.2", "orig_text": "IV\r\nThe Initialization Vector (IV) SHOULD be chosen at random, and\r\nMUST be unpredictable. Note that in versions of TLS prior to 1.1,\r\nthere was no IV field, and the last ciphertext block of the\r\nprevious record (the \"CBC residue\") was used as the IV. This was\r\nchanged to prevent the attacks described in [CBCATT]. For block\r\nciphers, the IV length is of length\r\nSecurityParameters.record_iv_length, which is equal to the\r\nSecurityParameters.block_size.", "correct_text": "IV\r\nThe Initialization Vector (IV) SHOULD be chosen at random, and\r\nMUST be unpredictable. Note that in versions of TLS prior to 1.1,\r\nthere was no IV field, and the last ciphertext block of the\r\nprevious record (the \"CBC residue\") was used as the IV. This was\r\nchanged to prevent the attacks described in [CBCATT]. For block\r\nciphers, the IV length is of length\r\nSecurityParameters.record_iv_length, which is equal to the\r\nSecurityParameters.block_length.", "notes": "This is an error here. The structure SecurityParameters hasn't the element block_size.\r\nIt has the element block_length.\r\nSee in section 6.1:\r\nstruct {\r\nConnectionEnd entity;\r\nPRFAlgorithm prf_algorithm;\r\nBulkCipherAlgorithm bulk_cipher_algorithm;\r\nCipherType cipher_type;\r\nuint8 enc_key_length;\r\nuint8 block_length;\r\nuint8 fixed_iv_length;\r\nuint8 record_iv_length;\r\nMACAlgorithm mac_algorithm;\r\nuint8 mac_length;\r\nuint8 mac_key_length;\r\nCompressionMethod compression_algorithm;\r\nopaque master_secret[48];\r\nopaque client_random[32];\r\nopaque server_random[32];\r\n} SecurityParameters;\r\n\r\n\r\nPaul Wouters (AD): Note this RFC is obsoleted and all of this text already got removed", "submit_date": "2020-07-29", "submitter_name": "Victor S. Osipov", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-21 03:51:31" }, { "errata_id": "7303", "doc-id": "RFC8446", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "6.1", "orig_text": "This alert notifies the recipient that the sender will not send any more messages on this connection. ", "correct_text": "This alert notifies the recipient that the sender will not send any more messages on this connection. close_notify alerts should be sent with a severity level of WARNING.", "notes": "Apparently, TLS/1.0 specified these should be set to WARNING, not FATAL, but this text got lost somewhere along the way. https://github.com/pion/dtls/issues/195\r\n\r\nOpenSSL/NSS both send as WARNING, and servers that have tried sending as FATAL have encountered compatibility problems with clients which treat FATAL alerts differently than WARNING alerts: e.g. https://source.chromium.org/chromium/chromium/src/+/main:third_party/boringssl/src/ssl/tls_record.cc;l=591;drc=c0872c02015009bf3dbab0a83c0452d141e8e9cf?q=tls_open_record&ss=chromium%2Fchromium%2Fsrc\r\n\r\nPaul Wouters(AD): Resolved but with the following Corrected Text:\r\n\r\nclose_notify: This alert notifies the recipient that the sender will not send any more messages on this connection. Any data received after a closure alert has been received MUST be ignored. This alert MUST be sent with AlertLevel=warning.", "submit_date": "2023-01-12", "submitter_name": "Eric Lawrence", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-29 01:04:34" }, { "errata_id": "6401", "doc-id": "RFC8446", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.6.2", "orig_text": "When the client has sent the \"post_handshake_auth\" extension (see\r\nSection 4.2.6), a server MAY request client authentication at any\r\ntime after the handshake has completed by sending a\r\nCertificateRequest message. ", "correct_text": "When the client has sent the \"post_handshake_auth\" extension (see\r\nSection 4.2.6), a server MAY request client authentication during the \r\nmain handshake and/or at any time after the handshake has completed by \r\nsending a CertificateRequest message. \r\n\r\n", "notes": "4.6.2 is ambiguous as to whether it forbids \"main handshake\" (mid-handshake) client \r\nauthentication when the client has sent the \"post_handshake_auth\" extension. I think \r\nthe language would be stronger if it were really forbidden, and openssl s_server permits \r\nthis behavior and rfc8740 implies it as well.\r\n\r\nThe \"main handshake\" language is adopted from 4.3.2 but \"main\" could be dropped as \r\n\"handshake\" is not ambiguous in 1.3 due to no renegotiation.", "submit_date": "2021-01-20", "submitter_name": "Eric Covener", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-29 00:54:39" }, { "errata_id": "6414", "doc-id": "RFC5280", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.2.1.12", "orig_text": " id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }\r\n -- TLS WWW server authentication\r\n -- Key usage bits that may be consistent: digitalSignature,\r\n -- keyEncipherment or keyAgreement", "correct_text": " id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 }\r\n -- TLS WWW server authentication\r\n -- Key usage bits that may be consistent: digitalSignature\r\n -- and/or (keyEncipherment or keyAgreement)", "notes": "In https://github.com/zmap/zlint/issues/553 there's been some disagreement and confusion about how to correctly interpret the \"or\" in the Original Text. \"You can only set one of these three bits\" is one interpretation, and it's hard to argue that this interpretation is inconsistent with the Original Text.\r\n\r\nHowever, digitalSignature+keyEncipherment makes sense for an RSA leaf certificate, and digitalSignature+keyAgreement makes sense for an ECC leaf certificate. Both are widely used, to enable ephemeral and non-ephemeral TLS ciphersuites in conjunction with a single server certificate.\r\n\r\nGiven that RFC5480 section 3 explicitly permits digitalSignature+keyAgreement in an ECC leaf certificate, I think it's likely that my proposed Corrected Text conveys the RFC5280 authors' intended meaning.", "submit_date": "2021-01-28", "submitter_name": "Rob Stradling", "verifier_id": "", "verifier_name": "Deb Cooley", "update_date": "2024-10-29 15:27:06" }, { "errata_id": "6498", "doc-id": "RFC4271", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "5.1.5", "orig_text": "LOCAL_PREF is a well-known attribute that SHALL be included in all UPDATE messages that a given BGP speaker sends to other internal peers. ", "correct_text": "LOCAL_PREF is a well-known discretionary attribute that SHALL be included in all UPDATE messages that a given BGP speaker sends to other internal peers. ", "notes": "It is unclear from the text to which of the four path attribute categories LOCAL_PREF belongs. There was even submitted an errata to create a fifth category for this attribute, but it is clear from the definition of the categories, that this attribute is well known discretionary. All routers must be capable of sending or receiving the LOCAL_PREF attribute, however it is up to a routers discretion whether to include that attribute in an UPDATE message.\r\n\r\n=====\r\n[Verifier notes.]\r\n\r\nThis is a valid report. The terminology in rfc4271 is not ideal, so using \"discretionary\" with a required action can cause significant confusion, even if that is the correct term for this attribute. A future version of this RFC should consider updating/cleaning up the terminology.\r\n", "submit_date": "2021-03-27", "submitter_name": "Graham Paasch", "verifier_id": "", "verifier_name": "Alvaro Retana", "update_date": "2021-03-29 17:30:14" }, { "errata_id": "6572", "doc-id": "RFC5246", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "9", "orig_text": "In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition).", "correct_text": "In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_GCM_SHA256 (see Appendix A.5 for the definition).", "notes": "A must-be-implement cipher suite should not relay on a bulk encryption algorithm which is vulnerable to plain-text attacks or on a secure hash algorithm which has been proven to be insecure.\n --VERIFIER NOTES-- \nerrata is not the right process for a change such as proposed.\r\nSee also: https://mailarchive.ietf.org/arch/msg/tls/2mKIkvRoQNMEMkT04JAqBifEJSo/", "submit_date": "2021-05-05", "submitter_name": "Johannes Görlich", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-21 03:47:23" }, { "errata_id": "7306", "doc-id": "RFC9110", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "14.1.1", "orig_text": " ranges-specifier = range-unit \"=\" range-set\r\n range-set = 1#range-spec\r\n range-spec = int-range\r\n / suffix-range\r\n / other-range", "correct_text": " ranges-specifier = range-unit \"=\" OWS range-set\r\n range-set = 1#range-spec\r\n range-spec = int-range\r\n / suffix-range\r\n / other-range", "notes": "The ABNF is inconsistent with one of the examples given in 14.1.2\r\n\r\n bytes= 0-999, 4500-5499, -1000\r\n\r\nThe bug in the ABNF was likely introduced when converting away from \"implied linear whitespace\".\r\n\r\nSee also .", "submit_date": "2023-01-13", "submitter_name": "Julian Reschke", "verifier_id": "", "verifier_name": "Francesca Palombini", "update_date": "2023-10-23 09:45:18" }, { "errata_id": "7307", "doc-id": "RFC8259", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "3", "orig_text": " null = %x6e.75.6c.6c ; null ", "correct_text": " null = %x6e.75.6c.6c ; null without quotation marks for numeric attributes and \"null\" for string attributes.", "notes": "It is not clear how to encode null values in JSON.\r\nSome are encoding all attributes as \"null\".\r\nSome are encoding all attributes as null without quotation marks\r\nSome are encoding string attributes as \"null\" and numeric attributes as null without quotation marks.\r\nhttps://json.org is mentioning \"null\". ECMA 262 is mentioning \"null\" for string and +0F for numeric attributes. However providing zero for a number instead of null is incorrect and provides wrong results (in BI).\n --VERIFIER NOTES-- \nThe original specification is clear as such, and this errata would make a change that breaks the format, and is against the original intent of the text.", "submit_date": "2023-01-13", "submitter_name": "Maxim Iurie", "verifier_id": "", "verifier_name": "Francesca Palombini", "update_date": "2023-01-18 09:39:22" }, { "errata_id": "6773", "doc-id": "RFC2119", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "5", "orig_text": "MAY This word, or the adjective \"OPTIONAL\", mean that an item is\r\n truly optional. One vendor may choose to include the item because a\r\n particular marketplace requires it or because the vendor feels that\r\n it enhances the product while another vendor may omit the same item.", "correct_text": "MAY This word, or the adjective \"OPTIONAL\", mean that an item is\r\n truly optional. One vendor may choose to include the item because a\r\n particular marketplace requires it or because the vendor feels that\r\n it enhances the product while another vendor may omit the same item.", "notes": "There is a double space before \"One vendor may choose to include\".\n --VERIFIER NOTES-- \nThis report doesn't add clarity or improve readabilty. We don't recommend errata be used to \"correct\" the number of spaces between sentences.", "submit_date": "2021-12-03", "submitter_name": "Michał Bieńkowski", "verifier_id": "", "verifier_name": "RFC Editor", "update_date": "2022-01-28 05:52:08" }, { "errata_id": "6820", "doc-id": "RFC8446", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "6.2", "orig_text": "unsupported_extension: Sent by endpoints receiving any handshake\r\n message containing an extension known to be prohibited for\r\n inclusion in the given handshake message, or including any\r\n extensions in a ServerHello or Certificate not first offered in\r\n the corresponding ClientHello or CertificateRequest. ", "correct_text": "unsupported_extension: Sent by endpoints receiving any handshake\r\n message containing an extension in a ServerHello or Certificate\r\n not first offered in the corresponding ClientHello or \r\n CertificateRequest.", "notes": "The definition of the unsupported_extension alert in section 6.2 contradicts the statements in section 4.2:\r\n\r\n If an implementation receives an extension\r\n which it recognizes and which is not specified for the message in\r\n which it appears, it MUST abort the handshake with an\r\n \"illegal_parameter\" alert.\r\n\r\nWhile this might not be inconsistent due to the \"abort the handshake with an X alert\" specification at the beginning of section 6.2, it might lead to confusion. (see https://mailarchive.ietf.org/arch/msg/tls/hGOGWZRMg718mWqOZ06LwjV9360/).\r\n\r\nPaul Wouters(AD): Currently discussed at:\r\n\r\nhttps://github.com/tlswg/tls13-spec/issues/1352\r\nhttps://github.com/tlswg/tls13-spec/pull/1353", "submit_date": "2022-01-21", "submitter_name": "Leander Schwarz", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-04-05 12:47:15" }, { "errata_id": "6830", "doc-id": "RFC5280", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "Appendix A.1", "orig_text": "-- Note - upper bounds on string types, such as TeletexString, are\r\n-- measured in characters. Excepting PrintableString or IA5String, a\r\n-- significantly greater number of octets will be required to hold\r\n-- such a value. As a minimum, 16 octets, or twice the specified\r\n-- upper bound, whichever is the larger, should be allowed for\r\n-- TeletexString. For UTF8String or UniversalString at least four\r\n-- times the upper bound should be allowed.", "correct_text": "-- Note - upper bounds on string types, such as TeletexString, are\r\n-- measured in characters. Excepting PrintableString or IA5String, a\r\n-- significantly greater number of octets will be required to hold\r\n-- such a value. As a minimum, 16 octets, or twice the specified\r\n-- upper bound, whichever is the larger, should be allowed for\r\n-- TeletexString. For UTF8String or UniversalString, four\r\n-- times the upper bound should be allowed.", "notes": "\"at least four times\" is likely a holdover from RFC 3280, as the same text exists in that RFC. In RFC 3280, the definition of UTF-8 in UTF8String was normatively referencing RFC 2279, which allowed for a maximum of 6 octets to represent a single Unicode character in UTF-8. However, RFC 5280 was updated to normatively reference RFC 3629, which restricts the allowed set of characters in a UTF-8 string to match those allowed in UTF-16 (i.e., the BMP and 16 supplementary planes as opposed to all 32k planes). As a result, the maximum length for a single RFC 3629 UTF-8 character is 4 octets, rendering the guidance of \"at least four times\" wholly unnecessary; \"four times\" is sufficient in all cases.\n --VERIFIER NOTES-- \n Verifier Notes: 'At least four times' includes 'four times'.", "submit_date": "2022-02-02", "submitter_name": "Corey Bonnell", "verifier_id": "", "verifier_name": "Deb Cooley", "update_date": "2024-10-29 15:31:51" }, { "errata_id": "6850", "doc-id": "RFC4254", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "5.1", "orig_text": "Requests for assignments of new SSH_MSG_CHANNEL_OPEN 'reason code'\r\nvalues (and associated 'description' text) in the range of 0x00000005\r\nto 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as\r\ndescribed in [RFC2434]. The IANA will not assign Channel Connection\r\nFailure 'reason code' values in the range of 0xFE000000 to\r\n0xFFFFFFFF. Channel Connection Failure 'reason code' values in that\r\nrange are left for PRIVATE USE, as described in [RFC2434].\r\n\r\n", "correct_text": "Requests for assignments of new SSH_MSG_CHANNEL_OPEN_FAILURE 'reason code'\r\nvalues (and associated 'description' text) in the range of 0x00000005\r\nto 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as\r\ndescribed in [RFC2434]. The IANA will not assign Channel Connection\r\nFailure 'reason code' values in the range of 0xFE000000 to\r\n0xFFFFFFFF. Channel Connection Failure 'reason code' values in that\r\nrange are left for PRIVATE USE, as described in [RFC2434].\r\n", "notes": "The 'reason code' is present on SSH_MSG_CHANNEL_OPEN_FAILURE message to denote cause of the failure while original text attributes it to SSH_MSG_CHANNEL_OPEN by mistake.", "submit_date": "2022-02-14", "submitter_name": "Hamid Nazari", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2023-07-28 18:03:49" }, { "errata_id": "6878", "doc-id": "RFC8174", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "GLOBAL", "orig_text": "http://www.rfc-editor.org/info/rfc8174\r\nhttp://trustee.ietf.org/license-info\r\nhttp://www.rfc-editor.org/info/rfc2119\r\nhttp://internetmessagingtechnology.org", "correct_text": "https://www.rfc-editor.org/info/rfc8174\r\nhttps://trustee.ietf.org/documents/trust-legal-provisions\r\nhttps://www.rfc-editor.org/info/rfc2119\r\nhttps://internetmessagingtechnology.org", "notes": "The URLs should be using HTTPS instead of HTTP and should be updated.\n --VERIFIER NOTES-- \nThis is how the URLs were presented when the RFC was published. ", "submit_date": "2022-03-10", "submitter_name": "Boris", "verifier_id": "", "verifier_name": "RFC Editor", "update_date": "2022-04-05 22:52:13" }, { "errata_id": "8849", "doc-id": "RFC2119", "errata_status_code": "Reported", "errata_type_code": "Technical", "section": "abstract", "orig_text": "3. SHOULD This word, or the adjective \"RECOMMENDED\", mean that there\r\n may exist valid reasons in particular circumstances to ignore a\r\n particular item, but the full implications must be understood and\r\n carefully weighed before choosing a different course.", "correct_text": "3. SHOULD This word, or the adjective \"RECOMMENDED\", means that there\r\n exist valid reasons in particular circumstances to ignore a\r\n particular item, but that this reason and the full implications of \r\n ignoring it must be understood and carefully weighed before doing so.", "notes": "When \"may exist\" was used, the authors often acted as if there wwas no obligation to identify and make clear these reasons. \r\n\r\nAs a result, SHOULD is often used incorrectly when such reasons cannot be clearly idetiied.\r\n\r\nAlthough I would prefer a bigger change requiring the author to make the reasons clear, that could only be done in bis-type revision. This is the best that can be done with a purely editorial change.", "submit_date": "2026-03-21", "submitter_name": "David Noveck", "verifier_id": "", "verifier_name": null, "update_date": "2026-03-31 19:42:56" }, { "errata_id": "6954", "doc-id": "RFC2119", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "6. of all scripts", "orig_text": "6. Guidance in the use of these Imperatives\r\n\r\n Imperatives of the type defined in this memo must be used with care\r\n and sparingly. In particular, they MUST only be used where it is\r\n actually required for interoperation or to limit behavior which has\r\n potential for causing harm (e.g., limiting retransmisssions) For\r\n example, they must not be used to try to impose a particular method\r\n on implementors where the method is not required for\r\n interoperability.\r\n\r\n{This part: (e.g., limiting retransmisssions); is the focus.}", "correct_text": "In-line html has an errata by Davidson, Malcolm about the extra S in retransmission. (Good Job to Malcom! (I would also like to make editors aware that is in only corrected in the, in-line html. The error of the extra -s in the word retransmissions is still present in all of the other documents.) \r\n\r\nThe problem I would like to bring to the attention of the minds of the world, is \r\nstill that same word, retransmissions and I'm concerned that it has been looked at and still over looked. It should be simply \"transmissions\" or, but NOT RECOMENDED; \"re-transmissions\". (I will explain.) ", "notes": "The base word \"transmission\" (which is already a compound word.) in the plural form, shows more than one, present tense, and also future tense. Therefore the re- prefix is redundant in the word. It actually retards the word making it null. Without the hyphen it is an entirely different compound word that may not even exist yet. The -s making it plural is plenty to make this sentence complete and accurate. There is no need for the re- prefix but if you must it should be hyphenated. Thank you!\n --VERIFIER NOTES-- \nThe word in question (retransmissions) is used as an example, and is a term of art in congestion control.", "submit_date": "2022-05-05", "submitter_name": "aaron wuescher", "verifier_id": "", "verifier_name": "Lars Eggert", "update_date": "2023-08-11 11:07:37" }, { "errata_id": "7003", "doc-id": "RFC8446", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.6.1.", "orig_text": "At any time after the server has received the client Finished message, it MAY send a NewSessionTicket message.", "correct_text": "At any time after the server has received both a \"psk_key_exchange_modes\" extension and a Finished message, it MAY send a NewSessionTicket message.\r\n\r\n", "notes": "Section 4.2.9. demands \r\n\r\nIn order to use PSKs, clients MUST also send a \"psk_key_exchange_modes\" extension.\r\n\r\nHence, an additional restriction is needed in Section 4.6.1.", "submit_date": "2022-06-22", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-10-17 18:38:47" }, { "errata_id": "7383", "doc-id": "RFC8259", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "3. Values", "orig_text": "false = %x66.61.6c.73.65 ; false\r\n\r\n null = %x6e.75.6c.6c ; null", "correct_text": "false = %x66.61.6C.73.65 ; false\r\n\r\n null = %x6E.75.6C.6C ; null", "notes": "Hex values should be capitalized https://www.rfc-editor.org/rfc/rfc5234#appendix-B.1", "submit_date": "2023-03-12", "submitter_name": "Daniel Tegründe", "verifier_id": "", "verifier_name": "Andy Newton", "update_date": "2026-05-28 18:35:23" }, { "errata_id": "7250", "doc-id": "RFC8446", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.6.1", "orig_text": " The client MAY use this PSK for future handshakes by including the\r\n ticket value in the \"pre_shared_key\" extension in its ClientHello\r\n (Section 4.2.11).", "correct_text": "(to add)\r\n\r\n Where the client does not support session tickets, this extension MUST be ignored.", "notes": "I've seen a TLS implementation which doesn't implement session tickets. That's fine, but the implementation doesn't *ignore* session tickets it receives. Instead, it treats reception of the ticket as un recoverable error, and drops the TLS connection.\r\n\r\nIt's also worth adding a note to section 4.2 at the bottom of page 38. To note that in general, f an extension isn't supported AND doesn't materially affect the TLS exchange, THEN it should be ignored.\r\n\r\ni.e. there's nothing in the spec which mentions Postel's law \"be conservative in what you send, be liberal in what you accept\". So implementors reading this document are free to do all kinds of odd things.\r\n\r\nIn addition, the text in Section 4.2 at the bottom of page 38 says:\r\n\r\n\"\r\n Designers\r\n and implementors should be aware of the fact that until the\r\n handshake has been authenticated, active attackers can modify\r\n messages and insert, remove, or replace extensions.\r\n\"\r\n\r\nThe implicit conclusion here is that an implementation receiving extensions must sanity check them. e.g. an attacker adding an undefined / unknown extension should not cause the entire session to be torn down.\r\n\r\nPaul Wouters(AD): Resolved but with the Corrected Text:\r\n\r\nThe client MAY use this PSK for future handshakes by including the ticket value in the \"pre_shared_key\" extension in its ClientHello (Section 4.2.11). Clients which receive a NewSessionTicket message but do not support resumption MUST silently ignore this message.", "submit_date": "2022-11-14", "submitter_name": "Alan DeKok", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-03-29 01:06:50" }, { "errata_id": "7419", "doc-id": "RFC9110", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "8.3.2", "orig_text": " In the fields defined by this document, charset names appear either\r\n in parameters (Content-Type), or, for Accept-Encoding, in the form of\r\n a plain token.", "correct_text": " In the fields defined by this document, charset names appear either\r\n in parameters (Content-Type), or, for Accept-Charset, in the form of\r\n a plain token.", "notes": "Accept-Encoding is the preferred list of response content codings. Accept-Charset is the preferred list of response charsets.", "submit_date": "2023-04-11", "submitter_name": "Dave Shawley", "verifier_id": "", "verifier_name": "Francesca Palombini", "update_date": "2023-10-23 09:42:33" }, { "errata_id": "7599", "doc-id": "RFC9110", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "6.4.1", "orig_text": "All 1xx (Informational), 204 (No Content), and 304 (Not Modified)\r\nresponses do not include content.\r\n\r\nAll other responses do include content, although that content might\r\nbe of zero length.", "correct_text": "All 1xx (Informational), 204 (No Content), 205 (Reset Content), \r\nand 304 (Not Modified) responses do not include content.\r\n\r\nAll other responses do include content, although that content might\r\nbe of zero length.", "notes": "Per section 15.3.6 (205 No Content), it says that servers MUST NOT generate a response. Section 6.4.1 says that \"All 1xx, 204, and 304 response don't include content and others do.\" even though 205 response mustn't generate content.\n --VERIFIER NOTES-- \nIn rejecting this Errata report I note that the reported text is not an error, but a deliberate decision of the authors and working group.", "submit_date": "2023-08-11", "submitter_name": "Justine Krejcha", "verifier_id": "", "verifier_name": "Francesca Palombini", "update_date": "2023-10-23 09:39:12" }, { "errata_id": "7620", "doc-id": "RFC8446", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "6.1", "orig_text": "Each party MUST send a \"close_notify\" alert before closing its write\r\nside of the connection, unless it has already sent some error alert.\r\nThis does not have any effect on its read side of the connection.\r\nNote that this is a change from versions of TLS prior to TLS 1.3 in\r\nwhich implementations were required to react to a \"close_notify\" by\r\ndiscarding pending writes and sending an immediate \"close_notify\"\r\nalert of their own. That previous requirement could cause truncation\r\nin the read side. Both parties need not wait to receive a\r\n\"close_notify\" alert before closing their read side of the\r\nconnection, though doing so would introduce the possibility of\r\ntruncation.", "correct_text": "Each party MUST send a \"close_notify\" alert before closing its write\r\nside of the connection, unless it has already sent some error alert.\r\nThis SHOULD NOT have any effect on the read side of the sender's connection;\r\nparties SHOULD receive a \"close_notify\" alert before closing the read side of their connection.\r\nNote that this is a change from versions of TLS prior to TLS 1.3 in\r\nwhich receivers were required to react to a \"close_notify\" by\r\ndiscarding pending writes and sending an immediate \"close_notify\"\r\nalert of their own. That previous requirement could cause truncation\r\nin the read side. Both parties need not wait to receive a\r\n\"close_notify\" alert before closing their read side of the\r\nconnection, though doing so would introduce the possibility of\r\ntruncation.", "notes": "As-is there's a specification-level vulnerability: Specification-compliant implementations may be vulnerable to truncation attacks.\r\n\r\nI suggest using SHOULD NOT & SHOULD for better signposting and to avoid specification-level vulnerability.\r\n\r\nI also suggest minor tweaks for readability.\n --VERIFIER NOTES-- \n Rejected by WG. See https://github.com/tlswg/tls13-spec/pull/1357/commits/d2a36a8029067cb20ff431fcaa8b3a4e537e4bf6", "submit_date": "2023-08-28", "submitter_name": "Ben Smyth", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-10-17 18:54:03" }, { "errata_id": "7658", "doc-id": "RFC5280", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "7.1", "orig_text": "The hyperlink to \"Section 2.6.1\" of RFC 4158 in this text is incorrect:\r\n\r\n * In step 6, Insignificant Character Removal, perform white space\r\n compression as specified in Section 2.6.1, Insignificant Space\r\n Handling, of [RFC4518].\r\n\r\nIt currently points to https://www.rfc-editor.org/rfc/rfc5280#section-2.6.1", "correct_text": "It should point to https://www.rfc-editor.org/rfc/rfc4518#section-2.6.1", "notes": "Simple fix to correct an incorrect hyperlink.", "submit_date": "2023-09-26", "submitter_name": "Sean Mullan", "verifier_id": "", "verifier_name": "Roman Danyliw", "update_date": "2024-01-11 21:39:58" }, { "errata_id": "7634", "doc-id": "RFC5280", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.1", "orig_text": " Certificate ::= SEQUENCE {\r\n tbsCertificate TBSCertificate,\r\n signatureAlgorithm AlgorithmIdentifier,\r\n signatureValue BIT STRING }", "correct_text": " Certificate ::= SEQUENCE {\r\n tbsCertificate TBSCertificate,\r\n signatureAlgorithm AlgorithmIdentifier,\r\n signature BIT STRING }", "notes": "The definition in section 4.1 disagrees with the definition in appendix A.1 (page 116) on whether the name of the field containing the signature is \"signatureValue\" or \"signature\". This error appears in RFC 3280 and RFC 2459 as well.\r\n\r\nThe versions of X.509 in force when RFCs 2459, 3280, and 5280 were published use neither of those names. (Those versions of X.509 considered a signature to be an encrypted hash and called the field \"encrypted\".) The current version, ITU-T X.509 (10/2019), defines this field to be \"signature\" in section 6.2.1. (X.509 defines the Certificate type using a component type of SIGNATURE, which has two fields named \"algorithmIdentifier\" and \"signature\".)\r\n\r\nIn addition to changing the field name in the definition of the Certificate type in section 4.1, the title and text of subsection 4.1.1.3 should be updated to replace \"signatureValue\" with \"signature\".\r\n\r\nVerifier note: Hold for document update to avoid changes that potentially break ASN.1", "submit_date": "2023-09-08", "submitter_name": "Nick Harper", "verifier_id": "", "verifier_name": "Deb Cooley", "update_date": "2024-10-29 15:13:01" }, { "errata_id": "7774", "doc-id": "RFC8446", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "4.1.3", "orig_text": "ServerHello.Random", "correct_text": "ServerHello.random", "notes": "Lowercase \"random\".\r\n\r\nThis report was created/verified per Paul Wouter's note at https://www.rfc-editor.org/errata/eid7769.", "submit_date": "2024-01-22", "submitter_name": "Rebecca VanRheenen", "verifier_id": "", "verifier_name": "RFC Editor", "update_date": "2024-01-22 18:43:23" }, { "errata_id": "7870", "doc-id": "RFC9110", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "8.6", "orig_text": " Likewise, a sender MUST NOT forward a message with a Content-Length\r\n header field value that does not match the ABNF above, with one\r\n exception: a recipient of a Content-Length header field value\r\n consisting of the same decimal value repeated as a comma-separated\r\n list (e.g, \"Content-Length: 42, 42\") MAY either reject the message as\r\n invalid or replace that invalid field value with a single instance of\r\n the decimal value, since this likely indicates that a duplicate was\r\n generated or combined by an upstream message processor.", "correct_text": " Likewise, a sender MUST NOT send a message with a Content-Length\r\n header field value that does not match the ABNF above. A\r\n recipient of a Content-Length header field value consisting of\r\n the same decimal value repeated as a comma-separated list (e.g,\r\n \"Content-Length: 42, 42\") MAY either reject the message as invalid\r\n or replace that invalid field value with a single instance of the\r\n decimal value, since this likely indicates that a duplicate was\r\n generated or combined by an upstream message processor.", "notes": "This change aims to fix 2 issues with the text:\r\n\r\nIssue #1\r\nRecall the following from section 8.6:\r\n> Likewise, a sender MUST NOT forward a message with a Content-Length header field value that does not match the ABNF above, ...\r\n\r\nIt wasn't immediately clear to me which of these was the intended meaning:\r\n1. Upon receipt of a message with an invalid Content-Length value, senders MUST NOT forward the message.\r\n2. Upon receipt of a message with an invalid Content-Length value, senders MUST NOT forward the message with the invalid value intact.\r\n\r\nMark Nottingham confirmed on GitHub that the intended meaning is option 2:\r\nhttps://github.com/httpwg/http-core/issues/1113#issuecomment-1937914210\r\n\r\nI propose that the word \"forward\" be changed to \"send\" to clear up the ambiguity.\r\n\r\nIssue #2\r\nWe've just established that the intended meaning of the first half of the sentence in question is that malformed CL header values MUST NOT be forwarded intact.\r\nAn exception to this rule is (by definition) a situation in which invalid CL header values *are* permitted to be forwarded intact.\r\nThe \"exception\" described in the text does not allow for invalid header values to be forwarded intact, so it is a misuse of the word \"exception.\"\r\n\r\nTo clear this up, I propose that the sentence be split in two, and that the word \"exception\" be removed.\n --VERIFIER NOTES-- \nIssue #1: 'forward' and 'send' are defined terms in the specification, and the previous paragraph covers the 'send' -- this requirement is specific to forwarding. It's specifically there to call out the exception _only_ in the forwarding case.\r\n\r\nFor issue #2, this might be more than an editorial problem, but mostly I disagree about \"exception\" being a misuse. I agree that more extensive editorial work could be done, but that is out of scope for an erratum.\r\n\r\nSee https://mailarchive.ietf.org/arch/msg/httpbisa/wYhoNFePlmmj5g58g_70er8pTH4/", "submit_date": "2024-03-24", "submitter_name": "Ben Kallus", "verifier_id": "", "verifier_name": "Francesca Palombini", "update_date": "2024-05-14 08:01:48" }, { "errata_id": "8138", "doc-id": "RFC9110", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "15.4", "orig_text": " 5. If the request method has been changed to GET or HEAD, remove\r\n content-specific header fields, including (but not limited to)\r\n Content-Encoding, Content-Language, Content-Location,\r\n Content-Type, Content-Length, Digest, Last-Modified.", "correct_text": "6.If a redirect request includes a target uri of \r\nredirect link (a recursive redirect request) \r\nsuch as: http://example.com/reditectto=\r\n\"\"http://example.com/redirecto=\"http://bad.examaple.com\"\" \r\na redirect to http://example.com/redirecto=\"http://bad.examaple.com\" \r\nshould be made and than to \r\nhttp://bad.examaple.com that way the security \r\nmessures to redirect to another domain may take place", "notes": "currently the rfc doesn't indicate how web server and \r\nbrowsers should handle recursive rerdirect such as \r\nhttp://example.com/reditectto=\"http://example.com/redirecto=\"http://bad.examaple.com\"\" \r\ntherefore i was able to abuse this behavior to gain \r\ncve and exploitation on web server for 2 main resoans \r\n1. redirect allowed only to same domain logic : with regex on \r\nthe parameter \"gooddomain.com/.*\" which works as intended for the escape of the domain part in the uri but doesnt handle a case where there is a recursive request which is handled by server side.\r\n2. out of domain control which gives the user a choice to know and \r\napprove the moving to another domain because the server views the \r\nrequest as to the same domain\r\n\r\nthe correct text should come after number 5\n --VERIFIER NOTES-- \n\r\nIn rejecting this errata report, I note that the aim of this erratum is not to fix an apparent error, but an addition to the current tex. This sort of text change is not in scope for errata reports, which are meant to collect errors in the documents, things that were actual errors at publication and that would have been fixed at that time had the working group or document authors noticed them -- they were just missed. This is not the case here.\r\n\r\nAdditionally, cyclical redirections are already addressed for clients, and are not relevant for servers, see: https://mailarchive.ietf.org/arch/msg/httpbisa/o3-eUDiKUiC_nWi-5s1wOOmMesU/ for details.", "submit_date": "2024-10-12", "submitter_name": "Roy Yosef Barkay, Tomer Yair", "verifier_id": "", "verifier_name": "Francesca Palombini", "update_date": "2024-10-29 15:02:19" }, { "errata_id": "8874", "doc-id": "RFC8259", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "6", "orig_text": "6. Numbers\r\n\r\n The representation of numbers is similar to that used in most\r\n programming languages. A number is represented in base 10 using\r\n decimal digits. It contains an integer component that may be\r\n prefixed with an optional minus sign, which may be followed by a\r\n fraction part and/or an exponent part. Leading zeros are not\r\n allowed.\r\n\r\n A fraction part is a decimal point followed by one or more digits.\r\n\r\n An exponent part begins with the letter E in uppercase or lowercase,\r\n which may be followed by a plus or minus sign. The E and optional\r\n sign are followed by one or more digits.\r\n\r\n Numeric values that cannot be represented in the grammar below (such\r\n as Infinity and NaN) are not permitted.\r\n\r\n number = [ minus ] int [ frac ] [ exp ]\r\n\r\n decimal-point = %x2E ; .\r\n\r\n digit1-9 = %x31-39 ; 1-9\r\n\r\n e = %x65 / %x45 ; e E\r\n\r\n exp = e [ minus / plus ] 1*DIGIT\r\n\r\n frac = decimal-point 1*DIGIT\r\n\r\n int = zero / ( digit1-9 *DIGIT )\r\n\r\n minus = %x2D ; -\r\n\r\n plus = %x2B ; +\r\n\r\n zero = %x30 ; 0\r\n\r\n This specification allows implementations to set limits on the range\r\n and precision of numbers accepted. Since software that implements\r\n IEEE 754 binary64 (double precision) numbers [IEEE754] is generally\r\n available and widely used, good interoperability can be achieved by\r\n implementations that expect no more precision or range than these\r\n provide, in the sense that implementations will approximate JSON\r\n numbers within the expected precision. A JSON number such as 1E400\r\n or 3.141592653589793238462643383279 may indicate potential\r\n interoperability problems, since it suggests that the software that\r\n created it expects receiving software to have greater capabilities\r\n for numeric magnitude and precision than is widely available.\r\n\r\n Note that when such software is used, numbers that are integers and\r\n are in the range [-(2**53)+1, (2**53)-1] are interoperable in the\r\n sense that implementations will agree exactly on their numeric\r\n values.", "correct_text": "...\r\nTODO something like\r\nhttps://github.com/adligo/ten10b_v1.adligo.org\r\nalso see\r\nhttps://www.ietf.org/archive/id/draft-morgan-ten64-00.html#commentary\r\n...", "notes": "Since JSON is based on ECMAScript now, it should be explicit in how ECMAScript's (decimal) numbers are serialized and deserialized. It should include which algorithms should be used, when, and why. It should be exceedingly specific about rounding, if and when rounding should ever be used! Without being explicit, various implementations will not be able to communicate apples to apples.\n --VERIFIER NOTES-- \n JSON is not based on ECMAScript.\r\n\r\nSee email thread: https://mailarchive.ietf.org/arch/msg/json/gucVG-EN3b2XJsKBsOJBU_6-LLI/", "submit_date": "2026-04-09", "submitter_name": "Scott Morgan", "verifier_id": "", "verifier_name": "Andrew Newton", "update_date": "2026-04-13 20:07:33" }, { "errata_id": "8173", "doc-id": "RFC9525", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "6.1.2", "orig_text": "With regard to the third example", "correct_text": "With regard to the fourth example", "notes": "The third example refers to the email service, which is unrelated to the SIP.", "submit_date": "2024-11-11", "submitter_name": "Shushang Wen", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2024-11-28 15:30:56" }, { "errata_id": "8561", "doc-id": "RFC5280", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "4.1.2.8", "orig_text": " This profile RECOMMENDS that names not be reused for\r\n different entities and that Internet certificates not make use of\r\n unique identifiers.", "correct_text": " It is RECOMMENDED that names not be reused for\r\n different entities and that Internet certificates not make use of\r\n unique identifiers.", "notes": "RECOMMENDS is not a normative language per: \r\n\r\n The key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\",\r\n \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"MAY\", and \"OPTIONAL\" in this\r\n document are to be interpreted as described in [RFC2119].\r\n\r\nThere are other similar uses of RECOMMENDS in the document.", "submit_date": "2025-09-03", "submitter_name": "Mohamed Boucadair", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2025-09-03 13:26:42" }, { "errata_id": "8268", "doc-id": "RFC9110", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "B.2", "orig_text": "The priority of the absolute form of the request URI over the Host\r\nheader field by origin servers has been made explicit to align with\r\nproxy handling. (Section 7.2)", "correct_text": " ", "notes": "This text should be in RFC 9112, Appendix C.3 instead. \r\n\r\nAfter the referred text was moved between RFC-to-be 9110 and 9112 [1], this item from \"Changes from 7230\" was not caught up.\r\n\r\n[1] https://github.com/httpwg/http-core/commit/e47483b5 \r\n\r\nSee also https://www.rfc-editor.org/errata/eid8268.", "submit_date": "2025-01-28", "submitter_name": "Sergey Kandaurov", "verifier_id": "", "verifier_name": "RFC Editor", "update_date": "2025-02-06 18:31:25" }, { "errata_id": "8406", "doc-id": "RFC4271", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "6.8", "orig_text": "If a pair of BGP speakers try to establish a BGP connection with each\r\nother simultaneously, then two parallel connections well be formed.", "correct_text": "If a pair of BGP speakers try to establish a BGP connection with each\r\nother simultaneously, then two parallel connections will be formed.", "notes": "small typo: \"well\" -> \"will\"", "submit_date": "2025-05-06", "submitter_name": "David Naylor", "verifier_id": "", "verifier_name": "RFC Editor", "update_date": "2025-05-08 20:55:11" }, { "errata_id": "8408", "doc-id": "RFC4271", "errata_status_code": "Rejected", "errata_type_code": "Editorial", "section": "9.1.1", "orig_text": "The Phase 1 decision function is a separate process,f which completes\r\n when it has no further work to do.", "correct_text": "The Phase 1 decision function is a separate process, f, which completes\r\n when it has no further work to do.", "notes": "Extra space and comma needed around function \"f\"\n --VERIFIER NOTES-- \nDuplicate of https://www.rfc-editor.org/errata/eid150", "submit_date": "2025-05-07", "submitter_name": "David Naylor", "verifier_id": "", "verifier_name": "Ketan Talaulikar", "update_date": "2025-05-19 07:15:48" }, { "errata_id": "8411", "doc-id": "RFC8446", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "4.2.7", "orig_text": "struct {\r\n NamedGroup named_group_list<2..2^16-1>;\r\n} NamedGroupList;", "correct_text": "struct {\r\n NamedGroup named_group_list<2..2^16-2>;\r\n} NamedGroupList;", "notes": "The specified maximum legal length of the named_group_list vector in the NamedGroupList structure is 2^16-1 bytes. This is invalid because NamedGroup is an enum that occupies two bytes, but 2^16-1 is not an exact multiple of the element size (2 bytes), as required in Section 3.4. It appears that the intended upper bound should be 2^16-2 bytes instead.\r\n\r\nAD note: This is scheduled for the bis document via https://github.com/tlswg/tls13-spec/pull/1380 \n --VERIFIER NOTES-- \n see https://github.com/tlswg/tls13-spec/pull/1380", "submit_date": "2025-05-08", "submitter_name": "Albin Johansson", "verifier_id": "", "verifier_name": "Deb Cooley", "update_date": "2026-05-07 19:28:05" }, { "errata_id": "7650", "doc-id": "RFC8259", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "7", "orig_text": "string = quotation-mark *char quotation-mark\r\n\r\n char = unescaped /\r\n escape (\r\n %x22 / ; \" quotation mark U+0022\r\n %x5C / ; \\ reverse solidus U+005C\r\n %x2F / ; / solidus U+002F\r\n %x62 / ; b backspace U+0008\r\n %x66 / ; f form feed U+000C\r\n %x6E / ; n line feed U+000A\r\n %x72 / ; r carriage return U+000D\r\n %x74 / ; t tab U+0009\r\n %x75 4HEXDIG ) ; uXXXX U+XXXX", "correct_text": "string = quotation-mark *json-char quotation-mark\r\n\r\n json-char = unescaped /\r\n escape (\r\n %x22 / ; \" quotation mark U+0022\r\n %x5C / ; \\ reverse solidus U+005C\r\n %x2F / ; / solidus U+002F\r\n %x62 / ; b backspace U+0008\r\n %x66 / ; f form feed U+000C\r\n %x6E / ; n line feed U+000A\r\n %x72 / ; r carriage return U+000D\r\n %x74 / ; t tab U+0009\r\n %x75 4HEXDIG ) ; uXXXX U+XXXX", "notes": "RFC 5234 Section 2.1 \"Rule Naming\" notes that \"rule names are case insensitive\". It is explained that literal text strings enclosed in quotation marks are case insensitive, and have later been clarified by RFC 7405.\r\nIn RFC 5234 Appendix B, Section B.1 \"Core Rules\", the rule \"CHAR\" is already defined such that it constitutes the core of ABNF, thus no grammar can use those names regarding the previous explanation.\r\n\r\nThe goal of this errata is to propose an alternative for the \"char\" rule such that RFC 8259 can provide a valid grammar regarding the ABNF RFCs.", "submit_date": "2023-09-20", "submitter_name": "Lucas Tesson", "verifier_id": "", "verifier_name": "Andy Newton", "update_date": "2026-05-28 18:39:27" }, { "errata_id": "8423", "doc-id": "RFC8446", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.1.2", "orig_text": " struct {\r\n \tProtocolVersion legacy_version = 0x0303;\t/* TLS v1.2 */\r\n \tRandom random;\r\n \topaque legacy_session_id<0..32>;\r\n \tCipherSuite cipher_suites<2..2^16-2>;\r\n \topaque legacy_compression_methods<1..2^8-1>;\r\n \tExtension extensions<8..2^16-1>;\r\n } ClientHello;", "correct_text": "struct {\r\n \tProtocolVersion legacy_version = 0x0303;\t/* TLS v1.2 */\r\n \tRandom random;\r\n \topaque legacy_session_id<0..32>;\r\n \tCipherSuite cipher_suites<2..2^16-2>;\r\n \topaque legacy_compression_methods<1..2^8-1>;\r\n \tExtension extensions<7..2^16-1>;\r\n} ClientHello;", "notes": "The minimum size of the ClientHello’s extensions is 7 as the bytes of the SupportedVersions field are at least:\r\n- 2 bytes for the type of extension;\r\n- 2 bytes for the length of the extension;\r\n- 1 byte for the length of the following versions;\r\n- 2 bytes per version (and there is at least 1 version).\r\n\r\nThe typo is also present in the section B.3.1.\r\n\r\nThis has been fixed in 8446bis here: https://github.com/tlswg/tls13-spec/pull/1420", "submit_date": "2025-05-19", "submitter_name": "Nizar Nadif", "verifier_id": "", "verifier_name": "Deb Cooley", "update_date": "2026-05-07 18:35:57" }, { "errata_id": "8438", "doc-id": "RFC8259", "errata_status_code": "Held for Document Update", "errata_type_code": "Editorial", "section": "14.1", "orig_text": "14.1. Normative References\r\n\r\n [ECMA-404] Ecma International, \"The JSON Data Interchange Format\",\r\n Standard ECMA-404,\r\n .", "correct_text": "14.1. Normative References\r\n\r\n [ECMA-404] Ecma International, \"The JSON Data Interchange Format\",\r\n Standard ECMA-404,\r\n .", "notes": "Link to ECMA-404 should be updated", "submit_date": "2025-05-28", "submitter_name": "vitya-ne", "verifier_id": "", "verifier_name": "Andy Newton", "update_date": "2025-05-29 19:10:14" }, { "errata_id": "7673", "doc-id": "RFC8259", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "7", "orig_text": "The representation of strings is similar to conventions used in the C family\r\nof programming languages. A string begins and ends with quotation marks. All\r\nUnicode characters may be placed within the quotation marks, except for the\r\ncharacters that MUST be escaped: quotation mark, reverse solidus, and the\r\ncontrol characters (U+0000 through U+001F).", "correct_text": "The representation of strings is similar to conventions used in the C family\r\nof programming languages. A string begins and ends with quotation marks. All\r\nUnicode characters may be placed within the quotation marks, except for the\r\ncharacters that MUST be escaped: quotation mark, reverse solidus, and the\r\ncontrol characters (U+0000 through U+001F, U+007F, and U+0080 through\r\nU+009F).", "notes": "There are 33 7-bit control characters, but the JSON RFC only listed 32 by\r\nomitting the inclusion of the last control character in the 7-bit ASCII range,\r\n'del.' However, JSON is not limited to 7-bit ASCII; it is Unicode. Unicode\r\nencompasses 65 control characters from U+0080 to U+009F, totaling an additional\r\n32 characters. The section that currently reads \"U+0000 through U+001F\" should\r\ninclude these additional control characters reading as \"U+0000 through U+001F,\r\nU+007F, and U+0080 through U+009F\"", "submit_date": "2023-10-11", "submitter_name": "Zachary Collier (Zamicol)", "verifier_id": "", "verifier_name": "Andy Newton", "update_date": "2026-05-28 18:39:56" }, { "errata_id": "8459", "doc-id": "RFC9110", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "15", "orig_text": "The status code of a response is a three-digit integer code that \r\ndescribes the result of the request and the semantics of the \r\nresponse, including whether the request was successful and what \r\ncontent is enclosed (if any). All valid status codes are within \r\nthe range of 100 to 599, inclusive.", "correct_text": "The status code of a response is a three-digit integer code that \r\ndescribes the result of the request and the semantics of the \r\nresponse, including whether the request was successful and what \r\ncontent is enclosed (if any). All valid status codes are within \r\nthe range of 100 to 999, inclusive.", "notes": "In the initial RFC 7231 which was obsoleted by this one, we had simple definition of a status code which was used to build http servers, clients and libraries that are being used now \"The status-code element is a three-digit integer code giving the result of the attempt to understand and satisfy the request.\".\r\n\r\nA lot of old systems are based on RFC 7231 and are using status codes that are in rage of 600 - 999. Those codes are mainly used to describe errors that aren't covered in previous status codes.\r\n\r\nFor example we have payment system that can return e.g. \"677 Invalid card number\" and no body. Now we'd probably return \"400 Bad request\" with e.g. json body in which we have error message.\r\n\r\nThis RFC should be backward compatible, and not to define breaking changes. If breaking changes are defined, it should be promoted more and talked about it between the community, give developers of old systems a time to align with new RFC, etc.\r\n\r\nDue to all of this, I'm suggesting that we omit all parts in this section that are limiting status codes to be only in range from 100 to 599, and update it accordingly so it support status codes from 100 to 999.\n --VERIFIER NOTES-- \nSection 6 of RFC 7231 also says \"There are five values for the first digit\" and lists 1xx through 5xx. Going further back, RFC 2616 contains identical language in Section 6.1.1; RFC 2068 contains identical language in its Section 6.1.1. This is not only not a recent change, it's not a change at all. This is the way HTTP has operated for decades, the reporter's noncompliant systems notwithstanding.", "submit_date": "2025-06-13", "submitter_name": "Bosko Stupar", "verifier_id": "", "verifier_name": "Mike Bishop (WIT AD)", "update_date": "2025-06-13 18:04:51" }, { "errata_id": "5210", "doc-id": "RFC8259", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "GLOBAL", "orig_text": "Internet Engineering Task Force (IETF) T. Bray, Ed.\r\nRequest for Comments: 8259 Textuality\r\nObsoletes: 7159 December 2017\r\nCategory: Standards Track\r\nISSN: 2070-1721", "correct_text": "Internet Engineering Task Force (IETF) T. Bray, Ed.\r\nRequest for Comments: 8259 Textuality\r\nSTD: 90 December 2017\r\nObsoletes: 7159\r\nCategory: Standards Track\r\nISSN: 2070-1721", "notes": "Missing \"STD\" entry in boilerplate.", "submit_date": "2017-12-16", "submitter_name": "Julian Reschke", "verifier_id": "", "verifier_name": "Andy Newton", "update_date": "2026-05-28 18:40:19" }, { "errata_id": "8622", "doc-id": "RFC8259", "errata_status_code": "Rejected", "errata_type_code": "Technical", "section": "4", "orig_text": "...The names within an object SHOULD be unique.", "correct_text": "Unknown, this contradicts the ECMA-404 specification.", "notes": "In both the ECMA-404 and the RFC 8259 specifications, it is stated that both descriptions should be considered equal. However, in RFC 8259 it is stated that names in an object should be unique, whereas in ECMA-404 it says in section 6 : \"The JSON syntax does not impose any restrictions on\r\nthe strings used as names, does not require that name strings be unique...\"\r\n\r\nThis seems to expose a contradiction between the two, expectedly equal specifications.\n --VERIFIER NOTES-- \n Consensus is to reject.\r\n\r\nsee https://mailarchive.ietf.org/arch/msg/json/reBGZ98FYQeyvfi-bWkFtzJPrdk/", "submit_date": "2025-10-31", "submitter_name": "Fótyék Róbert", "verifier_id": "", "verifier_name": "Andy Newton", "update_date": "2025-11-01 17:25:58" }, { "errata_id": "8764", "doc-id": "RFC4254", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4", "orig_text": " byte SSH_MSG_GLOBAL_REQUEST\r\n string request name in US-ASCII only\r\n boolean want reply\r\n .... request-specific data follows\r\n\r\n The value of 'request name' follows the DNS extensibility naming\r\n convention outlined in [SSH-ARCH].\r\n\r\n The recipient will respond to this message with\r\n SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if 'want reply' is\r\n TRUE.\r\n\r\n byte SSH_MSG_REQUEST_SUCCESS\r\n .... response specific data\r\n\r\n Usually, the 'response specific data' is non-existent.\r\n\r\n If the recipient does not recognize or support the request, it simply\r\n responds with SSH_MSG_REQUEST_FAILURE.\r\n\r\n byte SSH_MSG_REQUEST_FAILURE\r\n", "correct_text": " byte SSH_MSG_GLOBAL_REQUEST\r\n string request name in US-ASCII only\r\n boolean want reply\r\n .... request-specific data follows\r\n\r\n The value of 'request name' follows the DNS extensibility naming\r\n convention outlined in [SSH-ARCH].\r\n\r\n The recipient will respond to this message with\r\n SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE if 'want reply' is\r\n TRUE. If 'want reply' is false, the recipient MUST NOT send a response,\r\n even if the request is not recognized or supported.\r\n\r\n byte SSH_MSG_REQUEST_SUCCESS\r\n .... response specific data\r\n\r\n Usually, the 'response specific data' is non-existent.\r\n\r\n If the recipient does not recognize or support the request, it simply\r\n responds with SSH_MSG_REQUEST_FAILURE if 'want reply' is true.\r\n\r\n byte SSH_MSG_REQUEST_FAILURE\r\n", "notes": "The original wording was unclear on whether a response could be sent if 'want reply' was false, especially in the case where the request was not recognized or supported.\r\n\r\nThis is important because both sides depend on the order of responses to match response with request in the event that multiple requests are sent, so it needs to be possible to deterministically know whether a response will be sent. Therefore, if 'want reply' is false, the recipient MUST NOT send a response in any circumstances.", "submit_date": "2026-02-16", "submitter_name": "Joseph Galbraith", "verifier_id": "", "verifier_name": "Deb Cooley", "update_date": "2026-05-07 19:19:52" }, { "errata_id": "8794", "doc-id": "RFC8446", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "2.3", "orig_text": " Client Server\r\n\r\n ClientHello\r\n + early_data\r\n + key_share*\r\n + psk_key_exchange_modes\r\n + pre_shared_key\r\n (Application Data*) -------->\r\n ServerHello\r\n + pre_shared_key\r\n + key_share*\r\n {EncryptedExtensions}\r\n + early_data*\r\n {Finished}\r\n <-------- [Application Data*]\r\n (EndOfEarlyData)\r\n {Finished} -------->\r\n [Application Data] <-------> [Application Data]", "correct_text": " Client Server\r\n\r\n ClientHello\r\n + early_data\r\n + key_share*\r\n + psk_key_exchange_modes\r\n + pre_shared_key\r\n (Application Data*) -------->\r\n ServerHello\r\n + pre_shared_key\r\n + key_share*\r\n {EncryptedExtensions}\r\n + early_data*\r\n {Finished}\r\n <-------- [Application Data*]\r\n (EndOfEarlyData*)\r\n {Finished} -------->\r\n [Application Data] <-------> [Application Data]", "notes": "Section 4.5 reads: \"If the server sent an \"early_data\" extension in EncryptedExtensions, the client MUST send an EndOfEarlyData message after receiving the server Finished. If the server does not send an \"early_data\" extension in EncryptedExtensions, then the client MUST NOT send an EndOfEarlyData message.\"\r\nTherefore, EndOfEarlyData is sent only if the server sends an \"early_data\" extension and should be marked as situation-dependent.\r\n\r\nSEC AD (Paul Wouters) note: this is now filed against the 8446bis doc: https://github.com/tlswg/tls13-spec/issues/1409", "submit_date": "2026-03-02", "submitter_name": "Loïc Ferreira", "verifier_id": "", "verifier_name": "Paul Wouters", "update_date": "2026-03-02 17:50:00" }, { "errata_id": "8795", "doc-id": "RFC8446", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "4.6.2", "orig_text": "A client that receives a CertificateRequest message without having sent the \r\n\"post_handshake_auth\" extension MUST send an \"unexpected_message\" fatal alert.", "correct_text": "A client that receives a CertificateRequest message encrypted with the \r\nserver_application_traffic_secret_N without having sent the \r\n\"post_handshake_auth\" extension MUST send an \"unexpected_message\" fatal alert.", "notes": "This sentence is to be understood in the context of a possible post-handshake authentication. During a main handshake, a CertificateRequest message (encrypted with the server_handshake_traffic_secret) may be sent by the server (without need for the client to send a \"post_handshake_auth\" extension).\r\n\r\nThis has been fixed in 8446bis here: https://github.com/tlswg/tls13-spec/pull/1424", "submit_date": "2026-03-02", "submitter_name": "Loïc Ferreira", "verifier_id": "", "verifier_name": "Deb Cooley", "update_date": "2026-05-07 18:37:58" }, { "errata_id": "8799", "doc-id": "RFC8446", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "2.2", "orig_text": " Client Server\r\n\r\n Initial Handshake:\r\n ClientHello\r\n + key_share -------->\r\n ServerHello\r\n + key_share\r\n {EncryptedExtensions}\r\n {CertificateRequest*}\r\n {Certificate*}\r\n {CertificateVerify*}\r\n {Finished}\r\n <-------- [Application Data*]\r\n {Certificate*}\r\n {CertificateVerify*}\r\n {Finished} -------->\r\n <-------- [NewSessionTicket]\r\n [Application Data] <-------> [Application Data]", "correct_text": " Client Server\r\n\r\n Initial Handshake:\r\n ClientHello\r\n + key_share\r\n + psk_key_exchange_modes -------->\r\n ServerHello\r\n + key_share\r\n {EncryptedExtensions}\r\n {CertificateRequest*}\r\n {Certificate*}\r\n {CertificateVerify*}\r\n {Finished}\r\n <-------- [Application Data*]\r\n {Certificate*}\r\n {CertificateVerify*}\r\n {Finished} -------->\r\n <-------- [NewSessionTicket]\r\n [Application Data] <-------> [Application Data]", "notes": "According to Errata ID 7003, Section 4.6.1 should say: \"At any time after the server has received both a \"psk_key_exchange_modes\" extension and a Finished message, it MAY send a NewSessionTicket message.\"\r\n\r\nFixed in 8446bis here: https://github.com/tlswg/tls13-spec/pull/1345", "submit_date": "2026-03-03", "submitter_name": "Loïc Ferreira", "verifier_id": "", "verifier_name": "Deb Cooley", "update_date": "2026-05-07 18:41:29" }, { "errata_id": "8803", "doc-id": "RFC8446", "errata_status_code": "Verified", "errata_type_code": "Technical", "section": "E.1", "orig_text": "The PSK binder value forms a binding between a PSK and the current handshake, as \r\nwell as between the session where the PSK was established and the current \r\nsession. This binding transitively includes the original handshake transcript, \r\nbecause that transcript is digested into the values which produce the resumption \r\nmaster secret.", "correct_text": "The PSK binder value forms a binding between a PSK and the current handshake, as \r\nwell as between the session where the PSK was established (if established via a \r\nNewSessionTicket message) and the current session. This binding transitively \r\nincludes the original handshake transcript, because that transcript is digested \r\ninto the values which produce the resumption master secret.", "notes": "The last sentence is not correct since it does not hold for an external PSK (computed independently from the resumption master secret).\r\n\r\nNB: section 4.2.11.2 adds this precision: \"The PSK binder value forms a binding between a PSK and the current handshake, as well as a binding between the handshake in which the PSK was generated (if via a NewSessionTicket message) and the current handshake.\"\r\n\r\nFixed in 8446bis here: https://github.com/tlswg/tls13-spec/pull/1423", "submit_date": "2026-03-04", "submitter_name": "Loïc Ferreira", "verifier_id": "", "verifier_name": "Deb Cooley", "update_date": "2026-05-07 18:40:34" }, { "errata_id": "8850", "doc-id": "RFC2119", "errata_status_code": "Reported", "errata_type_code": "Editorial", "section": "6", "orig_text": "Guidance in the use of these Imperatives\r\n\r\n Imperatives of the type defined in this memo must be used with care\r\n and sparingly. ", "correct_text": "Guidance in the use of these Keywords\r\n\r\n Keywords of the type defined in this memo must be used with care\r\n and sparingly. ", "notes": "These terms are not imperative bud are modal auxiliaries and partiples. While some have an imperative-like force that s true of oly a few while the intention of this section is to refer to all of these keywords,", "submit_date": "2026-03-21", "submitter_name": "David Noveck", "verifier_id": "", "verifier_name": null, "update_date": null }, { "errata_id": "5318", "doc-id": "RFC8259", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "7", "orig_text": "string = quotation-mark *char quotation-mark\r\n\r\n char = unescaped /\r\n escape (\r\n %x22 / ; \" quotation mark U+0022\r\n %x5C / ; \\ reverse solidus U+005C\r\n %x2F / ; / solidus U+002F\r\n %x62 / ; b backspace U+0008\r\n %x66 / ; f form feed U+000C\r\n %x6E / ; n line feed U+000A\r\n %x72 / ; r carriage return U+000D\r\n %x74 / ; t tab U+0009\r\n %x75 4HEXDIG ) ; uXXXX U+XXXX\r\n\r\n escape = %x5C ; \\\r\n\r\n quotation-mark = %x22 ; \"\r\n\r\n unescaped = %x20-21 / %x23-5B / %x5D-10FFFF", "correct_text": "string = quotation-mark *char quotation-mark\r\n\r\n char = unescaped /\r\n escape (\r\n %x22 / ; \" quotation mark U+0022\r\n %x5C / ; \\ reverse solidus U+005C\r\n %x2F / ; / solidus U+002F\r\n %x62 / ; b backspace U+0008\r\n %x66 / ; f form feed U+000C\r\n %x6E / ; n line feed U+000A\r\n %x72 / ; r carriage return U+000D\r\n %x74 / ; t tab U+0009\r\n %x75 4HEXDIG ) ; uXXXX U+XXXX\r\n\r\n escape = %x5C ; \\\r\n\r\n quotation-mark = %x22 ; \"\r\n\r\n unescaped = %x20-21 / %x23-2E / %x30-5B / %x5D-10FFFF", "notes": "The solidus U+002F is listed as being escaped above, but is not excluded in the 'unescaped' sequence.", "submit_date": "2018-04-04", "submitter_name": "Joakim Erdfelt", "verifier_id": "", "verifier_name": "Andy Newton", "update_date": "2026-05-28 18:40:55" }, { "errata_id": "9004", "doc-id": "RFC9111", "errata_status_code": "Reported", "errata_type_code": "Technical", "section": "3.5", "orig_text": "A shared cache MUST NOT use a cached response to a request with an\r\nAuthorization header field (Section 11.6.2 of [HTTP]) to satisfy any\r\nsubsequent request unless the response contains a Cache-Control field\r\nwith a response directive (Section 5.2.2) that allows it to be stored\r\nby a shared cache, and the cache conforms to the requirements of that\r\ndirective for that response. In this specification, the following\r\nresponse directives have such an effect: must-revalidate\r\n(Section 5.2.2.2), public (Section 5.2.2.9), and s-maxage\r\n(Section 5.2.2.10).", "correct_text": "A shared cache MUST NOT use a cached response to a request with an\r\nAuthorization header field (Section 11.6.2 of [HTTP]) to satisfy any\r\nsubsequent request unless the response contains a Cache-Control field\r\nwith a response directive (Section 5.2.2) that allows it to be stored\r\nby a shared cache, and the cache conforms to the requirements of that\r\ndirective for that response. In this specification, the following\r\nresponse directives have such an effect: must-revalidate\r\n(Section 5.2.2.2), public (Section 5.2.2.9), and s-maxage\r\n(Section 5.2.2.10). Note that proxy-revalidate (Section 5.2.2.8) is\r\nnot included here: although Section 5.2.2.8 states it is analogous to\r\nmust-revalidate, it governs revalidation behavior after a response\r\nbecomes stale and does not itself authorize a shared cache to store a\r\nresponse to an authenticated request.", "notes": "Section 5.2.2.8 states that proxy-revalidate \"is analogous to must-revalidate (Section 5.2.2.2), except that proxy-revalidate does not apply to private caches\" — i.e., proxy-revalidate is the shared-cache-specific counterpart of must-revalidate. However, the list in Section 3.5 of response directives that allow a shared cache to store a response to an authenticated request includes must-revalidate but omits proxy-revalidate. This creates an apparent inconsistency between Sections 3.5 and 5.2.2.8. This is submitted as Editorial. The proposed corrected text adds a clarifying note explaining why proxy-revalidate is excluded (it governs revalidation after staleness, not storage authorization), so the relationship between the two sections is made explicit and reader confusion is removed. No change to caching behavior is requested.", "submit_date": "2026-06-11", "submitter_name": "zhangph", "verifier_id": "", "verifier_name": null, "update_date": "2026-06-11 18:06:23" }, { "errata_id": "9049", "doc-id": "RFC6125", "errata_status_code": "Verified", "errata_type_code": "Editorial", "section": "6.2.1", "orig_text": "Implementers are advised to monitor the state of the art with regard to \r\ncertificate issuance policies and migrate away from support CN-IDs in the\r\nfuture if possible.", "correct_text": "Implementers are advised to monitor the state of the art with regard to \r\ncertificate issuance policies and migrate away from support for CN-IDs in the \r\nfuture if possible.", "notes": "r/support/support for", "submit_date": "2026-07-28", "submitter_name": "Peng Yuan", "verifier_id": "", "verifier_name": "Madison Church", "update_date": "2026-08-03 16:51:45" }, { "errata_id": "9095", "doc-id": "RFC8259", "errata_status_code": "Reported", "errata_type_code": "Technical", "section": "11", "orig_text": "\r\n\r\nNote: No \"charset\" parameter is defined for this registration.\r\n Adding one really has no effect on compliant recipients.", "correct_text": "", "notes": "The first sentence of the note first repeats and \r\nwith the second sentence contradicts the statement made a few lines earlier\r\nin the section: `Optional parameters: n/a` that there are no media type parameters allowed.\r\n\r\nDisallowing the \"charset\" parameter is in line with the change from RFC7159 \r\nthat `Section 8.1 was changed to require the use of UTF-8 when transmitted over a network.` \r\nThe \"no effect\" statement in the note was understandable for the obsolete standards \r\nwhere other encodings were allowed. \r\nBut the rationale for it in RFC8259 is not obvious nor given. \r\nAs argument to the contrary: Security aware applications over the last years increasingly implement \r\nstrict whitelisting of allowed variations. Seeing a charset parameter where non is allowed will not pass\r\nby a strictly whitelisting, compliant recipient implementation. \r\nAnd thus it will have a negative effect on those compliant recipients - which makes the note wrong. \r\n(If the WG would have wished for interoperability with the old standards at this point, it would\r\nhave allowed \"charset\" as optional and then added a note that only \"utf-8\" is compatible with this RFC.)\r\n(This errata report has some similarities with Errata-ID: 5853 but is different in that it suggests to\r\nfully remove the wrong note.)\r\n\r\nSuggestion: remove the wrong note (and the then superfluous repetition)", "submit_date": "2026-08-06", "submitter_name": "Bernhard E. Reiter", "verifier_id": "", "verifier_name": null, "update_date": "2026-08-10 16:38:45" }, { "errata_id": "9185", "doc-id": "RFC9111", "errata_status_code": "Reported", "errata_type_code": "Technical", "section": "4.3.4", "orig_text": "The initial set of stored responses to update are those that could\r\nhave been chosen for that request -- i.e., those that meet the\r\nrequirements in Section 4, except the last requirement to be fresh,\r\nable to be served stale, or just validated.", "correct_text": "Replace the original paragraph with,\r\n\r\n The initial set consists of stored responses that satisfy all of\r\n the following conditions with respect to the request that\r\n elicited the 304 response:\r\n\r\n * The target URI matches that of the request.\r\n\r\n * The method associated with the stored response permits its use\r\n for the request.\r\n\r\n * Either the selecting request header fields match as specified\r\n in Section 4.1, or the stored response and the 304 response\r\n contain ETag field values that match using the strong\r\n comparison function defined in Section 8.8.3.2 of [HTTP].\r\n\r\nAt the end of Section 4.3.4, append\r\n\r\nWhen a response is identified for update through a strong\r\nentity-tag match despite a selecting-header mismatch, the cache\r\nMUST, for the purposes of Section 4.1, associate the updated\r\nresponse with the header fields of the request that elicited the\r\n304 response. Subsequent matching uses those request header fields\r\nand the updated response's Vary field. The cache MAY retain a\r\nseparate, unmodified entry associated with the original request.", "notes": "The choice to recast the affected paragraph as a list of criteria rather than a\r\nlist of exceptions to the Section 4 requirements is editorial. The key technical\r\nchange is to allow the initial set to include stored responses whose requests\r\nhave nonmatching selecting request header fields if the stored response is a\r\nstrong ETag match to the 304 response.\r\n\r\nSuppose we have a stored request,\r\n\r\n GET /\r\n Accept-Language: en, fr\r\n\r\nwith response\r\n\r\n 200 OK\r\n Vary: Accept-Language\r\n Content-Language: en\r\n ETag: \"xyz\"\r\n\r\nWe later receive a request,\r\n\r\n GET /\r\n Accept-Language: en, de\r\n\r\nSection 4.3.1 permits the cache to forward that request with\r\n\r\n If-None-Match: \"xyz\"\r\n\r\nIf the selected representation at the origin still has the strong entity tag\r\n\"xyz\", the origin can respond:\r\n\r\n 304 Not Modified\r\n Vary: Accept-Language\r\n Content-Language: en\r\n ETag: \"xyz\"\r\n \r\nThe strong ETag establishes that the stored representation is the representation\r\nselected for the validating request. Nevertheless, the current wording of\r\nSection 4.3.4 excludes the stored response before comparing the ETag, solely\r\nbecause its Accept-Language value does not match under Section 4.1.\r\n\r\nRFC 2616 and 7234 allowed this use of validation to resolve content-negotiation\r\nmismatches. The restriction added in RFC 9111 was intended to prevent a\r\nvalidation response from updating unrelated stored responses, particularly where\r\nvalidators do not uniquely identify a representation. HTTP Working Group issue #839\r\nrecords the concern that a Last-Modified value treated as a strong validator could\r\ncause a 304 response to update distinct representations that share a modification\r\ntimestamp.\r\n\r\nThe correct text preserves the existing restriction in the cases that originally\r\nmotivated it, while allowing a strong ETag match to perform the representation\r\nidentification contemplated by Section 4.3.1.", "submit_date": "2026-09-24", "submitter_name": "Daniel Fox Franke", "verifier_id": "", "verifier_name": null, "update_date": "2026-09-28 15:11:43" }, { "errata_id": "9162", "doc-id": "RFC9110", "errata_status_code": "Reported", "errata_type_code": "Technical", "section": "5.2", "orig_text": "When a field name is repeated within a section, its combined\r\n field value consists of the list of corresponding field line values\r\n within that section, concatenated in order, with each field line\r\n value separated by a comma.\r\n\r\n For example, this section:\r\n\r\n Example-Field: Foo, Bar\r\n Example-Field: Baz\r\n\r\n contains two field lines, both with the field name \"Example-Field\".\r\n The first field line has a field line value of \"Foo, Bar\", while the\r\n second field line value is \"Baz\". The field value for \"Example-\r\n Field\" is the list \"Foo, Bar, Baz\".", "correct_text": "When a field name is repeated within a section, its combined\r\n field value consists of the list of corresponding field line values\r\n within that section, concatenated in order, with each field line\r\n value separated by a comma SP (\", \").\r\n\r\n For example, this section:\r\n\r\n Example-Field: Foo, Bar\r\n Example-Field: Baz\r\n\r\n contains two field lines, both with the field name \"Example-Field\".\r\n The first field line has a field line value of \"Foo, Bar\", while the\r\n second field line value is \"Baz\". The field value for \"Example-\r\n Field\" is the list \"Foo, Bar, Baz\".", "notes": "The original text says, \"with each field line value separated by a comma\", but in the example, it shows the field line values being separated by a comma SP (\", \") instead of just a comma (\",\"). Hence, either the given definition of \"combined field value\" is incorrect, or the example intended to demonstrate it is incorrect.", "submit_date": "2026-09-01", "submitter_name": "Julian Shepherd", "verifier_id": "", "verifier_name": null, "update_date": "2026-09-02 18:59:03" }, { "errata_id": "9164", "doc-id": "RFC9110", "errata_status_code": "Reported", "errata_type_code": "Technical", "section": "Appendix A", "orig_text": "In the collected ABNF below, list rules are expanded per Section 5.6.1.", "correct_text": "In the collected ABNF below, list rules are expanded per Section 5.6.1. The collected rules are otherwise a normalised rendering of the rules defined in the body: adjacent quoted terminals may be combined into a single quoted string, case-sensitive strings may be written in hexadecimal notation, and repetition bounds may be written in their shortest equivalent form.", "notes": "Appendix A declares exactly one difference from the body — list-rule expansion — but applies at least three further transformations. Each is semantically equivalent ABNF, so no interoperability question arises: the collected grammar and the body define the same language throughout. The issue is only that the appendix names one transformation and performs several, which leaves a mechanical consumer that diffs Appendix A against the body with mismatches it cannot attribute.\r\n\r\nThe transformations we found, comparing every rule name Appendix A and the body both define (142 collected rules), after excluding the declared list expansion:\r\n\r\n1. Adjacent quoted terminals combined — 3 rules\r\n\r\nmedia-range §12.5.1 ( type \"/\" \"*\" ) — Appendix A ( type \"/*\" )\r\nhttp-URI §4.2.1 \"http\" \"://\" — Appendix A \"http://\"\r\nhttps-URI §4.2.2 \"https\" \"://\" — Appendix A \"https://\"\r\n\r\n2. Case-sensitive strings rewritten in hex\r\n\r\nGMT §5.6.7 %s\"GMT\" — Appendix A %x47.4D.54\r\nweak §8.8.3 %s\"W/\" — Appendix A %x57.2F\r\n\r\n3. Repetition bounds shortened\r\n\r\nqvalue §12.4.2 ( \"0\" [ \".\" 0*3DIGIT ] ) / ( \"1\" [ \".\" 0*3(\"0\") ] ) — Appendix A ( \"0\" [ \".\" *3DIGIT ] ) / ( \"1\" [ \".\" *3\"0\" ] )\r\ndate3 §5.6.7 month SP ( 2DIGIT / ( SP 1DIGIT )) — Appendix A month SP ( 2DIGIT / ( SP DIGIT ) )\r\n\r\nThe correction above is the smaller of the two possible fixes: one clause declaring that Appendix A is a normalised rendering resolves the whole class permanently. The alternative is to align the individual rules so the collected forms match the body's, which is a handful of one-line changes.\r\n\r\nWe are explicit that this is editorial and low-severity, and we would not argue with a decision to close it as \"no action needed\" — the value would then be in the answer being on the record.\r\n\r\nFound while transpiling RFC 9110 into rule-ID-traceable conformance oracles (gitlab.com/g6302/lintology). Our own extraction recorded both spellings of media-range as faithful, which they are; the divergence is visible only on comparison, which is exactly what a mechanical consumer of Appendix A does.\r\n\r\nPrecedent for this class: RFC 9112 Errata ID 7744 (obs-text citing Section 5.6.4 where it is defined in Section 5.5, noting \"This error also appears in 'Appendix A. Collected ABNF'\") was filed as Editorial and verified 2024-01-03.", "submit_date": "2026-09-07", "submitter_name": "Alexander Leschinsky, G&L Geißendörfer & Leschinsky GmbH", "verifier_id": "", "verifier_name": null, "update_date": "2026-09-08 15:43:23" }, { "errata_id": "9166", "doc-id": "RFC9111", "errata_status_code": "Held for Document Update", "errata_type_code": "Technical", "section": "5.2.3", "orig_text": "The Cache-Control header field can be extended through the use of one or more extension cache directives.", "correct_text": "The Cache-Control header field can be extended through the use of one or more extension cache directives. Additionally, other HTTP extensions (such as header fields) can also modify the operation of HTTP caches.", "notes": "During no-vary-search standardisation, we encountered views that this text precluded other HTTP extensions from modifying the operation of a HTTP cache without updating this specification. This clarification should be held for document update.", "submit_date": "2026-09-09", "submitter_name": "Mark Nottingham", "verifier_id": "", "verifier_name": "Mike Bishop", "update_date": "2026-09-29 17:38:25" } ]