idnits 2.17.1 draft-ietf-acme-client-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (24 September 2021) is 944 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'NIST800-63r3' is mentioned on line 586, but not defined == Missing Reference: 'NIST800-63A' is mentioned on line 591, but not defined == Missing Reference: 'NIST800-63C' is mentioned on line 601, but not defined == Missing Reference: 'RFC6844' is mentioned on line 261, but not defined ** Obsolete undefined reference: RFC 6844 (Obsoleted by RFC 8659) == Missing Reference: 'NIST800-63B' is mentioned on line 596, but not defined == Unused Reference: 'RFC2119' is defined on line 546, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'RFC7030' is defined on line 570, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-acme-ip' is defined on line 577, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4226 ** Downref: Normative reference to an Informational RFC: RFC 6238 Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF K. Moriarty 3 Internet-Draft Dell Technologies 4 Intended status: Standards Track 24 September 2021 5 Expires: 28 March 2022 7 ACME End User Client and Code Signing Certificates 8 draft-ietf-acme-client-03 10 Abstract 12 Automated Certificate Management Environment (ACME) core protocol 13 addresses the use case of web server certificates for TLS. This 14 document extends the ACME protocol to support end user client, device 15 client, and code signing certificates. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 28 March 2022. 34 Copyright Notice 36 Copyright (c) 2021 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Simplified BSD License text 45 as described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Identity Proofing for Client Certificates . . . . . . . . . . 2 52 3. End User Client Certificates . . . . . . . . . . . . . . . . 3 53 4. CodeSigning Certificates . . . . . . . . . . . . . . . . . . 5 54 5. Pre-authorization . . . . . . . . . . . . . . . . . . . . . . 8 55 6. Challenge Types . . . . . . . . . . . . . . . . . . . . . . . 8 56 6.1. One Time Password (OTP) . . . . . . . . . . . . . . . . . 8 57 6.1.1. HMAC-Based One-Time Password (HOTP) . . . . . . . . . 9 58 6.1.2. Time-Based One-Time Password (TOTP) . . . . . . . . . 9 59 6.1.3. Generic One Time Password (OTP) . . . . . . . . . . . 10 60 6.2. Public Key Cryptography . . . . . . . . . . . . . . . . . 10 61 6.3. WebAuthn or Public/Private Key Pairs . . . . . . . . . . 11 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 64 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 67 10.2. Informative References . . . . . . . . . . . . . . . . . 13 68 10.3. URL References . . . . . . . . . . . . . . . . . . . . . 13 69 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 13 70 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 13 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 73 1. Introduction 75 ACME [RFC8555] is a mechanism for automating certificate management 76 on the Internet. It enables administrative entities to prove 77 effective control over resources like domain names, and automates the 78 process of generating and issuing certificates. 80 The core ACME protocol defined challenge types specific to web server 81 certificates with the possibility to create extensions, or additional 82 challenge types for other use cases and certificate types. Client 83 certificates, such as end user and code signing may also benefit from 84 automated management to ease the deployment and maintenance of these 85 certificate types, thus the definition of this extension defining 86 challenge types specific to that usage. 88 2. Identity Proofing for Client Certificates 90 As with the TLS certificates defined in the core ACME document , identity proofing for ACME issued end user 92 client, device client, and code signing certificates is a separate 93 process outside of the automation of ACME. Identity proofing may be 94 an out-of-band process, if needed, and for this draft is likely tied 95 to the credentials used for the defined challenge types. 97 Identity proofing for these certificate types present some challenges 98 for process automation. NIST SP 800-63 r3 [NIST800-63r3] serves as 99 guidance for identity proofing further detailed in NIST SP 800-63A 100 [NIST800-63A] that may occur prior to the ability to automate 101 certificate management via ACME or may obviate the need for it 102 weighing end user privacy as a higher concern and allowing for 103 credential issuance to be decoupled from identity proofing (IAL1). 104 Using this guidance, a CA might select from the identity proofing 105 levels to assert claims on the issued certificates as described in 106 NIST SP 800-63 r3 [NIST800-63r3]. 108 The certificate issuing CA may make this choice by certificate type 109 issued. Once identity proofing has been performed, in cases where 110 this is part of the process, and certificates have been issued, NIST 111 SP 800-63 r3 [NIST800-63r3] includes recommendations for 112 authentication or in the context of ACME, management of issuance for 113 subsequent client, device, or code-signing certificates: 115 If federations and assertions are used for authorizing certificate 116 issuance, NIST SP 800-63 C [NIST800-63C] may be referenced for 117 guidance on levels of assurance. 119 Existing PKI certification authorities (CAs) tend to use a set of ad 120 hoc protocols for certificate issuance and identity verification. 121 For each certificate usage type, a basic process will be described to 122 obtain an initial certificate and for the certificate renewal 123 process. If higher assurance levels are desired, the guidance from 124 NIST SP 800-63 r3 [NIST800-63r3] may be useful and out-of-band 125 identity proofing options are possible options for pre-authorization 126 challenges or notifications. 128 3. End User Client Certificates 130 A client certificate used to authenticate an end user may be used for 131 mutual authentication in TLS, EAP-TLS, or messaging. The client 132 certificate in this case may be stored in a browser, PKCS-#11 133 container, KMIP (possible, but just code signing and device client 134 certificates in practice), or another key container. To obtain an 135 end user client certificate, there are several possibilities to 136 automate authentication of an identity credential intended to be tied 137 to an end user. 139 [We need to determine if it is important in ACME to define an 140 automated method that tests the identity or the user or to just have 141 consistent credentials for the authentication challenges. The 142 credentials may be distributed through an out-of-band method that 143 involves identity proofing.] 145 [Several authentication options with identity proofing are 146 intentionally provided for review and discussion by the ACME working 147 group.] 149 A trusted federated service that ties the user to an email address 150 with a reputation of the user attached to the email may be possible. 151 One such example might be the use of a JWT signed OAuth token. 153 Risk based authentication used for identity proofing with red herring 154 questions is a third option that could utilize public information on 155 individuals to authenticate. This would be similar to the signup 156 process used in some financial applications. 158 Existing credentials - for instance, FIDO. FIDO uses a public key 159 pair and does not perform identity proofing. FIDO authentication 160 provides a different key pair to each service using FIDO for 161 authentication, which are generated at the client and registered by 162 the server. This may require using the FIDO credentials from a 163 specific service for authentication to gain ACME issued crededentials 164 (not advised based on how FIDO credentials are supposed to be used). 165 Are there instances where the same provider would issue both sets of 166 credentials? You wouldn't want to expose your FIDO credentials to a 167 different party, that's why each service has their own. Would you 168 set up a mechanism to get FIDO credentials to then obtain a 169 certificate? (What use cases would this be necessary? When do you 170 need a certificate where you already have a specific public/private 171 key pair?) This can be defined as an auth type, but should it be? 173 One-time password (OTP) authentication is a secure option. In cases 174 where a higher assurance level is needed, OTP may be a good choice 175 and many options exist today for OTP that could use an app on a phone 176 for instance tied to an existing (or newly established) password. 177 The OTP may be tied to an out-of-band process and may be associated 178 with a username/password and other accounts. 180 One consideration is to understand if the use case could just use 181 FIDO and not create anything new (ACME client certificates). FIDO 182 provides a mechanism to have unique public key pair based access for 183 client authentication to web sites and they are working on non-web. 184 Identity proofing is intentionally decoupled from authentication in 185 this model as that is in line with NIST 800-63r3 recommendations for 186 privacy protections of the user. The credential in this case is 187 authenticated and would be consistent for it's use, but the identity 188 proofing for that credential is not performed. Obviously, identity 189 proofing is more important for some services, like financial 190 applications where tying the user to the identity for access to 191 financial information is important. However, is automated identity 192 proofing important for any user certificate or should it remain 193 decoupled where it could be automated by a service offering or is 194 there a need for a standardized mechanism to support it for user 195 certificates? 197 Three methods for ACME client authentication, not identity proofing, 198 are proposed in the Challenge Type Section. 200 4. CodeSigning Certificates 202 The process to retrieve a code signing certificate is similar to that 203 of a web server certificate, with differences primarily in the CSR 204 request and the resulting certificate properties. [The storage and 205 access of a code signing certificate must be protected and is 206 typically done through hardware, a hardware security module (HSM), 207 which likely has a PKCS#11 interface. A code signing certificate may 208 either be a standard one or an extended validation (EV) certificate.] 210 For automation purposes, the process described in this document will 211 follow the standard process and any out-of-band preprocessing can 212 increase the level of the issued certificate if the CA offers such 213 options and has additional identity proofing mechanisms (in band or 214 out-of-band). 216 Strict vetting processes are necessary for many code signing 217 certificates to provide a high assurance on the signer. In some 218 cases, issuance of a standard CodeSigning certificate will be 219 appropriate and no additional "challenges" [RFC8555 Section 8] will 220 be necessary. In this case, the standard option could be automated 221 very similar to Web server certificates with the only changes being 222 in the CSR properties. However, this may not apply to all scenarios, 223 such as those requiring EV certificates with the possibility for 224 required out-of-band initial authentication and identity proofing. 226 EV code signing certificates have a distinct set of requirements from 227 EV web certificates. In particular, they don't have associated 228 domain names, nor is CAA checking done. The code signing certificate 229 links a public key to an organization, not a domain. CAs may chose 230 different methods to enable the use of ACME for EV code signing 231 certificates. The intent of this work is to provide additional 232 authentication challenge types that may enable their automation 233 process. 235 Organization validation is required for standard code signing 236 certificates from most issuers. The CSR is used to identify the 237 organization from the included domain name in the request. The 238 resulting certificate, however, instead contains the organization's 239 name and for EV certificates, other identifying information for the 240 organization. For EV certificates, this could require that the 241 domain is registered with the Certificate Authority provider, listed 242 in CAA [RFC6844], and administrators for the account are named with 243 provided portal access for certificate issuance and management 244 options. 246 While ACME allows for the client to directly establish an account 247 with a CA, an initial out-of-band process for this step may assist 248 with the additional requirements for EV certificates and assurance 249 levels typically required for code signing certificates. For 250 standard certificates, with a recommendation for additional vetting 251 through extended challenge options to enable ACME to establish the 252 account directly. In cases where code signing certificates are used 253 heavily for an organization, having the portal access replaced with 254 ACME authenticated client access with extra challenges for 255 authentication may be an option to automate the functionality. 257 [For standard certificates, is it worth defining SMS and email for 258 the challenge? Obviously, EV needs more, so a few choices are 259 suggested in this revision.] 261 To improve the vetting process, ACME's optional use of CAA [RFC6844] 262 with the Directory "meta" data "caaIdentities" ([RFC8555] 263 Section 9.7.6) assists with the validation that a CA may have issue 264 certificates for any particular domain and is RECOMMENDED for use 265 with code signing certificates for this additional level of 266 validation checking on issued certificates. 268 As noted in RFC8555, "the external account binding feature (see 269 Section 7.3.4) can allow an ACME account to use authorizations that 270 have been granted to an external, non-ACME account. This allows ACME 271 to address issuance scenarios that cannot yet be fully automated, 272 such as the issuance of "Extended Validation" certificates." 274 The ACME challenge object, [RFC8555] Section 7.1.5 is RECOMMENDED for 275 use for Pre-authorization ([RFC8555] Section 7.4.1). Additional 276 challenge types are added to provide higher levels of security for 277 this issuance verification step. The use of OTP, FIDO credentials 278 (public/private key pairs), or validation from a certificate issued 279 at account setup time are defined in Section 8. Pre-Authoriziation. 281 Questions for reviewers: 283 [Is there interest to set a specific or default challenge object for 284 CodeSigning Certificates? Or should this be left to individual CAs 285 to decide and differentiate? The current challenge types defined in 286 RFC8555 include HTTPS (provisioning HTTP resources) and DNS 287 (provisioning a TXT resource record). Use of DNS may be possible, 288 but the HTTP resource doesn't necessarily make sense. Since the 289 process to retrieve an EV CodeSigning certificate usually requires 290 proof of the organization and validation from one of 2 named 291 administrators, some other challenge type like public/private key 292 pairs or OTP may be needed as defined challenge types. An 293 organization may want to tie this contact to a role rather than a 294 person and that consideration should be made in the design as well as 295 implementation by organizations.] 297 ACME provides an option for notification of the operator via email or 298 SMS upon issuance/renewal of a certificate after the domain has been 299 validated as owned by the requestor. This option is RECOMMENDED due 300 to the security considerations of code signing certificates as a way 301 to limit or reduce the possibility of a third party gaining access to 302 a code signing certificate inappropriately. Development of 303 additional challenge types is included in this document to support 304 this for pre-authorization, which would better match the security 305 considerations for this certificate type. Additional types may be 306 added if agreed upon by the working group. 308 Since DNS is used to identify the organization in the request, the 309 identifier "type" ([RFC8555]Section 7.4) is set to dns, not requiring 310 any additions to the ACME protocol for this type of certificate. The 311 distinction lies in the CSR, where the values are set to request a 312 CodeSigning certificate for a client certificate. [Question: Is it 313 helpful to define an identifier for the administrator or for the 314 developer to distinguish the certificate type in ACME and not just 315 the CSR?] 317 KeyUsage (DigitalSignature) and ExtendedKeyUsage (CodeSigning) in the 318 CSR MUST be set to the correct values for the CA to see the request 319 is for a Code Signing certificate. The Enhanced Key Usage SHOULD be 320 set to show this is a client certificate., using OID 321 "1.3.6.1.5.5.7.3.2". The CN MUST be set to the expected registered 322 domain with the CA account. 324 An advantage of ACME is the ability to automate rollover to allow for 325 easy management of short expiry times on certificates. The lifetime 326 of CodeSigning certificates is typically a year or two, but 327 automation could allow for shorter expiry times becoming feasible. 328 However, lifetimes are less of an issue for code signing certificates 329 than other certificate types. however there is a legitmate case for 330 "one signature per certificate." Automation might be helpful in this 331 case if patches or software updates were frequent or to minimize the 332 knowledge needed for the organization using this method. 334 Automation of storage to an HSM, which typically requires 335 authentication is intentionally left out-of-scope. 337 5. Pre-authorization 339 Additional challenge types are defined here for the verification of 340 administrators at an organization requesting CodeSigning 341 certificates. SMS and email are listed as possible in RFC8555 and 342 may be used singularly or in combination as the ACME protocol allows 343 for multiple pre-authorization challenges to be issued. Additional 344 pre-authorization types are defined that provide a higher level of 345 assurance to authorize a request. 347 6. Challenge Types 349 The challenge types defined in the following subsections are to 350 authenticate individuals or holders of specific pre-issued 351 credentials (users acting in roles for an organization). The 352 challenge types can be used to obtain end user certificate types or 353 as a pre-authorization challenges with certificate types such as the 354 Code Signing Certificate. Please note that the pre-authorization 355 challenge is also coupled with the account certificate in ACME for 356 verification. The process for obtaining EV Code Signing Certificates 357 typically requires authorization from one or more individuals in a 358 role for the organization. The use of pre-issued secure credentials, 359 at an assurance level appropriate for the certificate type being 360 issued, provides a way to automate the issuance and renewal process. 362 6.1. One Time Password (OTP) 364 There are numerous one time password technologies with slight 365 variations between implementations. The response to the challenge is 366 entered in the provided URL, offering flexibility to those using this 367 challenge type to acomodate the specific requirements of their 368 solution. Looking at 2 OTP solutions, the challenge response is 369 provided via a tool or app without any user interaction of 370 information required from the server to generate the challenge. The 371 2 solutions that operate in this manner include SecureID and Duo 372 Security. If a challenge is required to generate the response to be 373 provided in the URL, the token can supply the challenge. 375 type (required, string): The string "otp-01". 377 token (required, string): A random value that uniquely identifies 378 the challenge. OTP types and input vary between technologies. 379 The token value will match the type expected for the pre-issued 380 OTP credential. The user will be able to supply a response in the 381 provided URL from this challenge. It MUST NOT contain any 382 characters outside the base64url alphabet and MUST NOT include 383 base64 padding characters ("="). 385 { 386 "type": "otp-01", 387 "url": "https://example.com/acme/chall/WrV_H87EyD3", 388 "status": "pending", 389 "token": "challenge" 390 } 392 6.1.1. HMAC-Based One-Time Password (HOTP) 394 HOTP([RFC4226]) describes an algorithm for the generation of time- 395 based password values. 397 type (required, string): The string "hotp-01". 399 token (required, string): The HOTP value. This SHOULD be the 6 400 digit representation. 402 { 403 "type": "hotp-01", 404 "url": "https://example.com/acme/chall/WrV_H87EyD3", 405 "status": "pending", 406 "token": "123456" 407 } 409 6.1.2. Time-Based One-Time Password (TOTP) 411 TOTP([RFC6238]) describes an algorithm for the generation of time- 412 based password values, an extension from HOTP. 414 type (required, string): The string "totp-01". 416 token (required, string): The TOTP value. This SHOULD be the 6 417 digit representation. 419 { 420 "type": "totp-01", 421 "url": "https://example.com/acme/chall/WrV_H87EyD3", 422 "status": "pending", 423 "token": "123456" 424 } 426 6.1.3. Generic One Time Password (OTP) 428 There are numerous other one time password technologies with slight 429 variations between implementations. The response to the challenge is 430 entered in the provided URL, offering flexibility to those using this 431 challenge type to acomodate the specific requirements of their 432 solution. Looking at 2 OTP solutions, the challenge response is 433 provided via a tool or app without any user interaction of 434 information required from the server to generate the challenge. The 435 2 solutions that operate in this manner include SecureID and Duo 436 Security. If a challenge is required to generate the response to be 437 provided in the URL, the token can supply the challenge. 439 type (required, string): The string "otp-01". 441 token (required, string): A random value that uniquely identifies 442 the challenge. OTP types and input vary between technologies. 443 The token value will match the type expected for the pre-issued 444 OTP credential. The user will be able to supply a response in the 445 provided URL from this challenge. It MUST NOT contain any 446 characters outside the base64url alphabet and MUST NOT include 447 base64 padding characters ("="). 449 { 450 "type": "otp-01", 451 "url": "https://example.com/acme/chall/WrV_H87EyD3", 452 "status": "pending", 453 "token": "challenge" 454 } 456 6.2. Public Key Cryptography 458 Certificates may be pre-issued and stored according to assurance 459 level requirements for the purpose of identifying a user's identity. 460 If a higher assurance level is needed for a user serving in a 461 specific role or for that individual, it is possible for identity 462 proofing to occur in person using identifiers acceptable for the 463 specified process and the private key stored appropriately for the 464 required assurance level. PKCS#11 software or hardware tokens are 465 both possible options. This model assumes that there may be multiple 466 authorized users with different certificates that can be used for the 467 authorization or pre-authentication challenge. As such, the user 468 first provides the digital signature, so the account management can 469 determine if one of the acceptable certificates was used to digitally 470 sign the token. 472 type (required, string): The string "cert-01". 474 token (required, string): A random value that uniquely identifies 475 the challenge. The token for a certificate authentication 476 challenge includes a value for the recipeint to digitally sign 477 using their private key and post to the provided URL. The ACME 478 server then uses the digitally signed content to verify that the 479 challenge was signed using authorized credentials (certificate 480 issued and authorized for this challenge type). It MUST NOT 481 contain any characters outside the base64url alphabet and MUST NOT 482 include base64 padding characters ("="). 484 { 485 "type": "cert-01", 486 "url": "https://example.com/acme/chall/WrV_H87EyD3", 487 "status": "pending", 488 "token": "Some challenge to digitally sign" 489 } 491 6.3. WebAuthn or Public/Private Key Pairs 493 W3C's WebAuthn uses raw public/private key pairs that are issued 494 specific to a service. If WebAuthn or public/private key pairs 495 (PPKP) are selected as the challenge type, the account and credential 496 issuance will have to occur prior to use of this challenge type. The 497 WebAuthn or public/private key pair credentials would be specific to 498 the certificate management account and would be created by the 499 client, then registered with the service as occurs with normal 500 WebAuthn regisration of credentials. As with normal WebAuthn and 501 public/private key pairs, the token or challenge is digitally signed 502 to prove possession of the private key. 504 type (required, string): The string "ppkp-01". 506 token (required, string): A random value that uniquely identifies 507 the challenge. This challenge will operate much in the same way 508 as the certificate challenge as the operations are largely the 509 same. The user will be able to supply a response in the provided 510 URL from this challenge. It MUST NOT contain any characters 511 outside the base64url alphabet and MUST NOT include base64 padding 512 characters ("="). 514 { 515 "type": "ppkp-01", 516 "url": "https://example.com/acme/chall/WrV_H87EyD3", 517 "status": "pending", 518 "token": "Some challenge to sign" 519 } 521 7. Security Considerations 523 This will likely be full of considerations and is TBD for this 524 revision until challenge types are settled. 526 8. IANA Considerations 528 This memo includes no request to IANA, yet. 530 9. Contributors 532 Thank you to reviewers and contributors who helped to improve this 533 document. Thank you to Thomas Peterson who added the one-time 534 password types, HOTP and TOTP. Thank you to Tim Hollebeek for your 535 early review and added text specific to EV certificate issuance and 536 one time use code signing certificates. Thank you to Andrei Popov 537 and Deb Cooley for your reviews and suggestions made in -04. Thank 538 you to those who reviewed the CAA text removed in version -05 539 including: Carl Mehner, Roland Shoemaker, Ben Schwartz, and Ryan 540 Sleevi. Posted WG version. -02 updates authors email address. 542 10. References 544 10.1. Normative References 546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14, RFC 2119, 548 DOI 10.17487/RFC2119, March 1997, 549 . 551 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 552 O. Ranen, "HOTP: An HMAC-Based One-Time Password 553 Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, 554 . 556 [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: 557 Time-Based One-Time Password Algorithm", RFC 6238, 558 DOI 10.17487/RFC6238, May 2011, 559 . 561 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 562 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 563 May 2017, . 565 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 566 Kasten, "Automatic Certificate Management Environment 567 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 568 . 570 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 571 "Enrollment over Secure Transport", RFC 7030, 572 DOI 10.17487/RFC7030, October 2013, 573 . 575 10.2. Informative References 577 [I-D.ietf-acme-ip] 578 Shoemaker, R. B., "Automated Certificate Management 579 Environment (ACME) IP Identifier Validation Extension", 580 Work in Progress, Internet-Draft, draft-ietf-acme-ip-08, 1 581 October 2019, . 584 10.3. URL References 586 [NIST800-63r3] 587 US National Institute of Standards and Technology, 588 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 589 NIST.SP.800-63-3.pdf". 591 [NIST800-63A] 592 US National Institute of Standards and Technology, 593 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 594 NIST.SP.800-63a.pdf". 596 [NIST800-63B] 597 US National Institute of Standards and Technology, 598 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 599 NIST.SP.800-63b.pdf". 601 [NIST800-63C] 602 US National Institute of Standards and Technology, 603 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 604 NIST.SP.800-63c.pdf". 606 Appendix A. Change Log 608 Note to RFC Editor: if this document does not obsolete an existing 609 RFC, please remove this appendix before publication as an RFC. 611 02 draft added subsections contributed from Thomas Peterson on HOTP 612 and TOTP. 614 Appendix B. Open Issues 616 Note to RFC Editor: please remove this appendix before publication as 617 an RFC. 619 Author's Address 621 Kathleen M. Moriarty 622 Dell Technologies 623 176 South Street 624 Hopkinton, 625 United States of America 627 Email: Kathleen.Moriarty.ietf@gmail.com