RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 12 records.

Status: Verified (5)

RFC 4683, "Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)", October 2006

Source of RFC: pkix (sec)

Errata ID: 1047

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Verifier Name: Sean Turner
Date Verified: 2010-07-29

Section A says:


It should say:

id-pkip
 FROM PKIXCRMF-2005
  { iso(1) identified-organization(3) dod(6) internet(1) security(5)
    mechanisms(5) pkix(7) id-mod(0) id-mod-crmf2005(36) }

Notes:

As exposed in Errata 2359 above, the OID 'id-pkip' used on page 19
needs to be IMPORTed from the PKIXCRMF-2005 ASN.1 module in
Appendix B of RFC 4211 -- otherwise the PKIXSIM ASN.1 module
in Appendix A of RFC 4683 will not compile.

Errata ID: 2362

Status: Verified
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Verifier Name: Sean Turner
Date Verified: 2010-07-29

Section A says:

The change exposed in Errata 2358 has to be applied to the
collected ASN.1 as well.

Errata ID: 2358

Status: Verified
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Verifier Name: Sean Turner
Date Verified: 2010-07-29

Section 5.1 says:

The ASN.1 at the bottom of page 11 says:

        SIM ::= SEQUENCE {
            hashAlg          AlgorithmIdentifier,
            authorityRandom  OCTET STRING,   -- RA-chosen random number
                                             -- used in computation of
                                             -- pEPSI
|           pEPSI            OCTET STRING    -- hash of HashContent
                                             -- with algorithm hashAlg
        }

It should say:

        SIM ::= SEQUENCE {
            hashAlg          AlgorithmIdentifier,
            authorityRandom  OCTET STRING,   -- RA-chosen random number
                                             -- used in computation of
                                             -- pEPSI
|           pEPSI            OCTET STRING    -- hash of hash of
|                                            -- HashContent with
                                             -- algorithm hashAlg
        }

It should say:

See above.

Notes:

Rationale:
PEPSI is an iterated hash; see Section 4.4 where the last
line on page 9 says,
where PEPSI = H(H(P || R || SIItype || SII))
-----------------v-------
and Section 5.2 for the definition of HashContent.

Errata ID: 2359

Status: Verified
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Verifier Name: Sean Turner
Date Verified: 2010-07-29

Section 5.3 says:

At the bottom of page 12, Section 5.3 says:

   id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 }

For instance, a note should be added at the bottom of page 12:

   id-regEPEPSI OBJECT IDENTIFIER ::= { id-pkip 3 }
|
|  where id-pkip is defined in [RFC4211].

It should say:

See above.

Notes:

The OID, 'id-pkip' is neither defined within RFC 4683 nor imported.
Eventually, I found it being defined in RFC 4211.
That should be made explicit in Section 5.3 of RFC 4683 !

Errata ID: 2355

Status: Verified
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Verifier Name: Sean Turner
Date Verified: 2010-07-29

Section 4.4 says:

On page 10, the second-to-last paragraph of Section 4.4 says:

   Note that a secure communication channel MUST be used to pass P and
|  SII passing from the end entity to the RA, to protect them from
   disclosure or modification.

It should say:

   Note that a secure communication channel MUST be used to pass P and
|  SII from the end entity to the RA, to protect them from disclosure or
   modification.

It should say:

See above.

Status: Held for Document Update (7)

RFC 4683, "Internet X.509 Public Key Infrastructure Subject Identification Method (SIM)", October 2006

Source of RFC: pkix (sec)

Errata ID: 2356

Status: Held for Document Update
Type: Technical

Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 4.5 says:

Still on page 10, Section 4.5 has two instances of a missing article.

(4a)
The 1st paragraph of Section 4.5 says:

   It may be required that the CA (not just the RA) verifies SII before
|  issuing a certificate.  To meet this requirement, RA SHOULD encrypt
   the SIItype, SII, and SIM and send the result to the CA by a secure
   channel.  The user SHOULD also encrypt the same values and send the
   result to the CA in his or her certificate request message.  Then the
   CA compares these two results for verifying the user's SII.

