RFC Errata
Found 10 records.
Status: Verified (7)
RFC 5912, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", June 2010
Note: This RFC has been updated by RFC 6960, RFC 9480
Source of RFC: pkix (sec)
Errata ID: 2839
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Carl Wallace
Date Reported: 2011-06-16
Verifier Name: Sean Turner
Date Verified: 2011-07-26
Section 14 says:
Notes:
anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificatePolicies 0 } does not appear in the PKIX1Implicit-2009 module. It appears in the body of RFC 5280 and in the corresponding ASN.1 module in RFC 5280.
Errata ID: 2649
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2010-11-29
Verifier Name: Tim Polk
Date Verified: 2010-11-30
Section 7, says:
AttributeCertificateVersion1-2009
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) id-mod-v1AttrCert-02(49) } ;
It should say:
AttributeCertificateVersion1-2009
{ iso(1) member-body(2) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-v1AttrCert-02(49) } ;
Notes:
Oid was used from the wrong arc. THis change corrects the arc used for the OID number.
Errata ID: 3130
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Russ Housley
Date Reported: 2012-02-19
Verifier Name: Sean Turner
Date Verified: 2012-03-05
Throughout the document, when it says:
ct-foo CONTENT-TYPE ::=
{ FooType IDENTIFIED BY id-ct-foo }
It should say:
ct-foo CONTENT-TYPE ::=
{ TYPE FooType IDENTIFIED BY id-ct-foo }
Notes:
Of course, 'ct-foo', 'FooType', and 'id-ct-foo' need to be replaced as appropriate for the use of CONTENT-TYPE in RFC 5912. CONTENT-TYPE is imported from a module defined in RFC 5911, and errata 2612 makes a change to that definition. Therefore, 'TYPE' needs to be added each time a content type is defined to align with errata 2612.
The definitions that need to be updated are:
ct-encKeyWithID,
ct-scvp-certValRequest,
ct-scvp-certValResponse,
ct-scvp-valPolRequest,
ct-scvp-valPolResponse,
ct-PKIData, and
ct-PKIResponse.
Errata ID: 3259
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: James Manger
Date Reported: 2012-06-14
Verifier Name: Sean Turner
Date Verified: 2012-07-16
Section 4 says:
CRLReason ::= INTEGER
It should say:
IMPORTS CRLReason FROM PKIX1Implicit-2009
Notes:
CRLReason is correctly defined in section 14 "ASN.1 Module for RFC 5280, Explicit and Implicit" as:
CRLReason ::= ENUMERATED { … }
It is incorrectly re-defined in section 4 "ASN.1 Module for RFC 2560" (OCSP) as an INTEGER. It should import the correct definition instead.
ENUMERATED and INTEGER are similar, but not the same. They are BER-encoded differently (with a tags of 0x0A and 0x02 respectively).
Errata ID: 3626
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Carl Wallace
Date Reported: 2013-05-17
Verifier Name: Sean Turner
Date Verified: 2013-05-20
Section 14 says:
-- CRL number extension OID and syntax
ext-CRLNumber EXTENSION ::= {SYNTAX
INTEGER (0..MAX) IDENTIFIED BY id-ce-cRLNumber }
id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
CRLNumber ::= INTEGER (0..MAX)
It should say:
-- CRL number extension OID and syntax
CRLNumber ::= INTEGER (0..MAX)
ext-CRLNumber EXTENSION ::= {SYNTAX
CRLNumber IDENTIFIED BY id-ce-cRLNumber }
id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
Notes:
The CRLNumber extension was not defined to use the CRLNumber type. It should use the CRLNumber type. This is a corrected resubmission of an earlier errata submission that included an error.
Errata ID: 3692
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Carl Wallace
Date Reported: 2013-08-02
Verifier Name: Sean Turner
Date Verified: 2013-08-12
Section 14 says:
crlExtensions EXTENSION ::= {
ext-AuthorityKeyIdentifier | ext-IssuerAltName |
ext-CRLNumber | ext-DeltaCRLIndicator |
ext-IssuingDistributionPoint | ext-FreshestCRL, ... }
It should say:
crlExtensions EXTENSION ::= {
ext-AuthorityKeyIdentifier | ext-IssuerAltName |
ext-CRLNumber | ext-DeltaCRLIndicator |
ext-IssuingDistributionPoint | ext-FreshestCRL |
ext-AuthorityInfoAccess, ... }
Notes:
Section 5.2.7 of RFC 5280 allows AIA to be a CRL extension.
Errata ID: 6806
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Carl Wallace
Date Reported: 2022-01-03
Verifier Name: Benjamin Kaduk
Date Verified: 2022-01-04
Section 6 says:
pk-rsa PUBLIC-KEY ::= {
IDENTIFIER rsaEncryption
KEY RSAPublicKey
PARAMS TYPE NULL ARE absent
-- Private key format not in this module --
CERT-KEY-USAGE {digitalSignature, nonRepudiation,
keyEncipherment, dataEncipherment, keyCertSign, cRLSign}
}
It should say:
pk-rsa PUBLIC-KEY ::= {
IDENTIFIER rsaEncryption
KEY RSAPublicKey
PARAMS TYPE NULL ARE required
-- Private key format not in this module --
CERT-KEY-USAGE {digitalSignature, nonRepudiation,
keyEncipherment, dataEncipherment, keyCertSign, cRLSign}
}
Notes:
Section 2.3.1 of RFC 3279 states "(t)he parameters field MUST have ASN.1 type NULL for this algorithm identifier."
Status: Reported (2)
RFC 5912, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", June 2010
Note: This RFC has been updated by RFC 6960, RFC 9480
Source of RFC: pkix (sec)
Errata ID: 4145
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Pierce Leonberger
Date Reported: 2014-10-23
Section 14 says:
-- 3. A more complex version, but one that automatically ties
-- together both the signature algorithm and the
-- signature value for automatic decoding.
--
SIGNED{ToBeSigned} ::= SEQUENCE {
toBeSigned ToBeSigned,
algorithmIdentifier SEQUENCE {
algorithm SIGNATURE-ALGORITHM.
&id({SignatureAlgorithms}),
parameters SIGNATURE-ALGORITHM.
&Params({SignatureAlgorithms}
{@algorithmIdentifier.algorithm}) OPTIONAL
},
signature BIT STRING (CONTAINING SIGNATURE-ALGORITHM.&Value(
{SignatureAlgorithms}
{@algorithmIdentifier.algorithm}))
}
It should say:
SIGNED{ToBeSigned} ::= SEQUENCE {
toBeSigned ToBeSigned,
algorithmIdentifier SEQUENCE {
algorithm SIGNATURE-ALGORITHM.
&id({SignatureAlgorithms}),
parameters SIGNATURE-ALGORITHM.
&Params({SignatureAlgorithms}
{@algorithmIdentifier.algorithm}) OPTIONAL
},
signature BIT STRING
}
Notes:
I *believe* the 3rd option for SIGNED{} is invalid. The "signature" BIT STRING contains an OpenType which references an optional class field. It's possible to define objects with no type and OpenTypes must refer to a type. There's no mechanism to allow an OpenType to reference random bytes (not ASN.1 encoded).
I understand the intent is to allow for automatic decoding, but unless the "&Value" is required in SIGNATURE-ALGORITHM this will not work. Requiring it will not work because not all signature algorithms require the signature value to be encoded (e.g. RSA). The syntax would be valid is if "signature" was OPTIONAL (obviously not desirable).
So I propose we revert "signature" to "BIT STRING" without constraints.
Errata ID: 4244
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Richard Nicholas
Date Reported: 2015-01-27
Section 14 says:
at-x520StateOrProvinceName ATTRIBUTE ::=
{ TYPE DirectoryString {ub-state-name}
IDENTIFIED BY id-at-stateOrProvinceName }
X520StateOrProvinceName ::= DirectoryString {ub-state-name}
at-x520OrganizationName ATTRIBUTE ::=
{ TYPE DirectoryString {ub-organization-name}
IDENTIFIED BY id-at-organizationName }
X520OrganizationName ::= DirectoryString {ub-organization-name}
at-x520OrganizationalUnitName ATTRIBUTE ::=
{ TYPE DirectoryString {ub-organizational-unit-name}
IDENTIFIED BY id-at-organizationalUnitName }
X520OrganizationalUnitName ::= DirectoryString
{ub-organizational-unit-name}
It should say:
at-x520StateOrProvinceName ATTRIBUTE ::=
{ TYPE X520StateOrProvinceName
IDENTIFIED BY id-at-stateOrProvinceName }
X520StateOrProvinceName ::= DirectoryString {ub-state-name}
at-x520OrganizationName ATTRIBUTE ::=
{ TYPE X520OrganizationName IDENTIFIED BY id-at-organizationName }
X520OrganizationName ::= DirectoryString {ub-organization-name}
at-x520OrganizationalUnitName ATTRIBUTE ::=
{ TYPE X520OrganizationalUnitName
IDENTIFIED BY id-at-organizationalUnitName }
X520OrganizationalUnitName ::= DirectoryString
{ub-organizational-unit-name}
Notes:
The definitions of the three ATTRIBUTE objects (at-x520StateOrProvinceName, at-x520OrganizationName, at-x520OrganizationalUnitName) should be changed to reference the existing type definitions. This change will eliminate the extra type definition in each of those objects as well as make those object definitions consistent with the definitions for the at-x520LocalityName and at-x520CommonName ATTRIBUTE objects.
Status: Rejected (1)
RFC 5912, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", June 2010
Note: This RFC has been updated by RFC 6960, RFC 9480
Source of RFC: pkix (sec)
Errata ID: 3623
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Carl Wallace
Date Reported: 2013-05-16
Rejected by: Sean Turner
Date Rejected: 2013-05-20
Section 14 says:
-- CRL number extension OID and syntax
ext-CRLNumber EXTENSION ::= {SYNTAX
INTEGER (0..MAX) IDENTIFIED BY id-ce-cRLNumber }
id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
CRLNumber ::= INTEGER (0..MAX)
It should say:
-- CRL number extension OID and syntax
CRLNumber ::= INTEGER
ext-CRLNumber EXTENSION ::= {SYNTAX
CRLNumber IDENTIFIED BY id-ce-cRLNumber }
id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }
Notes:
The CRLNumber extension was not defined to use the CRLNumber type. The CRLNumber type uses MAX to limit the maximum value. This limitation is inconsistent with section 5.2.3 and Appendix B, which allow CRLNumber values up to 20 octets in length.
--VERIFIER NOTES--
This errata is rejected at the request of the person who reported it (i.e., Carl). Another errata was submitted to correct a mistake.