RFC Errata
Found 16 records.
Status: Verified (1)
RFC 4211, "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", September 2005
Note: This RFC has been updated by RFC 9045
Source of RFC: pkix (sec)
Errata ID: 4797
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lijun Liao
Date Reported: 2016-09-08
Verifier Name: Stephen Farrell
Date Verified: 2016-09-13
Section 4.1 says:
3. The certificate subject places its name in the Certificate
Template structure along with the public key. In this case the
poposkInput field is omitted from the POPOSigningKey structure.
The signature field is computed over the DER-encoded certificate
template structure.
It should say:
3. The certificate subject places its name in the Certificate
Template structure along with the public key. In this case the
poposkInput field is omitted from the POPOSigningKey structure.
The signature field is computed over the DER-encoded value of
certReq
Notes:
The original text conflicts with the following text block (just several lines later).
" The fields of POPOSigningKey have the following meaning:
...
signature contains the POP value produce. If poposkInput is
present, the signature is computed over the DER-encoded value of
poposkInput. If poposkInput is absent, the signature is computed
over the DER-encoded value of certReq."
Status: Held for Document Update (14)
RFC 4211, "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", September 2005
Note: This RFC has been updated by RFC 9045
Source of RFC: pkix (sec)
Errata ID: 166
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Section 4.1 says:
algorithmIdentifier identifiers the signature algorithm and an
associated parameters used to produce the POP value.
signature contains the POP value produce.
It should say:
algorithmIdentifier identifies the signature algorithm and
associated parameters used to produce the POP value.
signature contains the POP value produced
Notes:
Errata ID: 2339
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
Section B says:
Near the middle of page 32, contains the following [commented out] ASN.1, and ASN.1 comment:
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The contents of this type correspond to RFC 2279.
^^^^
The RFC should say:
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The contents of this type correspond to RFC 3629.
It should say:
[see above]
Notes:
RFC 2279 has been obsoleted by RFC 3629 == STD 63 "long" ago.
I am aware of the fact that the UTF-8 definition in RFC 3629
syntactically and semantically by intention is a proper subset
of the definition in RFC 2279 (restriction to possible Unicode
codepoints with up to 24-bit representation).
Thus, it might be true that the reference to RFC 2279 has been
used intentionally in this ASN.1 comment, e.g., because RFC 3280
[PROFILE] (pre-3629!) referred to RFC 2279 in that context.
But, regarding the STD status of RFC 3629, a standards track RFC
like RFC 4211 should, in this case, present explicit arguments
for the deviation from STD 63. (It doesn't.)
Errata ID: 2347
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
Section 7.1 says:
Subsequently, near the top of page 24, the same section says:
vvvvvvvvv
The %xx mechanism of [RFC1738] is used to encode '?' (%3f) and '%'
(%25) if they are not being used for their reserved purpose. Names
MUST NOT start with a numeric character.
It should better say:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
The %xx mechanism of Section 2.1 of STD 66 [RFC3986] is used to
encode '?' (%3f) and '%' (%25) if they are not being used for their
reserved purpose. Names MUST NOT start with a numeric character.
It should say:
[see above]
Notes:
Rationale: RFC 1738 has been obsoleted; the %-escaping method is now covered by the above mentioned section of that Internet Standard.
Errata ID: 2349
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Tim Polk
Date Held: 2010-07-20
Section 10.2 says:
On page 27, contains the following Ref. as its final entry:
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
It should say:
[see above]
Notes:
According to Errata 2348, this should be removed, and a new Ref.
[RFC3986] added -- to be taken from rfc-ref.txt .
Given the nature and context of the use of this Ref. in section 7.1
-- see item (11) above -- and the STD Status of RFC 3986, then
perhaps it is advisable to place this new Ref. into Section 10.1,
Normative References, not in section 10.2, Informative References.
Errata ID: 2340
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-29
Section 4.2.1 says:
In the last paragraph on page 11 says:
identifier contains a name that the CA/RA can associate with the
requestor. This will generally be either the DN of a certificate
or a text token passed and known to both the requestor and the
CA/RA. ...
It should say:
identifier contains a name that the CA/RA can associate with the requestor. This will generally be either a portion of either a subject name or subject alternative name (either from an existing certificate or from the certificate request) or a text token passed and known to both the requestor and the CA/RA.
Notes:
The location of the DN material will vary based on the question of whether
this is an archive operator or a POP operation.
Errata ID: 2342
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 4.4 says:
In the first text line on page 15, says:
The fields of PEMParameter have the following meaning:
^
It should say:
v
The fields of PBMParameter have the following meaning:
It should say:
[see above]
Notes:
Rationale: an OCR problem???
Changed to editorial.
Errata ID: 2341
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 4.4 says:
The ASN.1 fragment at the bottom of page 14, says:
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
iterationCount INTEGER,
mac AlgorithmIdentifier
)
^^^
It should say:
PBMParameter ::= SEQUENCE {
salt OCTET STRING,
owf AlgorithmIdentifier,
iterationCount INTEGER,
mac AlgorithmIdentifier
}
It should say:
[see above]
Errata ID: 2343
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 6.1 says:
In the first paragraph on page 19, refers to a wrong subsection; it says:
The regToken control is used only for initialization of an end entity
into the PKI, whereas the authenticator control (see section 7.2) can
^
be used for the initial as well as subsequent certification requests.
It should say:
The regToken control is used only for initialization of an end entity
into the PKI, whereas the authenticator control (see section 6.2) can
be used for the initial as well as subsequent certification requests.
It should say:
[see above]
Notes:
Changed to editorial.
Errata ID: 2344
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 6.3 says:
In the upper half of page 20, says:
The fields of PKIPublicationInfo have the following meaning:
action indicates whether or not the requestor wishes the CA/RA to
publish the certificate. The values and their means are:
^^
It should say:
The fields of PKIPublicationInfo have the following meaning:
action indicates whether or not the requestor wishes the CA/RA to
publish the certificate. The values and their meanings are:
It should say:
[see above]
Notes:
Changed to editorial.
Errata ID: 2345
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Tim Polk
Date Held: 2010-07-29
Section 6.3 says:
At the bottom of page 20, says:
The fields of SinglePubInfo have the following meaning:
pubMethod indicates the address type for the location at which the
requestor desires the certificate to be placed by the CA/RA.
dontCare indicates that the CA/RA can publish the certificate
in whatever locations it chooses. If dontCare is used, the
pubInfos field MUST be omitted.
^^^^^
(To make the full context visible, I have shown more text than
would be necessary for the errata note.)
>From the context, I strongly suspect that the RFC text should say:
The fields of SinglePubInfo have the following meaning:
pubMethod indicates the address type for the location at which the
requestor desires the certificate to be placed by the CA/RA.
dontCare indicates that the CA/RA can publish the certificate
in whatever locations it chooses. If dontCare is used, the
pubLocation field MUST be omitted.
^^^^^^^^
It should say:
[see above]
Notes:
Rationale: pubInfos is a "SEQUENCE SIZE (1..MAX) OF SinglePubInfo".
I cannot imagine how a certain value of a SinglePubInfo instance
subfield can ever imply a MUST to omit the full enclosing structure,
pubInfos -- which would have removed this subfield as well :-) .
Perhaps, the text has been cloned from the explanation of the
'dontPublish' value of the PKIPublicationInfo.action filed given
just below the text excerpt reproduced under item (7) above
without fully applying the proper changes.
Errata ID: 2346
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 6.4 says:
At the bottom of page 22, says:
The fields of EncryptedKey have the following meaning:
encryptedValue is longer used. This field has been deprecated
along with the EncryptedValue structure.
It should say:
The fields of EncryptedKey have the following meaning:
vvvv
encryptedValue is no longer used. This field has been
deprecated along with the EncryptedValue structure.
It should say:
[see above]
Notes:
Changed to editorial.
Errata ID: 2348
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-20
Section 9 says:
In the first paragraph on page 26, contains the sentence:
... The user can
claim that an item was signed by the entity that generated the key as
well as any entity that might have seen the key value during transfer
from the generator the to EE. ...
^^^^^^
It should say:
... The user can
claim that an item was signed by the entity that generated the key as
well as any entity that might have seen the key value during transfer
from the generator to the EE. ...
^^^^^^
It should say:
[see above]
Notes:
Changed to editorial.
Errata ID: 2350
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Held for Document Update by: Sean Turner
Date Held: 2010-07-29
Section A.2 says:
In the last ASN.1 fragment on page 31, says:
IP address (identifier "I"):
<iname> ::= <oid>
^^^^^
It should say:
[see above]
Notes:
The text should clarify what is meant by <oid> which is not defined in this
document nor is it a standard BNF item. It should be considered if a BNF
reference should be added. It should be made clearer what the different
terminals mean.
Errata ID: 2595
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2010-10-29
Held for Document Update by: Sean Turner
Section 2.1 says:
7. Replaced Appendix A with a reference to [RFC2875]. The only
difference is that the old text specified to use subject alt name
instead of subject name if subject name was empty. This is not
possible for a CA certificate issued using PKIX. It would
however be useful to update RFC 2875 to have this fallback
position.
7. Insert Appendix C describing why POP is necessary and what some
of the different POP attacks are.
8. pop field in the CertReqMsg structure has been renamed to popo to
avoid confusion between POP and pop.
9. The use of the EncryptedValue structure has been deprecated in
favor of the EnvelopedData structure.
10. Add details on how private keys are to be structured when
encrypted.
11. Allow for POP on key agreement algorithms other than DH.
It should say:
7. Replaced Appendix A with a reference to [RFC2875]. The only
difference is that the old text specified to use subject alt name
instead of subject name if subject name was empty. This is not
possible for a CA certificate issued using PKIX. It would
however be useful to update RFC 2875 to have this fallback
position.
8. Insert Appendix C describing why POP is necessary and what some
of the different POP attacks are.
9. pop field in the CertReqMsg structure has been renamed to popo to
avoid confusion between POP and pop.
10. The use of the EncryptedValue structure has been deprecated in
favor of the EnvelopedData structure.
11. Add details on how private keys are to be structured when
encrypted.
12. Allow for POP on key agreement algorithms other than DH.
Notes:
Item 7 erroneously repeated.
Status: Rejected (1)
RFC 4211, "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", September 2005
Note: This RFC has been updated by RFC 9045
Source of RFC: pkix (sec)
Errata ID: 798
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2005-11-08
Rejected by: Sean Turner
Date Rejected: 2010-07-29
Section 4.2 says:
Key Encipherment Keys, in the lower part of page 10, in the two (doubly indented) paragraphs explaining the components of 'agreeMAC', uses improper names for these components -- cf. the ASN.1 syntax for PKMACValue at the top of page 9. The RFC says:
vvvvvv
macAlg contains the algorithm identifying the method used to
compute the MAC value.
macValue contains the computed MAC value.
^^^^^^^^
It should say (I propose to make use of hierarchical subfield
notation):
agreeMAC.algID contains the algorithm identifying the method
used to compute the MAC value.
agreeMAC.value contains the computed MAC value.
It should say:
[see above]
Notes:
--VERIFIER NOTES--
The implication of doing the second level of indentation indicates that
these fields are in the type referenced by the agreeMac field. Note that the same thing occurs just above for subsequentMessage. The type definition occurred in the previous section 4.1.