Diff: draft-ietf-lamps-cms-shakes-09.txt - draft-ietf-lamps-cms-shakes-10.txt

	draft-ietf-lamps-cms-shakes-09.txt	draft-ietf-lamps-cms-shakes-10.txt

	LAMPS WG P. Kampanakis	LAMPS WG P. Kampanakis
	Internet-Draft Cisco Systems	Internet-Draft Cisco Systems
	Updates: RFC3370 (if approved) Q. Dang	Updates: RFC3370 (if approved) Q. Dang
	Intended status: Standards Track NIST	Intended status: Standards Track NIST

	Expires: October 13, 2019 April 11, 2019	Expires: October 27, 2019 April 25, 2019

	Use of the SHAKE One-way Hash Functions in the Cryptographic Message	Use of the SHAKE One-way Hash Functions in the Cryptographic Message
	Syntax (CMS)	Syntax (CMS)

	draft-ietf-lamps-cms-shakes-09	draft-ietf-lamps-cms-shakes-10

	Abstract	Abstract

	This document describes the conventions for using the SHAKE family of	This document describes the conventions for using the SHAKE family of
	hash functions with the Cryptographic Message Syntax (CMS) as one-way	hash functions with the Cryptographic Message Syntax (CMS) as one-way
	hash functions with the RSA Probabilistic signature and ECDSA	hash functions with the RSA Probabilistic signature and ECDSA
	signature algorithms, as message digests and message authentication	signature algorithms, as message digests and message authentication
	codes. The conventions for the associated signer public keys in CMS	codes. The conventions for the associated signer public keys in CMS
	are also described.	are also described.


	skipping to change at page 1, line 37 ¶	skipping to change at page 1, line 37 ¶
	Internet-Drafts are working documents of the Internet Engineering	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.	Drafts is at https://datatracker.ietf.org/drafts/current/.

	Internet-Drafts are draft documents valid for a maximum of six months	Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any	and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference	time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."	material or to cite them other than as "work in progress."


	This Internet-Draft will expire on October 13, 2019.	This Internet-Draft will expire on October 27, 2019.

	Copyright Notice	Copyright Notice

	Copyright (c) 2019 IETF Trust and the persons identified as the	Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.	document authors. All rights reserved.

	This document is subject to BCP 78 and the IETF Trust's Legal	This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents	Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of	(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents	publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect	carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must	to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of	include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as	the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.	described in the Simplified BSD License.

	Table of Contents	Table of Contents

	1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2	1. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4

	2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4	2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 5	3. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Use in CMS . . . . . . . . . . . . . . . . . . . . . . . . . 6	4. Use in CMS . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Message Digests . . . . . . . . . . . . . . . . . . . . . 6	4.1. Message Digests . . . . . . . . . . . . . . . . . . . . . 6
	4.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 7	4.2. Signatures . . . . . . . . . . . . . . . . . . . . . . . 7
	4.2.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 7	4.2.1. RSASSA-PSS Signatures . . . . . . . . . . . . . . . . 7
	4.2.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 8	4.2.2. ECDSA Signatures . . . . . . . . . . . . . . . . . . 8
	4.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 8	4.3. Public Keys . . . . . . . . . . . . . . . . . . . . . . . 8
	4.4. Message Authentication Codes . . . . . . . . . . . . . . 9	4.4. Message Authentication Codes . . . . . . . . . . . . . . 9
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9

	6. Security Considerations . . . . . . . . . . . . . . . . . . . 9	6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10

	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.1. Normative References . . . . . . . . . . . . . . . . . . 10	8.1. Normative References . . . . . . . . . . . . . . . . . . 11
	8.2. Informative References . . . . . . . . . . . . . . . . . 11	8.2. Informative References . . . . . . . . . . . . . . . . . 12
	Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12	Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17

	1. Change Log	1. Change Log

	[ EDNOTE: Remove this section before publication. ]	[ EDNOTE: Remove this section before publication. ]


		o draft-ietf-lamps-cms-shake-10:

		* Updated IANA considerations section to request for OID
		assignments.

	o draft-ietf-lamps-cms-shake-09:	o draft-ietf-lamps-cms-shake-09:

	* Fixed minor text nit.	* Fixed minor text nit.

	* Updates in Sec Considerations section.	* Updates in Sec Considerations section.

	o draft-ietf-lamps-cms-shake-08:	o draft-ietf-lamps-cms-shake-08:

	* id-shake128-len and id-shake256-len were replaced with id-	* id-shake128-len and id-shake256-len were replaced with id-
	sha128 with 32 bytes output length and id-shake256 with 64	sha128 with 32 bytes output length and id-shake256 with 64

	skipping to change at page 5, line 31 ¶	skipping to change at page 5, line 39 ¶
	nistAlgorithm(4) 2 11 }	nistAlgorithm(4) 2 11 }

	id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)	id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	country(16) us(840) organization(1) gov(101) csor(3)	country(16) us(840) organization(1) gov(101) csor(3)
	nistAlgorithm(4) 2 12 }	nistAlgorithm(4) 2 12 }

	In this specification, when using the id-shake128 or id-shake256	In this specification, when using the id-shake128 or id-shake256
	algorithm identifiers, the parameters MUST be absent. That is, the	algorithm identifiers, the parameters MUST be absent. That is, the
	identifier SHALL be a SEQUENCE of one component, the OID.	identifier SHALL be a SEQUENCE of one component, the OID.


	We define two new identifiers for RSASSA-PSS signatures using SHAKEs.	We define two identifiers for RSASSA-PSS signatures using SHAKEs.

	id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD1 }


	id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD2 }	id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1)
		identified-organization(3) dod(6) internet(1)
		security(5) mechanisms(5) pkix(7) algorithms(6)
		TBD1 }


	[ EDNOTE: "TBD1", "TBD2" will be specified by NIST later. ]	id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1)
		identified-organization(3) dod(6) internet(1)
		security(5) mechanisms(5) pkix(7) algorithms(6)
		TBD2 }

	The same RSASSA-PSS algorithm identifiers can be used for identifying	The same RSASSA-PSS algorithm identifiers can be used for identifying
	public keys and signatures.	public keys and signatures.


	We define two new algorithm identifiers of ECDSA signatures using	We define two algorithm identifiers of ECDSA signatures using SHAKEs.
	SHAKEs.

	id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	country(16) us(840) organization(1) gov(101) csor(3)
	nistAlgorithm(4) 3 TBD3 }


	id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)	id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1)
	country(16) us(840) organization(1) gov(101) csor(3)	identified-organization(3) dod(6) internet(1)
	nistAlgorithm(4) 3 TBD4 }	security(5) mechanisms(5) pkix(7) algorithms(6)
		TBD3 }


	[ EDNOTE: "TBD3", "TBD4" will be specified by NIST. ]	id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1)
		identified-organization(3) dod(6) internet(1)
		security(5) mechanisms(5) pkix(7) algorithms(6)
		TBD4 }

	The parameters for the four RSASSA-PSS and ECDSA identifiers MUST be	The parameters for the four RSASSA-PSS and ECDSA identifiers MUST be
	absent. That is, each identifier SHALL be a SEQUENCE of one	absent. That is, each identifier SHALL be a SEQUENCE of one
	component, the OID.	component, the OID.


	Two new object identifiers for KMACs using SHAKE128 and SHAKE256 are	Two object identifiers for KMACs using SHAKE128 and SHAKE256 are
	defined below.	defined below.

	id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)	id-KmacWithSHAKE128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	country(16) us(840) organization(1) gov(101) csor(3)	country(16) us(840) organization(1) gov(101) csor(3)
	nistAlgorithm(4) 2 19 }	nistAlgorithm(4) 2 19 }

	id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)	id-KmacWithSHAKE256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
	country(16) us(840) organization(1) gov(101) csor(3)	country(16) us(840) organization(1) gov(101) csor(3)
	nistAlgorithm(4) 2 20 }	nistAlgorithm(4) 2 20 }


	skipping to change at page 9, line 39 ¶	skipping to change at page 9, line 46 ¶
	Conforming implementations that process KMACs with the SHAKEs when	Conforming implementations that process KMACs with the SHAKEs when
	processing CMS data MUST recognize these identifiers.	processing CMS data MUST recognize these identifiers.

	When calculating the KMAC output, the variable N is 0xD2B282C2, S is	When calculating the KMAC output, the variable N is 0xD2B282C2, S is
	an empty string, and L, the integer representing the requested output	an empty string, and L, the integer representing the requested output
	length in bits, is 256 or 512 for KmacWithSHAKE128 or	length in bits, is 256 or 512 for KmacWithSHAKE128 or
	KmacWithSHAKE256 respectively in this specification.	KmacWithSHAKE256 respectively in this specification.

	5. IANA Considerations	5. IANA Considerations


	One object identifier for the ASN.1 module in Appendix A was assigned	One object identifier for the ASN.1 module in Appendix A was
	in the SMI Security for S/MIME Module Identifiers	requested for the SMI Security for S/MIME Module Identifiers
	(1.2.840.113549.1.9.16.0) registry:	(1.2.840.113549.1.9.16.0) registry:


	CMSAlgsForSHAKE-2019 { iso(1) member-body(2) us(840)	+---------+----------------------+--------------------+
	rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0)	\| Decimal \| Description \| References \|
	id-mod-cms-shakes-2019(TBD) }	+---------+----------------------+--------------------+
		\| TBD \| CMSAlgsForSHAKE-2019 \| [EDNOTE: THIS RFC] \|
		+---------+----------------------+--------------------+

		IANA has assigned four OID identifiers in the SMI Security for PKIX
		Algorithms [SMI-PKIX] (1.3.6.1.5.5.7.6) registry

		id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1)
		identified-organization(3) dod(6) internet(1)
		security(5) mechanisms(5) pkix(7) algorithms(6)
		TBD1 }
		id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1)
		identified-organization(3) dod(6) internet(1)
		security(5) mechanisms(5) pkix(7) algorithms(6)
		TBD2 }
		id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1)
		identified-organization(3) dod(6) internet(1)
		security(5) mechanisms(5) pkix(7) algorithms(6)
		TBD3 }
		id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1)
		identified-organization(3) dod(6) internet(1)
		security(5) mechanisms(5) pkix(7) algorithms(6)
		TBD4 }

	6. Security Considerations	6. Security Considerations

	This document updates [RFC3370]. The security considerations section	This document updates [RFC3370]. The security considerations section
	of that document applies to this specification as well.	of that document applies to this specification as well.

	NIST has defined appropriate use of the hash functions in terms of	NIST has defined appropriate use of the hash functions in terms of
	the algorithm strengths and expected time frames for secure use in	the algorithm strengths and expected time frames for secure use in
	Special Publications (SPs) [SP800-78-4] and [SP800-107]. These	Special Publications (SPs) [SP800-78-4] and [SP800-107]. These
	documents can be used as guides to choose appropriate key sizes for	documents can be used as guides to choose appropriate key sizes for

	skipping to change at page 12, line 26 ¶	skipping to change at page 13, line 11 ¶
	[SEC1] Standards for Efficient Cryptography Group, "SEC 1:	[SEC1] Standards for Efficient Cryptography Group, "SEC 1:
	Elliptic Curve Cryptography", May 2009,	Elliptic Curve Cryptography", May 2009,
	<http://www.secg.org/sec1-v2.pdf>.	<http://www.secg.org/sec1-v2.pdf>.

	[shake-nist-oids]	[shake-nist-oids]
	National Institute of Standards and Technology, "Computer	National Institute of Standards and Technology, "Computer
	Security Objects Register", October 2017,	Security Objects Register", October 2017,
	<https://csrc.nist.gov/Projects/Computer-Security-Objects-	<https://csrc.nist.gov/Projects/Computer-Security-Objects-
	Register/Algorithm-Registration>.	Register/Algorithm-Registration>.


		[SMI-PKIX]
		IANA, "SMI Security for PKIX Algorithms", March 2019,
		<https://www.iana.org/assignments/smi-numbers/
		smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.6>.

	[SP800-107]	[SP800-107]
	National Institute of Standards and Technology (NIST),	National Institute of Standards and Technology (NIST),
	"SP800-107: Recommendation for Applications Using Approved	"SP800-107: Recommendation for Applications Using Approved
	Hash Algorithms", May 2014,	Hash Algorithms", May 2014,
	<https://csrc.nist.gov/csrc/media/publications/sp/800-107/	<https://csrc.nist.gov/csrc/media/publications/sp/800-107/
	rev-1/final/documents/draft_revised_sp800-107.pdf>.	rev-1/final/documents/draft_revised_sp800-107.pdf>.

	[SP800-78-4]	[SP800-78-4]
	National Institute of Standards and Technology (NIST),	National Institute of Standards and Technology (NIST),
	"SP800-78-4: Cryptographic Algorithms and Key Sizes for	"SP800-78-4: Cryptographic Algorithms and Key Sizes for

	skipping to change at page 14, line 22 ¶	skipping to change at page 15, line 13 ¶
	-- And Signature identifiers used in SignerInfo	-- And Signature identifiers used in SignerInfo
	-- signatureAlgorithm field of SignedData content	-- signatureAlgorithm field of SignedData content
	-- type and countersignature attribute in CMS.	-- type and countersignature attribute in CMS.
	--	--
	-- From RFC5280, for reference.	-- From RFC5280, for reference.
	-- rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }	-- rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }
	-- When the rsaEncryption algorithm identifier is used	-- When the rsaEncryption algorithm identifier is used
	-- for a public key, the AlgorithmIdentifier parameters	-- for a public key, the AlgorithmIdentifier parameters
	-- field MUST contain NULL.	-- field MUST contain NULL.
	--	--

	id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { TBD1 }	id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1)
	id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { TBD2 }	identified-organization(3) dod(6) internet(1)
		security(5) mechanisms(5) pkix(7) algorithms(6)
		TBD1 }
		id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1)
		identified-organization(3) dod(6) internet(1)
		security(5) mechanisms(5) pkix(7) algorithms(6)
		TBD2 }
	-- When the id-RSASSA-PSS-* algorithm identifiers are used	-- When the id-RSASSA-PSS-* algorithm identifiers are used
	-- for a public key or signature in CMS, the AlgorithmIdentifier	-- for a public key or signature in CMS, the AlgorithmIdentifier
	-- parameters field MUST be absent. The message digest algorithm	-- parameters field MUST be absent. The message digest algorithm
	-- used in RSASSA-PSS MUST be SHAKE128 or SHAKE256 with a 32 or	-- used in RSASSA-PSS MUST be SHAKE128 or SHAKE256 with a 32 or
	-- 64 byte outout length respectively. The mask generating	-- 64 byte outout length respectively. The mask generating
	-- function MUST be SHAKE128 or SHAKE256 with an output length	-- function MUST be SHAKE128 or SHAKE256 with an output length
	-- of (n - 264) or (n - 520) bits respectively, where n	-- of (n - 264) or (n - 520) bits respectively, where n
	-- is the RSA modulus in bits. The RSASSA-PSS saltLength MUST	-- is the RSA modulus in bits. The RSASSA-PSS saltLength MUST
	-- be 32 or 64 bytes respectively. The trailerField MUST be 1,	-- be 32 or 64 bytes respectively. The trailerField MUST be 1,
	-- which represents the trailer field with hexadecimal value	-- which represents the trailer field with hexadecimal value

	skipping to change at page 14, line 39 ¶	skipping to change at page 15, line 35 ¶
	-- 64 byte outout length respectively. The mask generating	-- 64 byte outout length respectively. The mask generating
	-- function MUST be SHAKE128 or SHAKE256 with an output length	-- function MUST be SHAKE128 or SHAKE256 with an output length
	-- of (n - 264) or (n - 520) bits respectively, where n	-- of (n - 264) or (n - 520) bits respectively, where n
	-- is the RSA modulus in bits. The RSASSA-PSS saltLength MUST	-- is the RSA modulus in bits. The RSASSA-PSS saltLength MUST
	-- be 32 or 64 bytes respectively. The trailerField MUST be 1,	-- be 32 or 64 bytes respectively. The trailerField MUST be 1,
	-- which represents the trailer field with hexadecimal value	-- which represents the trailer field with hexadecimal value
	-- 0xBC. Regardless of id-RSASSA-PSS-* or rsaEncryption being	-- 0xBC. Regardless of id-RSASSA-PSS-* or rsaEncryption being
	-- used as the AlgorithmIdentifier of the OriginatorPublicKey,	-- used as the AlgorithmIdentifier of the OriginatorPublicKey,
	-- the RSA public key MUST be encoded using the RSAPublicKey	-- the RSA public key MUST be encoded using the RSAPublicKey
	-- type.	-- type.


	-- From RFC4055, for reference.	-- From RFC4055, for reference.
	-- RSAPublicKey ::= SEQUENCE {	-- RSAPublicKey ::= SEQUENCE {
	-- modulus INTEGER, -- -- n	-- modulus INTEGER, -- -- n
	-- publicExponent INTEGER } -- -- e	-- publicExponent INTEGER } -- -- e


	id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)	id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1)
	country(16) us(840) organization(1)	identified-organization(3) dod(6) internet(1)
	gov(101) csor(3) nistAlgorithm(4)	security(5) mechanisms(5) pkix(7) algorithms(6)
	sigAlgs(3) TBD3 }	TBD3 }
	id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)	id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1)
	country(16) us(840) organization(1)	identified-organization(3) dod(6) internet(1)
	gov(101) csor(3) nistAlgorithm(4)	security(5) mechanisms(5) pkix(7) algorithms(6)
	sigAlgs(3) TBD4 }	TBD4 }

	-- When the id-ecdsa-with-shake* algorithm identifiers are	-- When the id-ecdsa-with-shake* algorithm identifiers are
	-- used in CMS, the AlgorithmIdentifier parameters field	-- used in CMS, the AlgorithmIdentifier parameters field
	-- MUST be absent and the signature algorithm should be	-- MUST be absent and the signature algorithm should be
	-- deterministic ECDSA [RFC6979]. The message digest MUST	-- deterministic ECDSA [RFC6979]. The message digest MUST
	-- be SHAKE128 or SHAKE256 with a 32 or 64 byte outout	-- be SHAKE128 or SHAKE256 with a 32 or 64 byte outout
	-- length respectively. In both cases, the ECDSA public key,	-- length respectively. In both cases, the ECDSA public key,
	-- MUST be encoded using the id-ecPublicKey type.	-- MUST be encoded using the id-ecPublicKey type.


	-- From RFC5480, for reference.	-- From RFC5480, for reference.
	-- id-ecPublicKey OBJECT IDENTIFIER ::= {	-- id-ecPublicKey OBJECT IDENTIFIER ::= {
	-- iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }	-- iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
	-- The id-ecPublicKey parameters must be absent or present	-- The id-ecPublicKey parameters must be absent or present
	-- and are defined as	-- and are defined as
	-- ECParameters ::= CHOICE {	-- ECParameters ::= CHOICE {
	-- namedCurve OBJECT IDENTIFIER	-- namedCurve OBJECT IDENTIFIER
	-- -- -- implicitCurve NULL	-- -- -- implicitCurve NULL
	-- -- -- specifiedCurve SpecifiedECDomain	-- -- -- specifiedCurve SpecifiedECDomain
	-- }	-- }

End of changes. 21 change blocks.
	43 lines changed or deleted	84 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/