draft-ietf-acme-client-01.txt		draft-ietf-acme-client-02.txt
	IETF K. Moriarty		IETF K. Moriarty
	Internet-Draft Dell Technologies		Internet-Draft Dell Technologies
	Intended status: Standards Track May 18, 2020		Intended status: Standards Track October 5, 2020
	Expires: November 19, 2020		Expires: April 8, 2021
	ACME End User Client and Code Signing Certificates		ACME End User Client and Code Signing Certificates
	draft-ietf-acme-client-01		draft-ietf-acme-client-02
	Abstract		Abstract
	Automated Certificate Management Environment (ACME) core protocol		Automated Certificate Management Environment (ACME) core protocol
	addresses the use case of web server certificates for TLS. This		addresses the use case of web server certificates for TLS. This
	document extends the ACME protocol to support end user client, device		document extends the ACME protocol to support end user client, device
	client, and code signing certificates.		client, and code signing certificates.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	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 November 19, 2020.		This Internet-Draft will expire on April 8, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	skipping to change at page 2, line 16 ¶		skipping to change at page 2, line 16 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Identity Proofing for Client Certificates . . . . . . . . . . 2		2. Identity Proofing for Client Certificates . . . . . . . . . . 2
	3. End User Client Certificates . . . . . . . . . . . . . . . . 3		3. End User Client Certificates . . . . . . . . . . . . . . . . 3
	4. CodeSigning Certificates . . . . . . . . . . . . . . . . . . 5		4. CodeSigning Certificates . . . . . . . . . . . . . . . . . . 5
	5. Pre-authorization . . . . . . . . . . . . . . . . . . . . . . 8		5. Pre-authorization . . . . . . . . . . . . . . . . . . . . . . 8
	6. Challenge Types . . . . . . . . . . . . . . . . . . . . . . . 8		6. Challenge Types . . . . . . . . . . . . . . . . . . . . . . . 8
	6.1. One Time Password (OTP) . . . . . . . . . . . . . . . . . 8		6.1. One Time Password (OTP) . . . . . . . . . . . . . . . . . 8
	6.1.1. HMAC-Based One-Time Password (HOTP) . . . . . . . . . 9		6.1.1. HMAC-Based One-Time Password (HOTP) . . . . . . . . . 9
	6.1.2. Time-Based One-Time Password (TOTP) . . . . . . . . . 9		6.1.2. Time-Based One-Time Password (TOTP) . . . . . . . . . 9
	6.1.3. Generic One Time Password (OTP) . . . . . . . . . . . 10		6.1.3. Generic One Time Password (OTP) . . . . . . . . . . . 9
	6.2. Public Key Cryptography . . . . . . . . . . . . . . . . . 10		6.2. Public Key Cryptography . . . . . . . . . . . . . . . . . 10
	6.3. WebAuthn or Public/Private Key Pairs . . . . . . . . . . 11		6.3. WebAuthn or Public/Private Key Pairs . . . . . . . . . . 11
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	10.1. Normative References . . . . . . . . . . . . . . . . . . 12		10.1. Normative References . . . . . . . . . . . . . . . . . . 12
	10.2. Informative References . . . . . . . . . . . . . . . . . 13		10.2. Informative References . . . . . . . . . . . . . . . . . 13
	10.3. URL References . . . . . . . . . . . . . . . . . . . . . 13		10.3. URL References . . . . . . . . . . . . . . . . . . . . . 13
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14		Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14
	Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 14		Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 14
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
	skipping to change at page 6, line 31 ¶		skipping to change at page 6, line 31 ¶
	the challenge? Obviously, EV needs more, so a few choices are		the challenge? Obviously, EV needs more, so a few choices are
	suggested in this revision.]		suggested in this revision.]
	To improve the vetting process, ACME's optional use of CAA [RFC6844]		To improve the vetting process, ACME's optional use of CAA [RFC6844]
	with the Directory "meta" data "caaIdentities" ([RFC8555]		with the Directory "meta" data "caaIdentities" ([RFC8555]
	Section 9.7.6) assists with the validation that a CA may have issue		Section 9.7.6) assists with the validation that a CA may have issue
	certificates for any particular domain and is RECOMMENDED for use		certificates for any particular domain and is RECOMMENDED for use
	with code signing certificates for this additional level of		with code signing certificates for this additional level of
	validation checking on issued certificates.		validation checking on issued certificates.
	CAA helps as anyone verifying a certificate used for code signing can
	verify that the CA used has been authorized to issue certificates for
	that organization. CSR requests for code signing certificates
	typically contain a Common Name (CN) using a domain name that is
	replaced with the organization name to have the expected details
	displayed in the resulting certificate. Since this work flow already
	occurs, there is a path to automation and validation via an existing
	ACME type, "dns".
	As noted in RFC8555, "the external account binding feature (see		As noted in RFC8555, "the external account binding feature (see
	Section 7.3.4) can allow an ACME account to use authorizations that		Section 7.3.4) can allow an ACME account to use authorizations that
	have been granted to an external, non-ACME account. This allows ACME		have been granted to an external, non-ACME account. This allows ACME
	to address issuance scenarios that cannot yet be fully automated,		to address issuance scenarios that cannot yet be fully automated,
	such as the issuance of "Extended Validation" certificates."		such as the issuance of "Extended Validation" certificates."
	The ACME challenge object, [RFC8555] Section 7.1.5 is RECOMMENDED for		The ACME challenge object, [RFC8555] Section 7.1.5 is RECOMMENDED for
	use for Pre-authorization ([RFC8555] Section 7.4.1). Additional		use for Pre-authorization ([RFC8555] Section 7.4.1). Additional
	challenge types are added to provide higher levels of security for		challenge types are added to provide higher levels of security for
	this issuance verification step. The use of OTP, FIDO credentials		this issuance verification step. The use of OTP, FIDO credentials
	skipping to change at page 12, line 21 ¶		skipping to change at page 12, line 16 ¶
	This memo includes no request to IANA, yet.		This memo includes no request to IANA, yet.
	9. Contributors		9. Contributors
	Thank you to reviewers and contributors who helped to improve this		Thank you to reviewers and contributors who helped to improve this
	document. Thank you to Thomas Peterson who added the one-time		document. Thank you to Thomas Peterson who added the one-time
	password types, HOTP and TOTP. Thank you to Tim Hollebeek for your		password types, HOTP and TOTP. Thank you to Tim Hollebeek for your
	early review and added text specific to EV certificate issuance and		early review and added text specific to EV certificate issuance and
	one time use code signing certificates. Thank you to Andrei Popov		one time use code signing certificates. Thank you to Andrei Popov
	and Deb Cooley for your reviews and suggestions made in -04.		and Deb Cooley for your reviews and suggestions made in -04. Thank
			you to those who reviewed the CAA text removed in version -05
			including: Carl Mehner, Roland Shoemaker, Ben Schwartz, and Ryan
			Sleevi. Posted WG version. -02 updates authors email address.
	10. References		10. References
	10.1. Normative References		10.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,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and		[RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
	O. Ranen, "HOTP: An HMAC-Based One-Time Password		O. Ranen, "HOTP: An HMAC-Based One-Time Password
	Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005,		Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005,
	<https://www.rfc-editor.org/info/rfc4226>.		<https://www.rfc-editor.org/info/rfc4226>.
	[RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP:		[RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP:
	Time-Based One-Time Password Algorithm", RFC 6238,		Time-Based One-Time Password Algorithm", RFC 6238,
	DOI 10.17487/RFC6238, May 2011,		DOI 10.17487/RFC6238, May 2011,
	<https://www.rfc-editor.org/info/rfc6238>.		<https://www.rfc-editor.org/info/rfc6238>.
			[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
			"Enrollment over Secure Transport", RFC 7030,
			DOI 10.17487/RFC7030, October 2013,
			<https://www.rfc-editor.org/info/rfc7030>.
	[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>.
	[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.		[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
	Kasten, "Automatic Certificate Management Environment		Kasten, "Automatic Certificate Management Environment
	(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,		(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
	<https://www.rfc-editor.org/info/rfc8555>.		<https://www.rfc-editor.org/info/rfc8555>.
	10.2. Informative References		10.2. Informative References
	skipping to change at page 13, line 18 ¶		skipping to change at page 13, line 18 ¶
	Shoemaker, R., "ACME IP Identifier Validation Extension",		Shoemaker, R., "ACME IP Identifier Validation Extension",
	draft-ietf-acme-ip-08 (work in progress), October 2019.		draft-ietf-acme-ip-08 (work in progress), October 2019.
	10.3. URL References		10.3. URL References
	[NIST800-63A]		[NIST800-63A]
	US National Institute of Standards and Technology,		US National Institute of Standards and Technology,
	"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/		"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
	NIST.SP.800-63a.pdf".		NIST.SP.800-63a.pdf".
			[NIST800-63B]
			US National Institute of Standards and Technology,
			"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
			NIST.SP.800-63b.pdf".
	[NIST800-63C]		[NIST800-63C]
	US National Institute of Standards and Technology,		US National Institute of Standards and Technology,
	"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/		"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
	NIST.SP.800-63c.pdf".		NIST.SP.800-63c.pdf".
	[NIST800-63r3]		[NIST800-63r3]
	US National Institute of Standards and Technology,		US National Institute of Standards and Technology,
	"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/		"https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
	NIST.SP.800-63-3.pdf".		NIST.SP.800-63-3.pdf".
	skipping to change at page 14, line 26 ¶		skipping to change at page 14, line 26 ¶
	an RFC.		an RFC.
	Author's Address		Author's Address
	Kathleen M. Moriarty		Kathleen M. Moriarty
	Dell Technologies		Dell Technologies
	176 South Street		176 South Street
	Hopkinton		Hopkinton
	US		US
	EMail: Kathleen.Moriarty@dell.com		EMail: Kathleen.Moriarty.ietf@gmail.com
End of changes. 10 change blocks.
	16 lines changed or deleted		20 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/