rfc9053v8.txt		rfc9053.txt
	skipping to change at line 1681 ¶		skipping to change at line 1681 ¶
	the y-coordinate. The latter encoding has not been recommended by		the y-coordinate. The latter encoding has not been recommended by
	the IETF due to potential IPR issues. However, for operations in		the IETF due to potential IPR issues. However, for operations in
	constrained environments, the ability to shrink a message by not		constrained environments, the ability to shrink a message by not
	sending the y-coordinate is potentially useful.		sending the y-coordinate is potentially useful.
	For EC keys with both coordinates, the "kty" member is set to 2		For EC keys with both coordinates, the "kty" member is set to 2
	(EC2). The key parameters defined in this section are summarized in		(EC2). The key parameters defined in this section are summarized in
	Table 19. The members that are defined for this key type are:		Table 19. The members that are defined for this key type are:
	crv: This contains an identifier of the curve to be used with the		crv: This contains an identifier of the curve to be used with the
	key. The curves defined in this document for this key type can		key. The curves defined in this document for this key type can
	be found in Table 18. Other curves may be registered in the		be found in Table 18. Other curves may be registered in the
	future, and private curves can be used as well.		future, and private curves can be used as well.
	x: This contains the x-coordinate for the EC point. The integer is		x: This contains the x-coordinate for the EC point. The integer
	converted to a byte string as defined in [SEC1]. Leading-zero		is converted to a byte string as defined in [SEC1]. Leading-
	octets MUST be preserved.		zero octets MUST be preserved.
	y: This contains either the sign bit or the value of the		y: This contains either the sign bit or the value of the
	y-coordinate for the EC point. When encoding the value y, the		y-coordinate for the EC point. When encoding the value y, the
	integer is converted to a byte string (as defined in [SEC1]) and		integer is converted to a byte string (as defined in [SEC1])
	encoded as a CBOR bstr. Leading-zero octets MUST be preserved.		and encoded as a CBOR bstr. Leading-zero octets MUST be
	Compressed point encoding is also supported. Compute the sign		preserved. Compressed point encoding is also supported.
	bit as laid out in the Elliptic-Curve-Point-to-Octet-String		Compute the sign bit as laid out in the Elliptic-Curve-Point-
	Conversion function of [SEC1]. If the sign bit is zero, then		to-Octet-String Conversion function of [SEC1]. If the sign bit
	encode y as a CBOR false value; otherwise, encode y as a CBOR		is zero, then encode y as a CBOR false value; otherwise, encode
	true value. The encoding of the infinity point is not		y as a CBOR true value. The encoding of the infinity point is
	supported.		not supported.
	d: This contains the private key.		d: This contains the private key.
	For public keys, it is REQUIRED that "crv", "x", and "y" be present		For public keys, it is REQUIRED that "crv", "x", and "y" be present
	in the structure. For private keys, it is REQUIRED that "crv" and		in the structure. For private keys, it is REQUIRED that "crv" and
	"d" be present in the structure. For private keys, it is RECOMMENDED		"d" be present in the structure. For private keys, it is RECOMMENDED
	that "x" and "y" also be present, but they can be recomputed from the		that "x" and "y" also be present, but they can be recomputed from the
	required elements, and omitting them saves on space.		required elements, and omitting them saves on space.
	+======+======+=======+========+=================================+		+======+======+=======+========+=================================+
	| Key | Name | Label | CBOR | Description |		| Key | Name | Label | CBOR | Description |
	| Type | | | Type | |		| Type | | | Type | |
	skipping to change at line 1736 ¶		skipping to change at line 1736 ¶
	A new key type is defined for Octet Key Pairs (OKPs). Do not assume		A new key type is defined for Octet Key Pairs (OKPs). Do not assume
	that keys using this type are elliptic curves. This key type could		that keys using this type are elliptic curves. This key type could
	be used for other curve types (for example, mathematics based on		be used for other curve types (for example, mathematics based on
	hyper-elliptic surfaces).		hyper-elliptic surfaces).
	The key parameters defined in this section are summarized in		The key parameters defined in this section are summarized in
	Table 20. The members that are defined for this key type are:		Table 20. The members that are defined for this key type are:
	crv: This contains an identifier of the curve to be used with the		crv: This contains an identifier of the curve to be used with the
	key. The curves defined in this document for this key type can		key. The curves defined in this document for this key type can
	be found in Table 18. Other curves may be registered in the		be found in Table 18. Other curves may be registered in the
	future, and private curves can be used as well.		future, and private curves can be used as well.
	x: This contains the public key. The byte string contains the		x: This contains the public key. The byte string contains the
	public key as defined by the algorithm. (For X25519, internally		public key as defined by the algorithm. (For X25519,
	it is a little-endian integer.)		internally it is a little-endian integer.)
	d: This contains the private key.		d: This contains the private key.
	For public keys, it is REQUIRED that "crv" and "x" be present in the		For public keys, it is REQUIRED that "crv" and "x" be present in the
	structure. For private keys, it is REQUIRED that "crv" and "d" be		structure. For private keys, it is REQUIRED that "crv" and "d" be
	present in the structure. For private keys, it is RECOMMENDED that		present in the structure. For private keys, it is RECOMMENDED that
	"x" also be present, but it can be recomputed from the required		"x" also be present, but it can be recomputed from the required
	elements, and omitting it saves on space.		elements, and omitting it saves on space.
	+======+==========+=======+=======+=================================+		+======+==========+=======+=======+=================================+
	| Name | Key | Label | Type | Description |		| Name | Key | Label | Type | Description |
	| | Type | | | |		| | Type | | | |
	skipping to change at line 2275 ¶		skipping to change at line 2275 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF		[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
	Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,		Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
	<https://www.rfc-editor.org/info/rfc8439>.		<https://www.rfc-editor.org/info/rfc8439>.
	[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):		[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
	Structures and Process", STD 96, RFC 9052,		Structures and Process", STD 96, RFC 9052,
	DOI 10.17487/RFC9052, July 2022,		DOI 10.17487/RFC9052, August 2022,
	<https://www.rfc-editor.org/info/rfc9052>.		<https://www.rfc-editor.org/info/rfc9052>.
	[SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography",		[SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography",
	Standards for Efficient Cryptography, May 2009,		Standards for Efficient Cryptography, May 2009,
	<https://www.secg.org/sec1-v2.pdf>.		<https://www.secg.org/sec1-v2.pdf>.
	[STD94] Bormann, C. and P. Hoffman, "Concise Binary Object		[STD94] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", STD 94, RFC 8949, December 2020,		Representation (CBOR)", STD 94, RFC 8949, December 2020,
	<https://www.rfc-editor.org/info/std94>.		<https://www.rfc-editor.org/info/std94>.
	skipping to change at line 2299 ¶		skipping to change at line 2299 ¶
	Mattsson, J. P., Thormarker, E., and S. Ruohomaa,		Mattsson, J. P., Thormarker, E., and S. Ruohomaa,
	"Deterministic ECDSA and EdDSA Signatures with Additional		"Deterministic ECDSA and EdDSA Signatures with Additional
	Randomness", Work in Progress, Internet-Draft, draft-		Randomness", Work in Progress, Internet-Draft, draft-
	mattsson-cfrg-det-sigs-with-noise-04, 15 February 2022,		mattsson-cfrg-det-sigs-with-noise-04, 15 February 2022,
	<https://datatracker.ietf.org/doc/html/draft-mattsson-		<https://datatracker.ietf.org/doc/html/draft-mattsson-
	cfrg-det-sigs-with-noise-04>.		cfrg-det-sigs-with-noise-04>.
	[COUNTERSIGN]		[COUNTERSIGN]
	Schaad, J. and R. Housley, "CBOR Object Signing and		Schaad, J. and R. Housley, "CBOR Object Signing and
	Encryption (COSE): Countersignatures", Work in Progress,		Encryption (COSE): Countersignatures", Work in Progress,
	Internet-Draft, draft-ietf-cose-countersign-06, 20 July		Internet-Draft, draft-ietf-cose-countersign-08, 22 August
	2022, <https://datatracker.ietf.org/doc/html/draft-ietf-		2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
	cose-countersign-06>.		cose-countersign-08>.
	[GitHub-Examples]		[GitHub-Examples]
	"GitHub Examples of COSE", commit 3221310, 3 June 2020,		"GitHub Examples of COSE", commit 3221310, 3 June 2020,
	<https://github.com/cose-wg/Examples>.		<https://github.com/cose-wg/Examples>.
	[HKDF] Krawczyk, H., "Cryptographic Extraction and Key		[HKDF] Krawczyk, H., "Cryptographic Extraction and Key
	Derivation: The HKDF Scheme", 2010,		Derivation: The HKDF Scheme", 2010,
	<https://eprint.iacr.org/2010/264.pdf>.		<https://eprint.iacr.org/2010/264.pdf>.
	[OSCORE-GROUPCOMM]		[OSCORE-GROUPCOMM]
End of changes. 10 change blocks.
	27 lines changed or deleted		27 lines changed or added
This html diff was produced by rfcdiff 1.48.