RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (1)

RFC 6960, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", June 2013

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 (4)

RFC 6960, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", June 2013

Source of RFC: pkix (sec)

Errata ID: 5730
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Jaime Hablutzel
Date Reported: 2019-05-22

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".

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

Report New Errata



Advanced Search