errata logo graphic

Found 7 records.

Status: Verified (3)

RFC2560, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", June 1999

Note: This RFC has been obsoleted by RFC6960

Source of RFC: pkix (sec)

Errata ID: 2253

Status: Verified
Type: Editorial

Reported By: Jim Schaad
Date Reported: 2010-05-12
Verifier Name: Tim Polk
Date Verified: 2010-07-20

Section 4.2.1 says:

UnknownInfo ::= NULL -- this can be replaced with an enumeration

It should say:

UnknownInfo ::= NULL

Notes:

The is no way to change this without making existing decoders fail decoding the answer. The comment should therefore be removed

The same line exists in the ASN.1 module and should be removed there as well.


Errata ID: 2329

Status: Verified
Type: Editorial

Reported By: Shirley Carter
Date Reported: 2010-07-13
Verifier Name: Tim Polk
Date Verified: 2010-07-20

Section 4.2.2.2.1 says:

CAs issuing such a certificate should realized that

It should say:

CAs issuing such a certificate should realize that

Notes:

simple typo "realized" => "realize"


Errata ID: 3417

Status: Verified
Type: Editorial

Reported By: John Soltes
Date Reported: 2012-11-26
Verifier Name: Sean Turner
Date Verified: 2012-11-26

Section 4.2.2.2 says:

Systems or applications that rely on OCSP responses MUST be capable
of detecting and enforcing use of the id-ad-ocspSigning value as
described above.

and

3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage

It should say:

Systems or applications that rely on OCSP responses MUST be capable
of detecting and enforcing use of the id-kp-OCSPSigning value as
described above.

and

3. Includes a value of id-kp-ocspSigning in an ExtendedKeyUsage

Notes:

The first paragraph specifies that an "id-kp-OCSPSigning" value be included, and it then defines that value as "id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}", yet the second paragraph and the third listed alternative specify the use of an "id-ad-ocspSigning" value, which is not defined.

Also, the double quote mark at the end of the third listed alternative should be removed.


Status: Held for Document Update (3)

RFC2560, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", June 1999

Note: This RFC has been obsoleted by RFC6960

Source of RFC: pkix (sec)

Errata ID: 3251

Status: Held for Document Update
Type: Editorial

Reported By: Daniel Barclay
Date Reported: 2012-06-11
Held for Document Update by: Sean Turner

Section 4.2.2.2 says:

...  They MUST reject the response if the certificate required to validate
the signature on the response fails to meet at least one of the following
criteria:

   1. ...
   2. ...
   3. ...

It should say:

...  They MUST reject the response if it is not the case that the
certificate required to validate the signature on the response meets at 
least one of the following criteria:

   1. ...
   2. ...
   3. ...

Notes:

The "fails to meet at least one ... " part of the original wording is ambiguous.

It can sound like the grouping is "(fails to meet) at least one ..." rather than the (apparently) intended "fails to (meet at least one)".

Note: The submitted corrected text needs further improvement. I think it eliminates the ambiguity, but it currently is harder to follow.


Errata ID: 3252

Status: Held for Document Update
Type: Editorial

Reported By: Daniel Barclay
Date Reported: 2012-06-11
Held for Document Update by: Sean Turner
Date Held: 2012-06-28

Section 4.2.2.2.1 says:

... CAs issuing such a certificate should realized that a compromise of the
responder's key, is as serious as the compromise of a CA key used to sign 
CRLs, at least for the validity period of this certificate. ...

It should say:

... CAs issuing such a certificate should realized that a compromise of the
responder's key is as serious as the compromise of a CA key used to sign 
CRLs, at least for the validity period of this certificate. ...

Notes:

That first comma was extraneous.

SPT: I also swapped realized/realize.


Errata ID: 3253

Status: Held for Document Update
Type: Editorial

Reported By: Daniel Barclay
Date Reported: 2012-06-11
Held for Document Update by: Sean Turner

Section 5 says:

For this service to be effective, certificate using systems must connect to
the certificate status service provider. 

It should say:

For this service to be effective, certificate-using systems must connect to
the certificate status service provider. 

Notes:

(Alternatively, that could be "..., systems using certificates must ..."


Status: Rejected (1)

RFC2560, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", June 1999

Note: This RFC has been obsoleted by RFC6960

Source of RFC: pkix (sec)

Errata ID: 3272

Status: Rejected
Type: Technical

Reported By: Matthew Moore
Date Reported: 2012-06-29
Rejected by: Sean Turner
Date Rejected: 2012-07-02

Section 4.1.1 says:

   OCSPRequest     ::=     SEQUENCE {
       tbsRequest                  TBSRequest,
       optionalSignature   [0]     EXPLICIT Signature OPTIONAL }

   TBSRequest      ::=     SEQUENCE {
       version             [0]     EXPLICIT Version DEFAULT v1,
       requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
       requestList                 SEQUENCE OF Request,
       requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }

   Signature       ::=     SEQUENCE {
       signatureAlgorithm      AlgorithmIdentifier,
       signature               BIT STRING,
       certs               [0] EXPLICIT SEQUENCE OF Certificate 
   OPTIONAL}

   Version         ::=             INTEGER  {  v1(0) }

   Request         ::=     SEQUENCE {
       reqCert                     CertID,
       singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
       serialNumber        CertificateSerialNumber }

It should say:

...
   Version         ::=             INTEGER  {  v1(0) }

   GeneralName     ::=      ????
...

Notes:

The format of the GeneralName in the request syntax is never detailed.
--VERIFIER NOTES--
GeneralName is imported in the ASN.1 module from the PKIX1Explicit88 module.


Report New Errata