It should say:

   It may be required that the CA (not just the RA) verifies SII before
|  issuing a certificate.  To meet this requirement, the RA SHOULD
   encrypt the SIItype, SII, and SIM and send the result to the CA by a
   secure channel.  The user SHOULD also encrypt the same values and
   send the result to the CA in his or her certificate request message.
   Then the CA compares these two results for verifying the user's SII.

(4b)
The 2nd paragraph of Section 4.5 says:

|  Where the results from RA and the user are the EPEPSI.

It should say:

|  Where the results from the RA and the user are the EPEPSI.

It should say:

See above.

Errata ID: 2361

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-21

Section 11.2 says:

The first entry in Section 11.2 (at the bottom of page 15) says:

   [LDAPBIS STRPREP] Zeilenga, K., "LDAP: Internationalized String
                     Preparation", Work in Progress.

It should say:

See below.

Notes:

Apparently, this should have been replaced by the proper quotation
for RFC 4518 from rfc-ref.txt.

Rationale: RFC 4518 has been published four months before RFC 4683!

Errata ID: 2363

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-21

Section A says:

Near the bottom of page 18, the RFC says:

|      -- The content of this type conforms to RFC 2279
                                               ^^^^^^^^
It should say:

|      -- The content of this type conforms to STD 63, RFC 3629

It should say:

See above.

Errata ID: 2353

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-20

Section 2 says:

On page 6 of RFC 4683, I found two typos:

(1a)
The first sentence,

|  The following cryptography symbols are defined in this document.
                            ^
should say:

|  The following cryptographic symbols are defined in this document.
                            ^^
(1b)
The 6th entry,

       PEPSI      Privacy-Enhanced Protected Subject Information.
                  Calculated from the input value P, R, SIItype, SII
|                 using two iteration of H().
                                    ^
should say:

       PEPSI      Privacy-Enhanced Protected Subject Information.
                  Calculated from the input value P, R, SIItype, SII
|                 using two iterations of H().
                                    ^^

It should say:

See above.

Errata ID: 2354

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-21

Section 4.2 says:

The first paragraph of Section 4.2, on page 9 of RFC 4683 says:

   The user selects a password as one of the input values for computing
   the SIM.  The strength of the password is critical to protection of
|  the user's SII, in the following sense.  If an attacker has a
|  candidate SII value, and wants to determine whether the SIM value in
|  a specific subject certificate, P is the only protection for the SIM.
   [...]

The marked (3rd) sentence does not parse; apparently something is
missing, or the word "whether" has to be deleted, as follows:

                                    [...].  If an attacker has a
|  candidate SII value, and wants to determine the SIM value in a
   specific subject certificate, P is the only protection for the SIM.
   [...]

It should say:

See above.

Errata ID: 2360

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-21

Section 8 says:

The 3rd paragraph of RFC 4683 says:

   This protocol assumes that Bob is a trustworthy relying party who
|  will not reuse the Alice's information.  [...]
                  ^^^^
It should say:

   This protocol assumes that Bob is a trustworthy relying party who
|  will not reuse Alice's information.  [...]

It should say:

See above.

Errata ID: 2357

Status: Held for Document Update
Type: Editorial

Reported By: Alfred Hoenes
Date Reported: 2007-09-18
Held for Document Update by: Sean Turner
Date Held: 2010-07-21

Section 5.1 says:

The first paragraph of Section 5.1 (on mid-page 11) says:

   This section specifies the syntax for the SIM name form included in
|  the subjectAltName extension.  The SIM is composed of the three
   fields:  the hash algorithm identifier, the authority-chosen random
   value, and the value of the PEPSI itself.

It should say:

   This section specifies the syntax for the SIM name form included in
|  the subjectAltName extension.  The SIM is composed of three fields:
   the hash algorithm identifier, the authority-chosen random value, and
   the value of the PEPSI itself.

It should say:

See above.

Report New Errata