RFC Errata
Found 8 records.
Status: Verified (4)
RFC 8995, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", May 2021
Source of RFC: anima (ops)
Errata ID: 6716
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Max Pritikin
Date Reported: 2021-10-19
Verifier Name: Warren Kumari (Ops AD)
Date Verified: 2021-10-19
Section 5.8.3 says:
A registrar MAY be configured to ignore (i.e., override the above policy) the history of the device, but it is RECOMMENDED that this only be configured if hardware-assisted (i.e., Transport Performance Metrics (TPM) anchored) Network Endpoint Assessment (NEA) [RFC5209] is supported.
It should say:
A registrar MAY be configured to ignore (i.e., override the above policy) the history of the device, but it is RECOMMENDED that this only be configured if hardware-assisted (i.e., Trusted Platform Module (TPM) anchored) Network Endpoint Assessment (NEA) [RFC5209] is supported.
Notes:
The logical expansion of 'TPM' in this parenthetical example is the Trusted Platform Module.
Errata ID: 6834
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Esko Dijk
Date Reported: 2022-02-03
Verifier Name: Rob Wilton
Date Verified: 2024-01-15
Section 8.5 says:
* version * Status * Reason * reason-context
It should say:
* version * status * reason * reason-context
Notes:
The CDDL models in section 5.7 and 5.9.4 define the key values with lowercase first character; and the examples in those sections use the same. It seems that during final editing it was forgotten to update Section 8.5.
Errata ID: 7576
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Richardson
Date Reported: 2023-07-26
Verifier Name: Rob Wilton
Date Verified: 2023-11-09
Section 4.3 says:
objective-value = text ; name of the (list of) supported
; protocols: "EST-TLS" for RFC 7030.
It should say:
objective-value = text ; name of the supported protocol,
; e.g., "EST-TLS" for RFC 7030.
Notes:
This objective does not support a list of supported protocols.
The comment in the example might lead people to conclude they can do that.
Errata ID: 6736
Status: Verified
Type: Editorial
Publication Format(s) : TEXT, HTML
Reported By: Michael Richardson
Date Reported: 2021-11-13
Verifier Name: RFC Editor
Date Verified: 2022-01-27
Section 5.5 says:
MASA implementations SHOULD anticipate future media ntypes but, of course, will simply fail the request if those types are not yet known.
It should say:
MASA implementations SHOULD anticipate future media types but, of course, will simply fail the request if those types are not yet known.
Notes:
"ntypes" is not a word
Status: Reported (2)
RFC 8995, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", May 2021
Source of RFC: anima (ops)
Errata ID: 6648
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Michael Richardson
Date Reported: 2021-07-27
Section 5.1 says:
Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED on the pledge side. TLS 1.3 (or newer) SHOULD be available on the registrar server interface, and the registrar client interface, but TLS 1.2 MAY be used. TLS 1.3 (or newer) SHOULD be available on the MASA server interface, but TLS 1.2 MAY be used.
It should say:
Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED on the pledge side. TLS 1.3 (or newer) SHOULD be available on the registrar server interface, and the registrar client interface, but TLS 1.2 MAY be used. When TLS 1.3 is used the use of Server Name Indicator (SNI, [RFC6066]) is not required, per RFC8446 section 9.2, this specification is an application profile specification. A pledge connects to the Registrar using only an IP address and it will not have any idea of a correct SNI value. This also implies that the Registrar interface may not be virtual \ hosted using SNI.
Notes:
Another errata says that SNI is mandatory on MASA interface, and the distinction between the two is subtle.
Errata ID: 7263
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Rufus Buschart
Date Reported: 2022-12-09
Section 5.5 says:
idevid-issuer: The Issuer value from the pledge IDevID certificate is included to ensure unique interpretation of the serial-number. In the case of a nonceless (offline) voucher-request, an appropriate value needs to be configured from the same out-of-band source as the serial-number.
It should say:
idevid-issuer: The Issuer value from the pledge IDevID certificate SHOULD BE included to ensure unique interpretation of the serial- number. In the case of a nonceless (offline) voucher-request, an appropriate value MUST be configured from the same out-of-band source as the serial-number.
Notes:
The current language is no language according to RFC 2119.
Status: Held for Document Update (2)
RFC 8995, "Bootstrapping Remote Secure Key Infrastructure (BRSKI)", May 2021
Source of RFC: anima (ops)
Errata ID: 6642
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Michael Richardson
Date Reported: 2021-07-14
Held for Document Update by: Rob Wilton
Date Held: 2024-01-15
Section 5.4 says:
Use of TLS 1.3 (or newer) is encouraged. TLS 1.2 or newer is REQUIRED. TLS 1.3 (or newer) SHOULD be available.
It should say:
TLS 1.2 [RFC5246] with SNI support [RFC6066] is REQUIRED if TLS 1.3 is not available. The Server Name Indicator (SNI) is required when the Registrar communicates with the MASA in order for the MASA to be hosted in a modern multi-tenant TLS infrastructure.
Notes:
https://mailarchive.ietf.org/arch/msg/anima/bqrZXAk7vstWQ3V1-irIATnBKpY/
This adds new references to the text.
Errata ID: 6649
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Michael Richardson
Date Reported: 2021-07-27
Held for Document Update by: Rob Wilton
Date Held: 2024-01-15
Section 5.5.4. says:
Even when a domain CA is authenticated to the MASA, and there is strong sales channel integration to understand who the legitimate owner is, the above id-kp-cmcRA check prevents arbitrary end-entity certificates (such as an LDevID certificate) from having vouchers issued against them.
It should say:
Even when a domain CA is authenticated to the MASA, and there is strong sales channel integration to understand who the legitimate owner is, the above id-kp-cmcRA check prevents arbitrary end-entity certificates (such as an LDevID certificate) from having vouchers issued against them. add: The id-kp-cmcRA is an Extended Key Usage (EKU) attribute. When any EKU attribute it set, then the certificate MUST have all related attributes set. This means that the Registrar certificate MUST also have the id-kp-clientAuth (for use with the MASA) and the id-kp-serverAuth (for use with the Pledge) set.
Notes:
https://mailarchive.ietf.org/arch/msg/anima/H6Xs_f3rQAh9acOEFXEYuoZZGls/