RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 6 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

Status: Rejected (1)

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

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.

Report New Errata