--- 1/draft-ietf-acme-client-01.txt 2020-10-05 09:13:43.317782777 -0700 +++ 2/draft-ietf-acme-client-02.txt 2020-10-05 09:13:43.349783593 -0700 @@ -1,18 +1,18 @@ IETF K. Moriarty Internet-Draft Dell Technologies -Intended status: Standards Track May 18, 2020 -Expires: November 19, 2020 +Intended status: Standards Track October 5, 2020 +Expires: April 8, 2021 ACME End User Client and Code Signing Certificates - draft-ietf-acme-client-01 + draft-ietf-acme-client-02 Abstract Automated Certificate Management Environment (ACME) core protocol addresses the use case of web server certificates for TLS. This document extends the ACME protocol to support end user client, device client, and code signing certificates. Status of This Memo @@ -22,21 +22,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -50,24 +50,24 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Identity Proofing for Client Certificates . . . . . . . . . . 2 3. End User Client Certificates . . . . . . . . . . . . . . . . 3 4. CodeSigning Certificates . . . . . . . . . . . . . . . . . . 5 5. Pre-authorization . . . . . . . . . . . . . . . . . . . . . . 8 6. Challenge Types . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. One Time Password (OTP) . . . . . . . . . . . . . . . . . 8 6.1.1. HMAC-Based One-Time Password (HOTP) . . . . . . . . . 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.3. WebAuthn or Public/Private Key Pairs . . . . . . . . . . 11 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 13 10.3. URL References . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 @@ -259,29 +259,20 @@ the challenge? Obviously, EV needs more, so a few choices are suggested in this revision.] To improve the vetting process, ACME's optional use of CAA [RFC6844] with the Directory "meta" data "caaIdentities" ([RFC8555] Section 9.7.6) assists with the validation that a CA may have issue certificates for any particular domain and is RECOMMENDED for use with code signing certificates for this additional level of 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 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 to address issuance scenarios that cannot yet be fully automated, such as the issuance of "Extended Validation" certificates." The ACME challenge object, [RFC8555] Section 7.1.5 is RECOMMENDED for use for Pre-authorization ([RFC8555] Section 7.4.1). Additional challenge types are added to provide higher levels of security for this issuance verification step. The use of OTP, FIDO credentials @@ -537,41 +528,49 @@ This memo includes no request to IANA, yet. 9. Contributors Thank you to reviewers and contributors who helped to improve this document. Thank you to Thomas Peterson who added the one-time password types, HOTP and TOTP. Thank you to Tim Hollebeek for your early review and added text specific to EV certificate issuance and 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.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and O. Ranen, "HOTP: An HMAC-Based One-Time Password Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, . [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: Time-Based One-Time Password Algorithm", RFC 6238, DOI 10.17487/RFC6238, May 2011, . + [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., + "Enrollment over Secure Transport", RFC 7030, + DOI 10.17487/RFC7030, October 2013, + . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . 10.2. Informative References @@ -580,20 +579,25 @@ Shoemaker, R., "ACME IP Identifier Validation Extension", draft-ietf-acme-ip-08 (work in progress), October 2019. 10.3. URL References [NIST800-63A] US National Institute of Standards and Technology, "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 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] US National Institute of Standards and Technology, "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-63c.pdf". [NIST800-63r3] US National Institute of Standards and Technology, "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ NIST.SP.800-63-3.pdf". @@ -611,11 +615,11 @@ an RFC. Author's Address Kathleen M. Moriarty Dell Technologies 176 South Street Hopkinton US - EMail: Kathleen.Moriarty@dell.com + EMail: Kathleen.Moriarty.ietf@gmail.com