RFC Errata
Found 7 records.
Status: Verified (1)
RFC 5035, "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", August 2007
Source of RFC: smime (sec)
Errata ID: 2364
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Verifier Name: Tim Polk
Date Verified: 2010-07-29
Section 4 says:
On mid-page 6, Section 4 of RFC 5035 gives the following text as part
of the new Section 5.4.1.1, Certificate Identification Version 2 :
The fields of ESSCertIDv2 are defined as follows:
hashAlgorithm
contains the identifier of the algorithm used in computing
certHash.
certHash
is computed over the entire DER-encoded certificate (including the
| signature) using the SHA-1 algorithm.
[...]
The core reason for the new Cert ID version is algorithm agility.
Therefore, specifying SHA-1 here does not make any sense (and it
would turn the hashAlgorithm field useless) !
The 'certHash' field explanation should say:
certHash
is computed over the entire DER-encoded certificate (including the
| signature) using the algorithm specified by hashAlgorithm.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It should say:
See above.
Notes:
See above.
Status: Reported (1)
RFC 5035, "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", August 2007
Source of RFC: smime (sec)
Errata ID: 6566
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: David von Oheimb
Date Reported: 2021-04-29
Section 3 says:
certs
contains the list of certificates that are to be used in
validating the message. The first certificate identified in the
sequence of certificate identifiers MUST be the certificate used
to verify the signature. The encoding of the ESSCertIDv2 for this
certificate SHOULD include the issuerSerial field. If other
constraints ensure that issuerAndSerialNumber will be present in
the SignerInfo, the issuerSerial field MAY be omitted. The
certificate identified is used during the signature verification
process. If the hash of the certificate does not match the
certificate used to verify the signature, the signature MUST be
considered invalid.
If more than one certificate is present, subsequent certificates
limit the set of certificates that are used during validation.
It should say:
certs
contains the list of certificates that are to be used in
validating the message. It MUST contain at least one element.
The first certificate identified in the
sequence of certificate identifiers MUST be the certificate used
to verify the signature. The encoding of the ESSCertIDv2 for this
certificate SHOULD include the issuerSerial field. If other
constraints ensure that issuerAndSerialNumber will be present in
the SignerInfo, the issuerSerial field MAY be omitted. The
certificate identified is used during the signature verification
process. If the hash of the certificate does not match the
certificate used to verify the signature, the signature MUST be
considered invalid.
If more than one certificate identifier is present in the sequence of ESSCertIDv2s,
all certificates referenced there MUST be part of the signature validation chain.
Notes:
Some aspects of the 'certs' field of a SigningCertificateV2 attribute:
SigningCertificateV2 ::= SEQUENCE {
certs SEQUENCE OF ESSCertIDv2,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
described in the sentences quoted above are rather vague.
This lead to major confusion and wrong implementations.
As meanwhile has been clarified, they should be re-phrased;
see suggested new version above.
(One may further mandate/clarify that the certificate identifiers must be given in the same order
as they are expected in the validation chain, but I think this is not important because
the order should not play a critical role and will be determined by the validation chain anyway.)
Status: Held for Document Update (3)
RFC 5035, "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", August 2007
Source of RFC: smime (sec)
Errata ID: 1007
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
Section A says:
At the end of Appendix A, near the bottom of page 15, the last
two ASN.1 definitions are joined on one line. Apart from a major
decrease in readability, this in fact might be wrong in ASN.1.
The RFC says:
Hash ::= OCTET STRING IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
It should say:
Hash ::= OCTET STRING
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
(Note: I have indented the original/replacement RFC text by 3 columns
to make it better distinguishable in this context.)
It should say:
See above.
Notes:
See above.
Errata ID: 2365
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-29
Section 6 says:
The first paragraph of Section 6, on page 8, says: (Note: This section does not present new material. This section | contains the original contents of Section 5.4 in [ESS], which are retained with minor changes in this specification to achieve backwards compatibility.) The section number given therein is wrong; it should be 5.4.1 : (Note: This section does not present new material. This section | contains the original contents of Section 5.4.1 in [ESS], which are retained with minor changes in this specification to achieve backwards compatibility.)
It should say:
See above.
Notes:
See above.
Errata ID: 2366
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2007-09-09
Held for Document Update by: Tim Polk
Date Held: 2010-07-29
Section 6 says:
On top of page 7, Section 6 of RFC 5035 says:
The fields of ESSCertID are defined as follows:
certHash
| is computed over the entire DER-encoded certificate (including the
| signature).
[...]
This is the counterpart to the issue explained in errata 2634.
In the original Cert ID (v1) described here, the signature algorithm
is fixed and should be specified explicitely as SHA-1 in the
description of the certHash field :
certHash
| is computed over the entire DER-encoded certificate (including the
| signature), using the SHA-1 algorithm.
^^^^^^^^^^^^^^^^^^^^^^^^^^^
It should say:
See above.
Notes:
See above.
Status: Rejected (2)
RFC 5035, "Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility", August 2007
Source of RFC: smime (sec)
Errata ID: 1480
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Kurt Zeilenga
Date Reported: 2008-07-30
Rejected by: Sean Turner
Date Rejected: 2010-04-20
Section Appendix A says:
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type
}
It should say:
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] EXPLICIT ANY DEFINED BY type
}
Notes:
The RFC incorporates a bad ASN.1 construction from X.411. This construction was corrected in X.501 documents (see 2005). The tag on the value must be EXPLICIT otherwise it will be replaced by whatever tag the type used in the ANY calls for.
--VERIFIER NOTES--
An implicit tagged followed by an open type is converted to an explicit tag followed by an open type by the compiler.
Errata ID: 6735
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ernst Lawende
Date Reported: 2021-11-12
Rejected by: RFC Editor
Section 4 says:
ESSCertIDv2 ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier
DEFAULT {algorithm id-sha256},
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
It should say:
ESSCertIDv2 ::= SEQUENCE {
hashAlgorithm AlgorithmIdentifier
DEFAULT {id-sha256},
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
Notes:
No value assignment for 'algorithm' exists, and the definition of id-sha256 already contains the full object identifier.
--VERIFIER NOTES--
Errata rejected per request from Russ Housley