RFC Errata
Found 6 records.
Status: Verified (1)
RFC 6960, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", June 2013
Note: This RFC has been updated by RFC 8954
Source of RFC: pkix (sec)
Errata ID: 5891
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2019-11-02
Verifier Name: Benjamin Kaduk
Date Verified: 2019-11-06
Section Appendix B.2 says:
AuthorityInfoAccessSyntax, GeneralName, CrlEntryExtensions
FROM PKIX1Implicit-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}
It should say:
AuthorityInfoAccessSyntax, GeneralName, CrlEntryExtensions, CRLReason
FROM PKIX1Implicit-2009 -- From [RFC5912]
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)}
Notes:
The CRLReason is not defined in the ASN.1 module, and it should have been imported from the one that is defined in RFC 5212. The ASN.1 compiler will generate an error without this correction.
Status: Reported (3)
RFC 6960, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", June 2013
Note: This RFC has been updated by RFC 8954
Source of RFC: pkix (sec)
Errata ID: 6165
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Yury Strozhevsky
Date Reported: 2020-05-11
Section 1 says:
---
It should say:
o Appendix B.1 provides correct KeyHash type processing description. Now SHA-1 hash must be calculated for responder's public key ASN.1 value without tag, length and unused bits.
Notes:
The RFC6960 changes OCSP protocol in part of KeyHash type calculation. In RFC2560 there is the description:
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
(excluding the tag and length fields)
But in Appendix B.1, which is the major OCSP descriptive module, stated:
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
-- (i.e., the SHA-1 hash of the value of the
-- BIT STRING subjectPublicKey [excluding
-- the tag, length, and number of unused
-- bits] in the responder's certificate)
The difference is in what would be under SHA-1 hash. In RFC2560 KeyHash would be calculated for entire BIT STRING value, with "unused bits" byte (first byte in BIT STRING value), but Appendix B.1 in RFC6960 states that SHA-1 hash must be calculated for BIT STRING value without "unused bits".
Errata ID: 6166
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Yury Strozhevsky
Date Reported: 2020-05-11
Section Appendix B.2 says:
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
-- (excluding the tag and length fields)
It should say:
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
-- (i.e., the SHA-1 hash of the value of the
-- BIT STRING subjectPublicKey [excluding
-- the tag, length, and number of unused
-- bits] in the responder's certificate)
Notes:
These two descriptions of KeyHash produce different SHA-1 hashes due to different values: one is pure BIT STRING value block, with "unused bits" byte, but other - without "unused byte". Also the Appendix B.2 must be aligned with Appendix B.1 information.
Errata ID: 6167
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Yury Strozhevsky
Date Reported: 2020-05-11
Section 4.2.1 says:
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key (excluding the tag and length fields)
It should say:
KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
-- (i.e., the SHA-1 hash of the value of the
-- BIT STRING subjectPublicKey [excluding
-- the tag, length, and number of unused
-- bits] in the responder's certificate)
Notes:
Same explanationa as for https://www.rfc-editor.org/errata/eid6166
Status: Held for Document Update (1)
RFC 6960, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", June 2013
Note: This RFC has been updated by RFC 8954
Source of RFC: pkix (sec)
Errata ID: 5730
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Jaime Hablutzel
Date Reported: 2019-05-22
Held for Document Update by: Paul Wouters
Date Held: 2024-02-23
Section 4.1.1 says:
optionalSignature contains the algorithm identifier and any associated algorithm parameters in signatureAlgorithm; the signature value in signature; and, optionally, certificates the server needs to verify the signed response (normally up to but not including the client’s root certificate).
It should say:
optionalSignature contains the algorithm identifier and any associated algorithm parameters in signatureAlgorithm; the signature value in signature; and, optionally, certificates the server needs to verify the signed request (normally up to but not including the client’s root certificate).
Notes:
The paragraph refers to the signed "response" where it should refer to the signed "request".
Status: Rejected (1)
RFC 6960, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", June 2013
Note: This RFC has been updated by RFC 8954
Source of RFC: pkix (sec)
Errata ID: 5929
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Mohit Sahni
Date Reported: 2019-12-06
Rejected by: Benjamin Kaduk
Date Rejected: 2019-12-10
Section 4.4.1 says:
The nonce cryptographically binds a request and a response to prevent
replay attacks. The nonce is included as one of the
requestExtensions in requests, while in responses it would be
included as one of the responseExtensions. In both the request and
the response, the nonce will be identified by the object identifier
id-pkix-ocsp-nonce, while the extnValue is the value of the nonce.
id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp }
id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }
Nonce ::= OCTET STRING
Notes:
In section 4.1.1, the standard MUST define a maximum length for Nonce or the Nonce MUST be of a defined fixed length. The current implementations that follow this standard are vulnerable to denial of service attacks since they will try to accept even the large size OCSP requests with very big nonce value and eventually will consume more memory.
--VERIFIER NOTES--
Rejected per submitter after discussion.
This is an enhancement request and will be discussed on the lamps@ietf.org mailing list.