RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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/

Report New Errata



Advanced Search