RFC Errata
Found 2 records.
Status: Reported (2)
RFC 9190, "EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3", February 2022
Source of RFC: emu (sec)
Errata ID: 7577
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alan DeKok
Date Reported: 2023-07-29
Section 2.5 says:
When an EAP-TLS server has successfully processed the TLS client Finished and sent its last handshake message (Finished or a post- handshake message), it sends an encrypted TLS record with application data 0x00. The encrypted TLS record with application data 0x00 is a protected success result indication, as defined in [RFC3748] ...
It should say:
(append) If the EAP-TLS peer does not see the protected success indication, it MUST behave as if it had received an EAP Failure instead.
Notes:
This is largely a nit, but it's reasonable to say this.
The existing text discussed what the server must do, But it does not say what the
peer does if the server fails to behave this way,
Errata ID: 8094
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Eliot Lear
Date Reported: 2024-09-04
Section 2.1.1 says:
Certificates can be of any type supported by TLS including raw public keys.
It should say:
Certificates can be of any type supported by TLS. Raw public keys may also be used.
Notes:
A raw public key specifically is **not** a certificate.