RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (1)

RFC 9116, "A File Format to Aid in Security Vulnerability Disclosure", April 2022

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6946
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, PDF, HTML

Reported By: Edwin Balani
Date Reported: 2022-04-28
Verifier Name: RFC Editor
Date Verified: 2022-04-28

Section 4 says:

   unsigned       =  *line (contact-field eol) ; one or more required
                     *line (expires-field eol) ; exactly one required
                     *line [lang-field eol] *line ; exactly one optional
                     ; order of fields within the file is not important
                     ; except that if contact-field appears more
                     ; than once, the order of those indicates
                     ; priority (see Section 3.5.3)

It should say:

   unsigned       =  *line (contact-field eol) ; one or more required
                     *line (expires-field eol) ; exactly one required
                     *line [lang-field eol] *line ; exactly one optional
                     ; order of fields within the file is not important
                     ; except that if contact-field appears more
                     ; than once, the order of those indicates
                     ; priority (see Section 2.5.3)

Notes:

Reference to Section 2.5.3 (describing ordering semantics of the Contact field) mistakenly given in ABNF comments as "Section 3.5.3"

Status: Reported (2)

RFC 9116, "A File Format to Aid in Security Vulnerability Disclosure", April 2022

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 7264
Status: Reported
Type: Technical
Publication Format(s) : HTML

Reported By: Michael Osipov
Date Reported: 2022-12-10

Section 2.5.5 says:

Expires: 2021-12-31T18:37:07z

It should say:

Expires: 2021-12-31T18:37:07Z

Notes:

The ISO 8601 zulu indicator MUST be an upper case Z, not a lower case one.

Errata ID: 7743
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML

Reported By: Esa Jokinen
Date Reported: 2023-12-30

Section 4 says:

   CRLF             =  CR LF
                         ; Internet standard newline

It should say:

   CRLF             =  [CR] LF
                         ; Both CRLF and LF line separators can be used
                         ; (see Section 2.2) as long as the entire file
                         ; uses the chosen line separator.

Notes:

RFC 9116 section 2.2 accepts both CRLF and LF line separators. There is a contradiction in the ABNF Grammar as it suggests only CRLF would be allowed elsewhere whereas LF is an option in "cleartext" & "eol". For consistency, the CRLF should either be mandatory or optional on the entire file, and only CRLF or LF should be used in a single file instead of mixing them.

The referenced RFC 2046 (section 4.1.1) and 5198 (section 2) have chosen the CRLF sequence as a MUST. On the other hand, the context is OpenPGP Message Format that canonicalizes the signed text documents by converting LF to CRLF before signing (RFC 4880, 5.4.2), and the receiving software should convert them to native line endings (RFC 4880, 5.9).

This report respects the intent of section 2.2 to treat line separators more liberally and recognizes that it is not an issue in the context of RFC 4880. The goal is to describe this in the ABNF Grammar with the smallest possible change, resulting in "CRLF" being locally redefined as "[CR] LF".

Report New Errata



Advanced Search