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/