RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 records.

Status: Verified (4)

RFC 3279, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", April 2002

Source of RFC: pkix (sec)

Errata ID: 307
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Olivier Dierick
Date Reported: 2005-08-01

Section 1 says:

   This document specifies algorithm identifiers and ASN.1 [X.660]
   encoding formats for digital signatures and subject public keys used
   in the Internet X.509 Public Key Infrastructure (PKI).

It should say:

   This document specifies algorithm identifiers and ASN.1 [X.690]
   encoding formats for digital signatures and subject public keys used
   in the Internet X.509 Public Key Infrastructure (PKI).

Notes:


In Section 4, it says:
[X.660] ITU-T Recommendation X.660 Information Technology -
ASN.1 encoding rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER), 1997.
It should say:
[X.690] ITU-T Recommendation X.660 Information Technology -
ASN.1 encoding rules: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER), 1997.



Errata ID: 2048
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Jim Wigginton
Date Reported: 2009-10-12
Verifier Name: Pasi Eronen
Date Verified: 2010-02-22

Section 2.3.5 says:

      id-characteristic-two-basis OBJECT IDENTIFIER ::= {
           characteristic-two-field basisType(1) }

It should say:

      id-characteristic-two-basis OBJECT IDENTIFIER ::= {
           characteristic-two-field basisType(3) }

Notes:

Note that this bug is only in Section 2.3.5; the ASN.1 module in Section 3 has the correct OID.

Errata ID: 4036
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Matthias Koenig
Date Reported: 2014-07-03
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-31

Section 2.3.3 says:

g specifies the generator of the multiplicative subgroup of order g;

It should say:

g specifies the generator of the multiplicative subgroup of order q;

Notes:

RFC2631 states that g is of order q mod p (section 2.1.1).
Also, X9.42 (which is referenced in section 2.3.3 of RFC3279) defines g as
"generator of the q-order cyclic subgroup of GF(p), that is, an element of order q in the multiplicative group of GF(p)" (X9.42:2001, section 4.1)

Errata ID: 4102
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Annie Yousar
Date Reported: 2014-09-07
Verifier Name: Kathleen Moriarty
Date Verified: 2015-03-31

Section 1 says:

 This specification describes the encoding of digital signatures
 generated with the following cryptographic algorithms:

|   * Rivest-Shamir-Adelman (RSA);
    * Digital Signature Algorithm (DSA); and
    * Elliptic Curve Digital Signature Algorithm (ECDSA).

It should say:

 This specification describes the encoding of digital signatures
 generated with the following cryptographic algorithms:

|   * Rivest-Shamir-Adleman (RSA);
    * Digital Signature Algorithm (DSA); and
    * Elliptic Curve Digital Signature Algorithm (ECDSA).

Notes:

Len is "Adleman" and not "Adelman". The error repeats a few lines later again. The spelling in 2.2.1 is correct.

Status: Reported (1)

RFC 3279, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", April 2002

Source of RFC: pkix (sec)

Errata ID: 6672
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Jaime Hablutzel
Date Reported: 2021-09-01

Section 2.3.5 says:

If the keyUsage extension is present in a CA or CRL issuer certificate which conveys an elliptic curve public key, any combination of the following values MAY be present:

digitalSignature;
nonRepudiation; and
keyAgreement.

If the keyAgreement value is present, either of the following values MAY be present:

encipherOnly; and
decipherOnly.

The keyUsage extension MUST NOT assert both encipherOnly and decipherOnly.

If the keyUsage extension is present in a CA certificate which conveys an elliptic curve public key, any combination of the following values MAY be present:

digitalSignature;
nonRepudiation;
keyAgreement;
keyCertSign; and
cRLSign.

It should say:

If the keyUsage extension is present in an end entity certificate which conveys an elliptic curve public key, any combination of the following values MAY be present:

digitalSignature;
nonRepudiation; and
keyAgreement.

If the keyAgreement value is present, either of the following values MAY be present:

encipherOnly; and
decipherOnly.

The keyUsage extension MUST NOT assert both encipherOnly and decipherOnly.

If the keyUsage extension is present in a CA or CRL issuer certificate which conveys an elliptic curve public key, any combination of the following values MAY be present:

digitalSignature;
nonRepudiation;
keyAgreement;
keyCertSign; and
cRLSign.

Notes:

- "a CA or CRL issuer certificate" is replaced by "an end entity certificate"
- "CA certificate" is replaced by "CA or CRL issuer certificate"

The need for this correction can be confirmed from RFC 5480, "3. Key Usage Bits".

Corrected wording has been copied from the section "2.3.1 RSA Keys" of this RFC 3279 itself.

Report New Errata



Advanced Search