RFC Errata
Found 4 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