rfc9374v4.txt		rfc9374.txt
	skipping to change at line 128 ¶		skipping to change at line 128 ¶
	spoofable (ID-5), and identify a registry where the ID is listed		spoofable (ID-5), and identify a registry where the ID is listed
	(ID-2); all within a 19-character identifier (ID-1).		(ID-2); all within a 19-character identifier (ID-1).
	This RFC is a foundational document of DRIP, as it describes the use		This RFC is a foundational document of DRIP, as it describes the use
	of Hierarchical Host Identity Tags (HHITs) (Section 3) as self-		of Hierarchical Host Identity Tags (HHITs) (Section 3) as self-
	asserting IPv6 addresses and thereby a trustable identifier for use		asserting IPv6 addresses and thereby a trustable identifier for use
	as the UAS Remote ID (see Section 3 of [DRIP-ARCH]). All other DRIP-		as the UAS Remote ID (see Section 3 of [DRIP-ARCH]). All other DRIP-
	related technologies will enable or use HHITs as multipurpose remote		related technologies will enable or use HHITs as multipurpose remote
	identifiers. HHITs add explicit hierarchy to the 128-bit HITs,		identifiers. HHITs add explicit hierarchy to the 128-bit HITs,
	enabling DNS HHIT queries (Host ID for authentication, e.g.,		enabling DNS HHIT queries (Host ID for authentication, e.g.,
	[DRIP-AUTH]) and use with a Differentiated Access Control (e.g.		[DRIP-AUTH]) and use with a Differentiated Access Control (e.g.,
	Registration Data Access Protocol (RDAP) [RFC9224]) for 3rd-party		Registration Data Access Protocol (RDAP) [RFC9224]) for 3rd-party
	identification endorsement (e.g., [DRIP-AUTH]).		identification endorsement (e.g., [DRIP-AUTH]).
	The addition of hierarchy to HITs is an extension to [RFC7401] and		The addition of hierarchy to HITs is an extension to [RFC7401] and
	requires an update to [RFC7343]. As this document also adds EdDSA		requires an update to [RFC7343]. As this document also adds EdDSA
	(Section 3.4) for Host Identities (HIs), a number of Host Identity		(Section 3.4) for Host Identities (HIs), a number of Host Identity
	Protocol (HIP) parameters in [RFC7401] are updated, but these should		Protocol (HIP) parameters in [RFC7401] are updated, but these should
	not be needed in a DRIP implementation that does not use HIP.		not be needed in a DRIP implementation that does not use HIP.
	HHITs as used within the context of UAS are labeled as DRIP Entity		HHITs as used within the context of UAS are labeled as DRIP Entity
	Tags (DETs). Throughout this document, HHIT and DET will be used		Tags (DETs). Throughout this document, HHIT and DET will be used
	appropriately. HHIT will be used when covering the technology, and		appropriately. HHIT will be used when covering the technology, and
	DET will be used in the context of UAS RID.		DET will be used in the context of UAS RID.
	HHITs provide self-claims of the HHIT registry. A HHIT can only be		HHITs provide self-claims of the HHIT registry. A HHIT can only be
	in a single registry within a registry system (e.g. DNS).		in a single registry within a registry system (e.g., DNS).
	HHITs are valid, though non-routable, IPv6 addresses [RFC8200]. As		HHITs are valid, though non-routable, IPv6 addresses [RFC8200]. As
	such, they fit in many ways within various IETF technologies.		such, they fit in many ways within various IETF technologies.
	1.1. HHIT Statistical Uniqueness Different from UUID or X.509 Subject		1.1. HHIT Statistical Uniqueness Different from UUID or X.509 Subject
	HHITs are statistically unique through the cryptographic hash feature		HHITs are statistically unique through the cryptographic hash feature
	of second-preimage resistance. The cryptographically bound addition		of second-preimage resistance. The cryptographically bound addition
	of the hierarchy and a HHIT registration process [DRIP-REG] provide		of the hierarchy and a HHIT registration process [DRIP-REG] provide
	complete, global HHIT uniqueness. If the HHITs cannot be looked up		complete, global HHIT uniqueness. If the HHITs cannot be looked up
	skipping to change at line 308 ¶		skipping to change at line 308 ¶
	Context IDs are allocated out of the namespace introduced for		Context IDs are allocated out of the namespace introduced for
	Cryptographically Generated Addresses (CGA) Type Tags [RFC3972].		Cryptographically Generated Addresses (CGA) Type Tags [RFC3972].
	3.1. HHIT Prefix for RID Purposes		3.1. HHIT Prefix for RID Purposes
	The IPv6 HHIT prefix MUST be distinct from that used in the flat-		The IPv6 HHIT prefix MUST be distinct from that used in the flat-
	space HIT as allocated in [RFC7343]. Without this distinct prefix,		space HIT as allocated in [RFC7343]. Without this distinct prefix,
	the first 4 bits of the RAA would be interpreted as the HIT Suite ID		the first 4 bits of the RAA would be interpreted as the HIT Suite ID
	per HIPv2 [RFC7401].		per HIPv2 [RFC7401].
	Initially, for DET use, one 28-bit prefix should be assigned out of		Initially, the IPv6 prefix listed in Table 1 is assigned for DET use.
	the IANA IPv6 Special Purpose Address Block ([RFC6890]).		It has been registered in the "IANA IPv6 Special-Purpose Address
			Registry" [RFC6890].
	+==========+======+==============+		+==========+======+==============+
	| HHIT Use | Bits | Value |		| HHIT Use | Bits | Value |
	+==========+======+==============+		+==========+======+==============+
	| DET | 28 | 2001:30::/28 |		| DET | 28 | 2001:30::/28 |
	+----------+------+--------------+		+----------+------+--------------+
	Table 1		Table 1: Initial DET IPv6 Prefix
	Other prefixes may be added in the future either for DET use or other		Other prefixes may be added in the future either for DET use or other
	applications of HHITs. For a prefix to be added to the registry in		applications of HHITs. For a prefix to be added to the registry in
	Section 8.2, its usage and HID allocation process have to be publicly		Section 8.2, its usage and HID allocation process have to be publicly
	available.		available.
	3.2. HHIT Suite IDs		3.2. HHIT Suite IDs
	The HHIT Suite IDs specify the HI and hash algorithms. These are a		The HHIT Suite IDs specify the HI and hash algorithms. These are a
	superset of the 4-bit and 8-bit HIT Suite IDs as defined in		superset of the 4-bit and 8-bit HIT Suite IDs as defined in
	skipping to change at line 356 ¶		skipping to change at line 357 ¶
	+-----------------+-------------+		+-----------------+-------------+
	| RSA,DSA/SHA-256 | 1 [RFC7401] |		| RSA,DSA/SHA-256 | 1 [RFC7401] |
	+-----------------+-------------+		+-----------------+-------------+
	| ECDSA/SHA-384 | 2 [RFC7401] |		| ECDSA/SHA-384 | 2 [RFC7401] |
	+-----------------+-------------+		+-----------------+-------------+
	| ECDSA_LOW/SHA-1 | 3 [RFC7401] |		| ECDSA_LOW/SHA-1 | 3 [RFC7401] |
	+-----------------+-------------+		+-----------------+-------------+
	| EdDSA/cSHAKE128 | 5 |		| EdDSA/cSHAKE128 | 5 |
	+-----------------+-------------+		+-----------------+-------------+
	Table 2		Table 2: Initial HHIT Suite IDs
	3.2.1. HDA Custom HIT Suite IDs		3.2.1. HDA Custom HIT Suite IDs
	Support for 8-bit HHIT Suite IDs allows for HDA custom HIT Suite IDs.		Support for 8-bit HHIT Suite IDs allows for HDA custom HIT Suite IDs
	These will be assigned values greater than 15 as follows:		(see Table 3).
	+===================+=======+		+===================+=======+
	| HHIT Suite | Value |		| HHIT Suite | Value |
	+===================+=======+		+===================+=======+
	| HDA Private Use 1 | 254 |		| HDA Private Use 1 | 254 |
	+-------------------+-------+		+-------------------+-------+
	| HDA Private Use 2 | 255 |		| HDA Private Use 2 | 255 |
	+-------------------+-------+		+-------------------+-------+
	Table 3		Table 3: HDA Custom HIT
			Suite IDs
	These custom HIT Suite IDs, for example, may be used for large-scale		These custom HIT Suite IDs, for example, may be used for large-scale
	experimentation with post-quantum computing hashes or similar domain-		experimentation with post-quantum computing hashes or similar domain-
	specific needs. Note that currently there is no support for domain-		specific needs. Note that currently there is no support for domain-
	specific HI algorithms.		specific HI algorithms.
	They should not be used to create a "de facto standardization".		They should not be used to create a "de facto standardization".
	Section 8.2 states that additional Suite IDs can be made through IETF		Section 8.2 states that additional Suite IDs can be made through IETF
	Review.		Review.
	skipping to change at line 416 ¶		skipping to change at line 418 ¶
	The RAA is a 14-bit field (16,384 RAAs). Management of this space is		The RAA is a 14-bit field (16,384 RAAs). Management of this space is
	further described in [DRIP-REG]. An RAA MUST provide a set of		further described in [DRIP-REG]. An RAA MUST provide a set of
	services to allocate HDAs to organizations. It SHOULD have a public		services to allocate HDAs to organizations. It SHOULD have a public
	policy on what is necessary to obtain an HDA. The RAA need not		policy on what is necessary to obtain an HDA. The RAA need not
	maintain any HIP-related services. At minimum, it MUST maintain a		maintain any HIP-related services. At minimum, it MUST maintain a
	DNS zone for the HDA zone delegation for discovering HIP RVS servers		DNS zone for the HDA zone delegation for discovering HIP RVS servers
	[RFC8004] for the HID. Zone delegation is covered in [DRIP-REG].		[RFC8004] for the HID. Zone delegation is covered in [DRIP-REG].
	As DETs under administrative control may be used in many different		As DETs under administrative control may be used in many different
	domains (e.g., commercial, recreation, military), RAAs should be		domains (e.g., commercial, recreation, military), RAAs should be
	allocated in blocks (e.g. 16-19) with consideration of the likely		allocated in blocks (e.g., 16-19) with consideration of the likely
	size of a particular usage. Alternatively, different prefixes can be		size of a particular usage. Alternatively, different prefixes can be
	used to separate different domains of use of HHITs.		used to separate different domains of use of HHITs.
	The RAA DNS zone within the UAS DNS tree may be a PTR for its RAA.		The RAA DNS zone within the UAS DNS tree may be a PTR for its RAA.
	It may be a zone in a HHIT-specific DNS zone. Assume that the RAA is		It may be a zone in a HHIT-specific DNS zone. Assume that the RAA is
	decimal 100. The PTR record could be constructed as follows (where		decimal 100. The PTR record could be constructed as follows (where
	20010030 is the DET prefix):		20010030 is the DET prefix):
	100.20010030.hhit.arpa. IN PTR raa.example.com.		100.20010030.hhit.arpa. IN PTR raa.example.com.
	skipping to change at line 470 ¶		skipping to change at line 472 ¶
	parameters. Other than the HIP DNS RR (Resource Record) [RFC8005],		parameters. Other than the HIP DNS RR (Resource Record) [RFC8005],
	these should not be needed in a DRIP implementation that does not use		these should not be needed in a DRIP implementation that does not use
	HIP.		HIP.
	See Section 3.2 for use of the HIT Suite in the context of DRIP.		See Section 3.2 for use of the HIT Suite in the context of DRIP.
	3.4.1. HOST_ID		3.4.1. HOST_ID
	The HOST_ID parameter specifies the public key algorithm, and for		The HOST_ID parameter specifies the public key algorithm, and for
	elliptic curves, a name. The HOST_ID parameter is defined in		elliptic curves, a name. The HOST_ID parameter is defined in
	Section 5.2.9 of [RFC7401].		Section 5.2.9 of [RFC7401]. Table 4 adds a new HI Algorithm.
	+===================+=======+===========+		+===================+=======+===========+
	| Algorithm profile | Value | Reference |		| Algorithm profile | Value | Reference |
	+===================+=======+===========+		+===================+=======+===========+
	| EdDSA | 13 | [RFC8032] |		| EdDSA | 13 | [RFC8032] |
	+-------------------+-------+-----------+		+-------------------+-------+-----------+
	Table 4		Table 4: New EdDSA Host ID
	3.4.1.1. HIP Parameter support for EdDSA		3.4.1.1. HIP Parameter support for EdDSA
	The addition of EdDSA as a HI algorithm requires a subfield in the		The addition of EdDSA as a HI algorithm requires a subfield in the
	HIP HOST_ID parameter (Section 5.2.9 of [RFC7401]) as was done for		HIP HOST_ID parameter (Section 5.2.9 of [RFC7401]) as was done for
	ECDSA when used in a HIP exchange.		ECDSA when used in a HIP exchange.
	For HIP hosts that implement EdDSA as the algorithm, the following		For HIP hosts that implement EdDSA as the algorithm, the following
	EdDSA curves are represented by the following fields:		EdDSA curves are represented by the fields in Figure 2
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| EdDSA Curve | NULL |		| EdDSA Curve | NULL |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Public Key |		| Public Key |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2		Figure 2: EdDSA Curves Fields
	EdDSA Curve: Curve label		EdDSA Curve: Curve label
	Public Key: Represented in Octet-string format [RFC8032]		Public Key: Represented in Octet-string format [RFC8032]
	For hosts that implement EdDSA as a HIP algorithm, the following		For hosts that implement EdDSA as a HIP algorithm, the following
	EdDSA curves are defined. Recommended curves are tagged accordingly:		EdDSA curves are defined. Recommended curves are tagged accordingly:
	+===========+==============+===========================+		+===========+==============+===========================+
	| Algorithm | Curve | Values |		| Algorithm | Curve | Values |
	skipping to change at line 520 ¶		skipping to change at line 522 ¶
	+-----------+--------------+---------------------------+		+-----------+--------------+---------------------------+
	| EdDSA | EdDSA25519 | 1 [RFC8032] (RECOMMENDED) |		| EdDSA | EdDSA25519 | 1 [RFC8032] (RECOMMENDED) |
	+-----------+--------------+---------------------------+		+-----------+--------------+---------------------------+
	| EdDSA | EdDSA25519ph | 2 [RFC8032] |		| EdDSA | EdDSA25519ph | 2 [RFC8032] |
	+-----------+--------------+---------------------------+		+-----------+--------------+---------------------------+
	| EdDSA | EdDSA448 | 3 [RFC8032] (RECOMMENDED) |		| EdDSA | EdDSA448 | 3 [RFC8032] (RECOMMENDED) |
	+-----------+--------------+---------------------------+		+-----------+--------------+---------------------------+
	| EdDSA | EdDSA448ph | 4 [RFC8032] |		| EdDSA | EdDSA448ph | 4 [RFC8032] |
	+-----------+--------------+---------------------------+		+-----------+--------------+---------------------------+
	Table 5		Table 5: EdDSA Curves
	3.4.1.2. HIP DNS RR support for EdDSA		3.4.1.2. HIP DNS RR support for EdDSA
	The HIP DNS RR is defined in [RFC8005]. It uses the values defined		The HIP DNS RR is defined in [RFC8005]. It uses the values defined
	for the 'Algorithm Type' of the IPSECKEY RR [RFC4025] for its PK		for the 'Algorithm Type' of the IPSECKEY RR [RFC4025] for its PK
	Algorithm field.		Algorithm field.
	The 'Algorithm Type' value and EdDSA HI encoding are assigned per		The 'Algorithm Type' value and EdDSA HI encoding are assigned per
	[RFC9373].		[RFC9373].
	skipping to change at line 547 ¶		skipping to change at line 549 ¶
	Section 5.2.10 of [RFC7401].		Section 5.2.10 of [RFC7401].
	The following HIT Suite ID is defined:		The following HIT Suite ID is defined:
	+=================+=======+		+=================+=======+
	| HIT Suite | Value |		| HIT Suite | Value |
	+=================+=======+		+=================+=======+
	| EdDSA/cSHAKE128 | 5 |		| EdDSA/cSHAKE128 | 5 |
	+-----------------+-------+		+-----------------+-------+
	Table 6		Table 6: HIT Suite ID
	Table 7 provides more detail on the above HIT Suite combination.		Table 7 provides more detail on the above HIT Suite combination.
	The output of cSHAKE128 is variable per the needs of a specific		The output of cSHAKE128 is variable per the needs of a specific
	ORCHID construction. It is at most 96 bits long and is directly used		ORCHID construction. It is at most 96 bits long and is directly used
	in the ORCHID (without truncation).		in the ORCHID (without truncation).
	+=======+===========+=========+===========+====================+		+=======+===========+=========+===========+====================+
	| Index | Hash | HMAC | Signature | Description |		| Index | Hash | HMAC | Signature | Description |
	| | function | | algorithm | |		| | function | | algorithm | |
	skipping to change at line 1032 ¶		skipping to change at line 1034 ¶
	[RFC6890]. Future additions to this subregistry are to be made		[RFC6890]. Future additions to this subregistry are to be made
	through Expert Review (Section 4.5 of [RFC8126]). Entries with		through Expert Review (Section 4.5 of [RFC8126]). Entries with
	network-specific prefixes may be present in the registry.		network-specific prefixes may be present in the registry.
	+==========+======+==============+===========+		+==========+======+==============+===========+
	| HHIT Use | Bits | Value | Reference |		| HHIT Use | Bits | Value | Reference |
	+==========+======+==============+===========+		+==========+======+==============+===========+
	| DET | 28 | 2001:30::/28 | RFC 9374 |		| DET | 28 | 2001:30::/28 | RFC 9374 |
	+----------+------+--------------+-----------+		+----------+------+--------------+-----------+
	Table 8		Table 8: Registered DET IPv6 Prefix
	Criteria that should be applied by the designated experts includes		Criteria that should be applied by the designated experts includes
	determining whether the proposed registration duplicates existing		determining whether the proposed registration duplicates existing
	functionality and whether the registration description is clear and		functionality and whether the registration description is clear and
	fits the purpose of this registry.		fits the purpose of this registry.
	Registration requests MUST be sent to drip-reg-review@ietf.org and be		Registration requests MUST be sent to drip-reg-review@ietf.org and be
	evaluated within a three-week review period on the advice of one or		evaluated within a three-week review period on the advice of one or
	more designated experts. Within that review period, the designated		more designated experts. Within that review period, the designated
	experts will either approve or deny the registration request, and		experts will either approve or deny the registration request, and
	skipping to change at line 1076 ¶		skipping to change at line 1078 ¶
	+-------------------+-------+-----------+		+-------------------+-------+-----------+
	| ECDSA_LOW/SHA-1 | 3 | [RFC7401] |		| ECDSA_LOW/SHA-1 | 3 | [RFC7401] |
	+-------------------+-------+-----------+		+-------------------+-------+-----------+
	| EdDSA/cSHAKE128 | 5 | RFC 9374 |		| EdDSA/cSHAKE128 | 5 | RFC 9374 |
	+-------------------+-------+-----------+		+-------------------+-------+-----------+
	| HDA Private Use 1 | 254 | RFC 9374 |		| HDA Private Use 1 | 254 | RFC 9374 |
	+-------------------+-------+-----------+		+-------------------+-------+-----------+
	| HDA Private Use 2 | 255 | RFC 9374 |		| HDA Private Use 2 | 255 | RFC 9374 |
	+-------------------+-------+-----------+		+-------------------+-------+-----------+
	Table 9		Table 9: Registered HHIT Suite IDs
	The HHIT Suite ID values 1 - 31 are reserved for IDs that MUST be		The HHIT Suite ID values 1 - 31 are reserved for IDs that MUST be
	replicated as HIT Suite IDs (Section 8.4) as is 5 here. Higher		replicated as HIT Suite IDs (Section 8.4) as is 5 here. Higher
	values (32 - 255) are for those Suite IDs that need not or cannot be		values (32 - 255) are for those Suite IDs that need not or cannot be
	accommodated as a HIT Suite ID.		accommodated as a HIT Suite ID.
	8.3. IANA CGA Registry Update		8.3. IANA CGA Registry Update
	This document has been added as a reference for the "CGA Extension		This document has been added as a reference for the "CGA Extension
	Type Tags" registry [IANA-CGA]. IANA has the following Context ID in		Type Tags" registry [IANA-CGA]. IANA has the following Context ID in
	skipping to change at line 1118 ¶		skipping to change at line 1120 ¶
	This document defines the new EdDSA Host ID with value 13		This document defines the new EdDSA Host ID with value 13
	(Section 3.4.1) in the "HI Algorithm" subregistry of the "Host		(Section 3.4.1) in the "HI Algorithm" subregistry of the "Host
	Identity Protocol (HIP) Parameters" registry.		Identity Protocol (HIP) Parameters" registry.
	+===================+=======+===========+		+===================+=======+===========+
	| Algorithm Profile | Value | Reference |		| Algorithm Profile | Value | Reference |
	+===================+=======+===========+		+===================+=======+===========+
	| EdDSA | 13 | [RFC8032] |		| EdDSA | 13 | [RFC8032] |
	+-------------------+-------+-----------+		+-------------------+-------+-----------+
	Table 11		Table 11: Registered HI Algorithm
	EdDSA Curve Label:		EdDSA Curve Label:
	This document specifies a new algorithm-specific subregistry named		This document specifies a new algorithm-specific subregistry named
	"EdDSA Curve Label". The values for this subregistry are defined		"EdDSA Curve Label". The values for this subregistry are defined
	in Section 3.4.1.1. Future additions to this subregistry are to		in Section 3.4.1.1. Future additions to this subregistry are to
	be made through IETF Review (Section 4.8 of [RFC8126]).		be made through IETF Review (Section 4.8 of [RFC8126]).
	+===========+==============+=========+============+		+===========+==============+=========+============+
	| Algorithm | Curve | Value | Reference |		| Algorithm | Curve | Value | Reference |
	+===========+==============+=========+============+		+===========+==============+=========+============+
	skipping to change at line 1142 ¶		skipping to change at line 1144 ¶
	+-----------+--------------+---------+------------+		+-----------+--------------+---------+------------+
	| EdDSA | EdDSA25519ph | 2 | [RFC8032] |		| EdDSA | EdDSA25519ph | 2 | [RFC8032] |
	+-----------+--------------+---------+------------+		+-----------+--------------+---------+------------+
	| EdDSA | EdDSA448 | 3 | [RFC8032] |		| EdDSA | EdDSA448 | 3 | [RFC8032] |
	+-----------+--------------+---------+------------+		+-----------+--------------+---------+------------+
	| EdDSA | EdDSA448ph | 4 | [RFC8032] |		| EdDSA | EdDSA448ph | 4 | [RFC8032] |
	+-----------+--------------+---------+------------+		+-----------+--------------+---------+------------+
	| | | 5-65535 | Unassigned |		| | | 5-65535 | Unassigned |
	+-----------+--------------+---------+------------+		+-----------+--------------+---------+------------+
	Table 12		Table 12: Registered EdDSA Curve Labels
	HIT Suite ID:		HIT Suite ID:
	This document defines the new HIT Suite of EdDSA/cSHAKE with value		This document defines the new HIT Suite of EdDSA/cSHAKE with value
	5 (Section 3.4.2) in the "HIT Suite ID" subregistry of the "Host		5 (Section 3.4.2) in the "HIT Suite ID" subregistry of the "Host
	Identity Protocol (HIP) Parameters" registry.		Identity Protocol (HIP) Parameters" registry.
	+=================+=======+===========+		+=================+=======+===========+
	| Suite ID | Value | Reference |		| Suite ID | Value | Reference |
	+=================+=======+===========+		+=================+=======+===========+
	| EdDSA/cSHAKE128 | 5 | RFC 9374 |		| EdDSA/cSHAKE128 | 5 | RFC 9374 |
	+-----------------+-------+-----------+		+-----------------+-------+-----------+
	Table 13		Table 13: Registered HIT Suite of
			EdDSA/cSHAKE
	The HIT Suite ID 4-bit values 1 - 15 and 8-bit values 0x00 - 0x0F		The HIT Suite ID 4-bit values 1 - 15 and 8-bit values 0x00 - 0x0F
	MUST be replicated as HHIT Suite IDs (Section 8.2) as is 5 here.		MUST be replicated as HHIT Suite IDs (Section 8.2) as is 5 here.
	9. Security Considerations		9. Security Considerations
	The 64-bit hash in HHITs presents a real risk of second pre-image		The 64-bit hash in HHITs presents a real risk of second pre-image
	cryptographic hash attack (see Section 9.5). There are no known (to		cryptographic hash attack (see Section 9.5). There are no known (to
	the authors) studies of hash size impact on cryptographic hash		the authors) studies of hash size impact on cryptographic hash
	attacks.		attacks.
	skipping to change at line 1703 ¶		skipping to change at line 1706 ¶
	+------------------+-------------------------------------+------+		+------------------+-------------------------------------+------+
	| 2^72 | 1B | 10B |		| 2^72 | 1B | 10B |
	+------------------+-------------------------------------+------+		+------------------+-------------------------------------+------+
	| 2^68 | 250M | 2.5B |		| 2^68 | 250M | 2.5B |
	+------------------+-------------------------------------+------+		+------------------+-------------------------------------+------+
	| 2^64 | 66M | 663M |		| 2^64 | 66M | 663M |
	+------------------+-------------------------------------+------+		+------------------+-------------------------------------+------+
	| 2^60 | 16M | 160M |		| 2^60 | 16M | 160M |
	+------------------+-------------------------------------+------+		+------------------+-------------------------------------+------+
	Table 15		Table 15: Approximate Population Size With Collision Risk
	Acknowledgments		Acknowledgments
	Dr. Gurtov is an adviser on Cybersecurity to the Swedish Civil		Dr. Gurtov is an adviser on Cybersecurity to the Swedish Civil
	Aviation Administration.		Aviation Administration.
	Quynh Dang of NIST gave considerable guidance on using Keccak and the		Quynh Dang of NIST gave considerable guidance on using Keccak and the
	supporting NIST documents. Joan Deamen of the Keccak team was		supporting NIST documents. Joan Deamen of the Keccak team was
	especially helpful in many aspects of using Keccak. Nicholas		especially helpful in many aspects of using Keccak. Nicholas
	Gajcowski [CFRG-COMMENT] provided a concise hash pre-image security		Gajcowski [CFRG-COMMENT] provided a concise hash pre-image security
End of changes. 20 change blocks.
	22 lines changed or deleted		25 lines changed or added
This html diff was produced by rfcdiff 1.48.