RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 16 records.

Status: Verified (1)

RFC 4211, "Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)", September 2005

Source of RFC: pkix (sec)

Errata ID: 4797

Status: Verified
Type: Editorial

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

Source of RFC: pkix (sec)

Errata ID: 166

Status: Held for Document Update
Type: Technical

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Source of RFC: pkix (sec)

Errata ID: 798

Status: Rejected
Type: Editorial

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.

Report New Errata



Search RFCs
Advanced Search
×