RFC Errata
Found 6 records.
Status: Verified (4)
RFC 3779, "X.509 Extensions for IP Addresses and AS Identifiers", June 2004
Source of RFC: pkix (sec)
Errata ID: 2537
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jim Schaad
Date Reported: 2010-09-30
Verifier Name: Sean Turner
Date Verified: 2011-02-23
Section 2.2.3.9 says:
To simplify the comparison of IP address blocks when performing certification path validation, a maximum IP address MUST contain at least one bit whose value is 1, i.e., the subsequent octets may not be omitted nor all zero.
It should say:
Text should be deleted.
Notes:
There are a number of different issues relative to this text that need to be addressed.
1. This text implicitly change the rules for encoding a maximum value. As an example the address 0.0.0.255 is encoded as 03 03 00 00 00 00 according to the rule " The BIT STRING for the maximum address results from removing all the least-significant one-bits from the maximum address."
2. The rule in no way simplifies any comparisions of IP address blocks. If one really wishes to simplify the comparison then one needs to change the rule for maximum addresses to remove all but the last least-signficant one-bit from the address. However it is not clear that even this would really simplify the comparison in any significant way.
If you look at the example in 2.2.3.9 - tis is not clear how having the one bit at the top of the encoding helps make the comparisons any easier - but it satisfies the requirment that atleast one bit is a 1. If the maximum value ws encoded as 1000 1 (0x3 0x02 0x03 0x84) - a bitwise comparision routine could make for a simplified a < b comparison (looking at only the top 5 bits of the address to be compared.)
Errata ID: 6792
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Theo Buehler
Date Reported: 2021-12-21
Verifier Name: Benjamin Kaduk
Date Verified: 2021-12-25
Section Appendix B says:
30 3d Extension {
06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7
01 01 ff critical
04 2e extnValue {
30 2c IPAddrBlocks {
30 10 IPAddressFamily {
04 03 0001 01 addressFamily: IPv4 Unicast
IPAddressChoice
30 09 addressesOrRanges {
IPAddressOrRange
03 02 00 0a addressPrefix 10/8
IPAddressOrRange
03 03 04 b010 addressPrefix 172.16/12
} -- addressesOrRanges
} -- IPAddressFamily
30 07 IPAddressFamily {
04 03 0001 02 addressFamily: IPv4 Multicast
IPAddressChoice
05 00 inherit from issuer
} -- IPAddressFamily
30 0f IPAddressFamily {
04 02 0002 addressFamily: IPv6
IPAddressChoice
30 09 addressesOrRanges {
IPAddressOrRange
03 07 00 200100000002 addressPrefix 2001:0:2/47
} -- addressesOrRanges
} -- IPAddressFamily
} -- IPAddrBlocks
} -- extnValue
} -- Extension
It should say:
30 3d Extension {
06 08 2b06010505070107 extnID 1.3.6.1.5.5.7.1.7
01 01 ff critical
04 2e extnValue {
30 2c IPAddrBlocks {
30 10 IPAddressFamily {
04 03 0001 01 addressFamily: IPv4 Unicast
IPAddressChoice
30 09 addressesOrRanges {
IPAddressOrRange
03 02 00 0a addressPrefix 10/8
IPAddressOrRange
03 03 04 ac10 addressPrefix 172.16/12
} -- addressesOrRanges
} -- IPAddressFamily
30 07 IPAddressFamily {
04 03 0001 02 addressFamily: IPv4 Multicast
IPAddressChoice
05 00 inherit from issuer
} -- IPAddressFamily
30 0f IPAddressFamily {
04 02 0002 addressFamily: IPv6
IPAddressChoice
30 09 addressesOrRanges {
IPAddressOrRange
03 07 00 200100000002 addressPrefix 2001:0:2/48
} -- addressesOrRanges
} -- IPAddressFamily
} -- IPAddrBlocks
} -- extnValue
} -- Extension
Notes:
b010 represents 176.16/12, the hex representation of 172 is ac, so it should be ac10.
The IPv6 addressPrefix in question is 2001:0:2/48, not 2001:0:2/47, as explained in the text before the example.
Errata ID: 836
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Randy Bush
Date Reported: 2006-06-21
Section 3.2.3.1 says:
The ASIdentifiers type is a SEQUENCE containing one or more forms of autonomous system identifiers -- AS numbers (in the asnum element) or routing domain identifiers (in the rdi element). When the ASIdentifiers type contains multiple forms of identifiers, the asnum entry MUST precede the rdi entry. AS numbers are used by BGP, and routing domain identifiers are specified in the IDRP [RFC1142].
It should say:
[see Notes]
Notes:
IDRP was never defined in an RFC, only by ISO 10747.
from pending
Errata ID: 1886
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Charles Bobo
Date Reported: 2009-09-21
Verifier Name: Sean Turner
Date Verified: 2010-04-19
Section 2.1.1 says:
An IPv6 address is a 128-bit quantity that is written as eight
hexadecimal numbers, each in the range 0 through ffff, separated by a
semicolon (":"); 2001:0:200:3:0:0:0:1 is an example of an IPv6
address. IPv6 addresses frequently have adjacent fields whose value
is 0. One such group of 0 fields may be abbreviated by two
semicolons ("::").
It should say:
An IPv6 address is a 128-bit quantity that is written as eight
hexadecimal numbers, each in the range 0 through ffff, separated by a
colon (":"); 2001:0:200:3:0:0:0:1 is an example of an IPv6 address.
IPv6 addresses frequently have adjacent fields whose value is 0. One
such group of 0 fields may be abbreviated by two colons ("::").
Notes:
"semicolon" should be "colon"
Added reference to RFC4291.
Verifier: Forward reference to RFC4291 is inappropriate.
Status: Held for Document Update (2)
RFC 3779, "X.509 Extensions for IP Addresses and AS Identifiers", June 2004
Source of RFC: pkix (sec)
Errata ID: 7653
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Job Snijders
Date Reported: 2023-09-22
Held for Document Update by: Paul Wouters
Date Held: 2024-01-12
Section 3.2.3 says:
Section 3.2.3.8: The ASRange type is a SEQUENCE consisting of a min and a max element, and is used to specify a range of AS identifier values.
It should say:
Section 3.2.3.8: The ASRange type is a SEQUENCE consisting of a min and a max element, and is used to specify a range of AS identifier values. The min and max elements MUST specify two distinct AS identifiers.
Notes:
The introduction in section 1 stresses that the objective of the encoding rules in section 2 and section 3
is to produce unique encoding and minimal size encoding of the information.
Allowing ASRanges where the minimum value is the same as the maximum value clearly violates the
objective of specifying a canonical form (in order to produce a unique representation); however the
specification as-is doesn't forbid min & max to be the same value. The corrected text addresses this.
Note: erratum edited per https://mailarchive.ietf.org/arch/msg/pkix/iZnCd58xgl1C47GSeFemAU9CF1g/
Errata ID: 1887
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Charles Bobo
Date Reported: 2009-09-21
Held for Document Update by: Tim Polk
Section References says:
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April
2002.
[S-BGP] S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway
Protocol (S-BGP)," IEEE JSAC Special Issue on Network
Security, April 2000.
It should say:
[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April
2002.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC4291] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture",
RFC 4291, February 2006
[S-BGP] S. Kent, C. Lynn, and K. Seo, "Secure Border Gateway
Protocol (S-BGP)," IEEE JSAC Special Issue on Network
Security, April 2000.
Notes:
Section is "Informational References" but this doesn't fit in the Section field above.
References were out of alphabetical order -- RFC3281 should come before RFC3513.
Added reference RFC4291