< draft-ietf-dcrup-dkim-ecc-00.txt		draft-ietf-dcrup-dkim-ecc-01.txt >
	DCRUP S. Rose		DCRUP S. Rose
	Internet-Draft NIST		Internet-Draft NIST
	Updates: 6376 (if approved) June 2, 2017		Updates: 6376 (if approved) June 21, 2017
	Intended status: Standards Track		Intended status: Standards Track
	Expires: December 4, 2017		Expires: December 23, 2017
	Defining Elliptic Curve Cryptography Algorithms for use with DKIM		Defining Elliptic Curve Cryptography Algorithms for use with DKIM
	draft-ietf-dcrup-dkim-ecc-00		draft-ietf-dcrup-dkim-ecc-01
	Abstract		Abstract
	DomainKeys Identified Mail (DKIM) uses digital signature to associate		DomainKeys Identified Mail (DKIM) uses digital signature to associate
	a message with a given sending domain. Currently, there is only one		a message with a given sending domain. Currently, there is only one
	cryptography algorithm defined for use with DKIM (RSA). This		cryptography algorithm defined for use with DKIM (RSA). This
	document defines four new elliptic curve cryptography algorithms for		document defines four new elliptic curve cryptography algorithms for
	use with DKIM. This will allow for algorithm agility if a weakness		use with DKIM. This will allow for algorithm agility if a weakness
	is found in RSA, and allows for smaller key length to provide the		is found in RSA, and allows for smaller key length to provide the
	same digital signature strength.		same digital signature strength.
	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 http://datatracker.ietf.org/drafts/current/.		Drafts is at http://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 December 4, 2017.		This Internet-Draft will expire on December 23, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://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
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 33 ¶
	2. Defining New ECC algorithms for Use with DKIM		2. Defining New ECC algorithms for Use with DKIM
	This document defines a new digital signature algorithm for use with		This document defines a new digital signature algorithm for use with
	DKIM:		DKIM:
	algorithm | mnemonic		algorithm | mnemonic
	-------------+-------------		-------------+-------------
	ECDSA P-256 | ecdsa256		ECDSA P-256 | ecdsa256
	The SHA-512 hash algorithm is also now defined for use with DKIM		For ECDSA, the SHA-1 hash algorithm MUST NOT be used.
	using the mnemonic 'sha512' for the "h=" DKIM key tag and "a=" sig-
	a-tag-h DKIM signature tag (see below).
	For ECDSA, the SHA-1 hash algorithm MUST NOT be used. Both ECDSA and
	RSA MAY be used with SHA-512.
	3. Changes to ABNF Definitions of DKIM Keys and Signatures		3. Changes to ABNF Definitions of DKIM Keys and Signatures
	The original definition of DKIM signatues and keys are defined in		The original definition of DKIM signatues and keys are defined in
	[RFC6376]. The following are changes to the definition to include		[RFC6376]. The following are changes to the definition to include
	the new digital signature algorithm and secure hash algorithm.		the new digital signature algorithm and secure hash algorithm.
	3.1. Changes to DKIM Key Definition		3.1. Changes to DKIM Key Definition
	The original definition of the textual representation of DKIM keys is		The original definition of the textual representation of DKIM keys is
	skipping to change at page 4, line 17 ¶		skipping to change at page 4, line 12 ¶
	h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to		h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to
	"sha256"). A colon-separated list of hash algorithms that might		"sha256"). A colon-separated list of hash algorithms that might
	be used. Unrecognized algorithms MUST be ignored. Refer to		be used. Unrecognized algorithms MUST be ignored. Refer to
	[RFC6376]Section 3.3 for a discussion of the hash algorithms		[RFC6376]Section 3.3 for a discussion of the hash algorithms
	implemented by Signers and Verifiers. The set of algorithms		implemented by Signers and Verifiers. The set of algorithms
	listed in this tag in each record is an operational choice made by		listed in this tag in each record is an operational choice made by
	the Signer.		the Signer.
	ABNF:		ABNF:
	key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg *( [FWS] ":" [FWS]		key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg
	key-h-tag-alg ) key-h-tag-alg = "sha1" / "sha256" / "sha512" / x-		*( [FWS] ":" [FWS] key-h-tag-alg )
	key-h-tag-alg x-key-h-tag-alg = hyphenated-word ; for future		key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg
	extension		x-key-h-tag-alg = hyphenated-word ; for future extension
	k= Key type (plain-text; MANDATORY). Signers and Verifiers MUST		k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and
	support the "rsa" key type. The "rsa" key type indicates that an		Verifiers MUST support the "rsa" key type. The "rsa" key type
	ASN.1 DER-encoded [UTI.X680.2002] RSAPublicKey (see [RFC8017],		indicates that an ASN.1 DER-encoded [UTI.X680.2002] RSAPublicKey
	Sections 3.1 and A.1.1) is being used in the "p=" tag. The		(see [RFC8017], Sections 3.1 and A.1.1) is being used in the "p="
	"ecdsa256" key type indicates an ASN.1 DER-encoded [UTI.X680.2002]		tag. The "ecdsa256" key type indicates an ASN.1 DER-encoded
	PublicKey (see [RFC5480], Section 2.2) is being used in the "p="		[UTI.X680.2002] PublicKey (see [RFC5480], Section 2.2) is being
	tag. (Note: the "p=" tag further encodes the value using the		used in the "p=" tag. (Note: the "p=" tag further encodes the
	base64 algorithm.) Unrecognized key types MUST be ignored.		value using the base64 algorithm.) Unrecognized key types MUST be
			ignored.
	ABNF:		ABNF:
	key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type key-k-tag-type =		key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type
	"rsa" / "ecdsa256" / x-key-k-tag-type x-key-k-tag-type =		key-k-tag-type = "rsa" / "ecdsa256" / x-key-k-tag-type
	hyphenated-word ; for future extension		x-key-k-tag-type = hyphenated-word ; for future extension
	3.2. Changes to DKIM Signature Definition		3.2. Changes to DKIM Signature Definition
	The original definition of the textual representation of DKIM		The original definition of the textual representation of DKIM
	signatures is found in section 3.5 of [RFC6376]. The only changes to		signatures is found in section 3.5 of [RFC6376]. The only changes to
	the definition is below. The entire key:tag definition is included		the definition is below. The entire key:tag definition is included
	for clarity. All other tags:value pairs are unchanged. References		for clarity. All other tags:value pairs are unchanged. References
	to the definitions below have also been updated to reflect the		to the definitions below have also been updated to reflect the
	current state of the art.		current state of the art.
	a= The algorithm used to generate the signature (plain-text;		a= The algorithm used to generate the signature (plain-text;
	REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256" and		REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256" and
	SHOULD support "ecdsa256-sha256"; Signers MUST NOT use "sha1" with		SHOULD support "ecdsa256-sha256"; Signers MUST NOT use "sha1" with
	"ecdsa256". See [RFC6376] Section 3.3 for a description of RSA		"ecdsa256". See [RFC6376] Section 3.3 for a description of RSA
	and [FIPS.186-4.2013] Section 6 for a brief description of ECDSA.		and [FIPS.186-4.2013] Section 6 for a brief description of ECDSA.
	ABNF:		ABNF:
	sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg sig-a-tag-alg =		sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg
	sig-a-tag-k "-" sig-a-tag-h sig-a-tag-k = "rsa" / "ecdsa256" / x-		sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h
	sig-a-tag-k sig-a-tag-h = "sha1" / "sha256" / "sha512" / x-sig-		sig-a-tag-k = "rsa" / "ecdsa256" / x-sig-a-tag-k
	a-tag-h x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) ; for later		sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h
	extension x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) ; for later		x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT)
	extension		; for later extension
			x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT)
			; for later extension
	4. Sender Considerations		4. Sender Considerations
	New algorithms for an established protocols take some time to gain		New algorithms for an established protocols take some time to gain
	wide deployment. There will be a period of time where new algorithms		wide deployment. There will be a period of time where new algorithms
	are in operation side by side with older algorithms. There will also		are in operation side by side with older algorithms. There will also
	be a sizable percentage of DKIM validators that will not understand		be a sizable percentage of DKIM validators that will not understand
	new algorithms until they are upgraded. This will lead to a period		new algorithms until they are upgraded. This will lead to a period
	of time where multiple DKIM signature algorithms are in use for a		of time where multiple DKIM signature algorithms are in use for a
	sender. Email administrators MAY want to also sign with RSA/SHA-1 or		sender. Email administrators MAY want to also sign with RSA/SHA-1 or
	skipping to change at page 5, line 35 ¶		skipping to change at page 5, line 37 ¶
	view on DKIM validation rates by receivers.		view on DKIM validation rates by receivers.
	5. Receiver Considerations		5. Receiver Considerations
	These requirements are for DKIM verifiers (as defined it [RFC6376]).		These requirements are for DKIM verifiers (as defined it [RFC6376]).
	These entities would be the consumers of any end-to-end email		These entities would be the consumers of any end-to-end email
	security policy and would be the entity responsible for validating		security policy and would be the entity responsible for validating
	DKIM signatures.		DKIM signatures.
	DKIM verifiers claiming conformance to this document MUST implement		DKIM verifiers claiming conformance to this document MUST implement
	all of the above cryptographic algorithms and SHOULD implement the		all of the above cryptographic algorithms.
	SHA-512 hash algorithm.
	This document does NOT change the behavior of the core DKIM		This document does NOT change the behavior of the core DKIM
	specification in that verifiers MUST ignore unknown algorithms in		specification in that verifiers MUST ignore unknown algorithms in
	DKIM signatures.		DKIM signatures.
	6. Security Considerations		6. Security Considerations
	This document defines the use of new elliptic curve cryptographic		This document defines the use of new elliptic curve cryptographic
	algorithms for use with DomainKey Identified Mail (DKIM). This		algorithms for use with DomainKey Identified Mail (DKIM). This
	document is not a discussion of the relative strengths or weaknesses		document is not a discussion of the relative strengths or weaknesses
	skipping to change at page 6, line 21 ¶		skipping to change at page 6, line 22 ¶
	value:		value:
	algorithm | mnemonic | Reference		algorithm | mnemonic | Reference
	-------------+------------+--------------		-------------+------------+--------------
	ECDSA P-256 | ecdsa256 | This document		ECDSA P-256 | ecdsa256 | This document
	The current DKIM Key Tag registry is located at		The current DKIM Key Tag registry is located at
	https://www.iana.org/assignments/dkim-parameters/dkim-		https://www.iana.org/assignments/dkim-parameters/dkim-
	parameters.xhtml#dkim-parameters-6		parameters.xhtml#dkim-parameters-6
	This draft also defines a new hash algorithm for use with DKIM. This
	draft updates the "DKIM Hash Algorithms" registry to include the
	following new entry:
	algorithm | mnemonic | Reference
	-------------+------------+--------------
	SHA-512 | sha512 | This document
	The current DKIM Hash Algorithm registry is located at
	https://www.iana.org/assignments/dkim-parameters/dkim-
	parameters.xhtml#dkim-parameters-7
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,		[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
End of changes. 13 change blocks.
	47 lines changed or deleted		32 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/