RFC Errata
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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.