idnits 2.17.1 draft-moriarty-acme-client-02.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 (August 19, 2019) is 1712 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 669, but not defined == Missing Reference: 'NIST800-63A' is mentioned on line 654, but not defined == Missing Reference: 'NIST800-63B' is mentioned on line 659, but not defined == Missing Reference: 'NIST800-63C' is mentioned on line 664, but not defined == Missing Reference: 'RFC6844' is mentioned on line 334, but not defined ** Obsolete undefined reference: RFC 6844 (Obsoleted by RFC 8659) == Unused Reference: 'RFC2119' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'RFC7030' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 637, 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 == Outdated reference: A later version (-08) exists of draft-ietf-acme-ip-06 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 EMC 4 Intended status: Standards Track August 19, 2019 5 Expires: February 20, 2020 7 ACME End User Client and Code Signing Certificates 8 draft-moriarty-acme-client-02 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 February 20, 2020. 34 Copyright Notice 36 Copyright (c) 2019 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 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Identity Proofing for Client Certificates . . . . . . . . . . 2 53 3. Device Certificates . . . . . . . . . . . . . . . . . . . . . 4 54 4. End User Client Certificates . . . . . . . . . . . . . . . . 5 55 5. CodeSigning Certificates . . . . . . . . . . . . . . . . . . 6 56 6. Pre-authorization . . . . . . . . . . . . . . . . . . . . . . 9 57 7. Challenge Types . . . . . . . . . . . . . . . . . . . . . . . 9 58 7.1. One Time Password (OTP) . . . . . . . . . . . . . . . . . 10 59 7.1.1. HMAC-Based One-Time Password (HOTP) . . . . . . . . . 10 60 7.1.2. Time-Based One-Time Password (TOTP) . . . . . . . . . 11 61 7.1.3. Generic One Time Password (OTP) . . . . . . . . . . . 11 62 7.2. Certificate . . . . . . . . . . . . . . . . . . . . . . . 12 63 7.3. FIDO or Public/Private Key Pairs . . . . . . . . . . . . 12 64 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 66 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 69 11.2. Informative References . . . . . . . . . . . . . . . . . 14 70 11.3. URL References . . . . . . . . . . . . . . . . . . . . . 14 71 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16 72 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 16 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 75 1. Introduction 77 ACME [RFC8555] is a mechanism for automating certificate management 78 on the Internet. It enables administrative entities to prove 79 effective control over resources like domain names, and automates the 80 process of generating and issuing certificates. 82 The core ACME protocol defined challenge types specific to web server 83 certificates with the possibility to create extensions, or additional 84 challenge types for other use cases and certificate types. Client 85 certificates, such as end user and Code SIgning may also benefit from 86 automated management to ease the deployment and maintenance of these 87 certificates type, thus the definition of this extension defining 88 challenge types specific to that usage. 90 2. Identity Proofing for Client Certificates 92 As with the TLS certificates defined in the core ACME document, 93 identity proofing for ACME issued end user client, device client, and 94 code signing certificates was not covered in RFC8555. 96 Identity proofing for these certificate types present some challenges 97 for process automation. NIST SP 800-63 r3 [NIST800-63r3] serves as 98 guidance for identity proofing further detailed in NIST SP 800-63A 99 [NIST800-63A] that may occur prior to the ability to automate 100 certificate management via ACME or may obviate the need for it 101 weighing end user privacy as a higher concern and allowing for 102 credential issuance to be decoupled from identity proofing (IAL1). 103 Using this guidance, a CA might select from the identity proofing 104 levels to assert claims on the issued certificates as follows from 105 NIST SP 800-63 r3 [NIST800-63r3]: 107 "IAL1: There is no requirement to link the applicant to a specific 108 real-life identity. Any attributes provided in conjunction with the 109 authentication process are self-asserted or should be treated as such 110 (including attributes a Credential Service Provider, or CSP, asserts 111 to an RP). 113 IAL2: Evidence supports the real-world existence of the claimed 114 identity and verifies that the applicant is appropriately associated 115 with this real-world identity. IAL2 introduces the need for either 116 remote or physically-present identity proofing. Attributes can be 117 asserted by CSPs to RPs in support of pseudonymous identity with 118 verified attributes. 120 IAL3: Physical presence is required for identity proofing. 121 Identifying attributes must be verified by an authorized and trained 122 representative of the CSP. As with IAL2, attributes can be asserted 123 by CSPs to RPs in support of pseudonymous identity with verified 124 attributes." 126 The certificate issuing CA may make this choice by certificate type 127 issued. Once identity proofing has been performed, in cases where 128 this is part of the process, and certificates have been issued, NIST 129 SP 800-63 r3 [NIST800-63r3] has the following recommendations for 130 authentication or in the context of ACME, management of issuance for 131 subsequent client, device, or code-signing certificates: 133 "For services in which return visits are applicable, a successful 134 authentication provides reasonable risk-based assurances that the 135 subscriber accessing the service today is the same as that which 136 accessed the service previously. The robustness of this confidence 137 is described by an AAL categorization. NIST SP 800-63 B 138 [NIST800-63B] addresses how an individual can securely authenticate 139 to a CSP to access a digital service or set of digital services. SP 140 800-63B contains both normative and informative material. 142 The three AALs define the subsets of options agencies can select 143 based on their risk profile and the potential harm caused by an 144 attacker taking control of an authenticator and accessing agencies? 145 systems. The AALs are as follows: 147 AAL1: AAL1 provides some assurance that the claimant controls an 148 authenticator bound to the subscriber's account. AAL1 requires 149 either single-factor or multi-factor authentication using a wide 150 range of available authentication technologies. Successful 151 authentication requires that the claimant prove possession and 152 control of the authenticator through a secure authentication 153 protocol. 155 AAL2: AAL2 provides high confidence that the claimant controls 156 authenticator(s) bound to the subscriber's account. Proof of 157 possession and control of two distinct authentication factors is 158 required through secure authentication protocol(s). Approved 159 cryptographic techniques are required at AAL2 and above. 161 AAL3: AAL3 provides very high confidence that the claimant controls 162 authenticator(s) bound to the subscriber's account. Authentication 163 at AAL3 is based on proof of possession of a key through a 164 cryptographic protocol. AAL3 authentication SHALL use a hardware- 165 based authenticator and an authenticator that provides verifier 166 impersonation resistance; the same device MAY fulfill both these 167 requirements. In order to authenticate at AAL3, claimants SHALL 168 prove possession and control of two distinct authentication factors 169 through secure authentication protocol(s). Approved cryptographic 170 techniques are required." 172 If federations and assertions are used for authorizing certificate 173 issuance, NIST SP 800-63 C [NIST800-63C] may be referenced for 174 guidance on levels of assurance. 176 Existing PKI certification authorities (CAs) tend to use a set of ad 177 hoc protocols for certificate issuance and identity verification. 178 For each certificate usage type, a basic process will be described to 179 obtain an initial certificate and for the certificate renewal 180 process. If higher assurance levels are desired, the guidance from 181 NIST SP 800-63 r3 [NIST800-63r3] may be useful and out-of-band 182 identity proofing options are possible options for pre-authorization 183 challenges or notifications. 185 3. Device Certificates 187 A device certificate is a client certificate issued to a device 188 identified through device credentials such as an IP address, 189 hostname, or MAC address. This process is separate from an end user 190 client certificate that may be stored on a device, but identifies a 191 person using the device described in the next subsection. While 192 there are automated processes in place today for device certificate 193 renewal, most are specific to the CA and not open standards. The 194 general workflow is similar to that described in RFC8555 with the 195 differences being in the CSR, requesting a client certificate. [IP 196 addresses may be necessary for some devices and it may be best to 197 extend [I-D.ietf-acme-ip] to cover varying CSR types that include 198 client certificates for devices explicitly.] 200 A typical process to obtain a device certificate may be similar to 201 the following workflow described in the introduction of RFC8555 with 202 the exception of certificate type and usage. 204 [There is some work happening in possibly 2 different drafts on 205 device certificates, so no further definition is provided here at 206 this time.] 208 [Is an additional type definition helpful to distinguish that this is 209 for a client certificate?] 211 4. End User Client Certificates 213 A client certificate used to authenticate an end user may be used for 214 mutual authentication in TLS, EAP-TLS, or messaging. The client 215 certificate in this case may be stored in a browser, PKCS-#11 216 container, KMIP, or another key container. To obtain an end user 217 client certificate, there are several possibilities to automate 218 authentication of an identity credential presumably tied to an end 219 user. 221 [We need to determine if it is important in ACME to define an 222 automated method that tests the identity or the user or to just have 223 consistent credentials for the authentication challenges. The 224 credentials may be distributed through an out-of-band method that 225 involves identity proofing.] 227 [Several authentication options with identity proofing are 228 intentionally provided for review and discussion by the ACME working 229 group.] 231 A trusted federated service that ties the user to an email address 232 with a reputation of the user attached to the email may be possible. 233 One such example might be the use of a JWT signed OAuth token. 235 Risk based authentication used for identity proofing with red herring 236 questions is a third option that could utilize public information on 237 individuals to authenticate. This would be similar to the signup 238 process used in some financial applications. 240 Existing credentials - for instance, FIDO. FIDO uses a public key 241 pair and does not perform identity proofing. FIDO authentication 242 provides a different key pair to each service using FIDO for 243 authentication, which are generated at the client and registered by 244 the server. This may require using the FIDO credentials from a 245 specific service for authentication to gain ACME issued crededentials 246 (not advised based on how FIDO credentials are supposed to be used). 247 Are there instances where the same provider would issue both sets of 248 credentials? You wouldn't want to expose your FIDO credentials to a 249 different party, that's why each service has their own. Would you 250 set up a mechanism to get FIDO credentials to then obtain a 251 certificate? (What use cases would this be necessary? When do you 252 need a certificate where you already have a specific public/private 253 key pair?) This can be defined as an auth type, but should it be? 255 One-time password (OTP) authentication is a secure option. In cases 256 where a higher assurance level is needed, OTP may be a good choice 257 and many options exist today for OTP that could use an app on a phone 258 for instance tied to an existing (or newly established) password. 259 The OTP may be tied to an out-of-band process and may be associated 260 with a username/password and other accounts. 262 One consideration is to understand if the use case could just use 263 FIDO and not create anything new (ACME client certificates). FIDO 264 provides a mechanism to have unique public key pair based access for 265 client authentication to web sites and they are working on non-web. 266 Identity proofing is intentionally decoupled from authentication in 267 this model as that is in line with NIST 800-63r3 recommendations for 268 privacy protections of the user. The credential in this case is 269 authenticated and would be consistent for it's use, but the identity 270 proofing for that credential is not performed. Obviously, identity 271 proofing is more important for some services, like financial 272 applications where tying the user to the identity for access to 273 financial information is important. However, is automated identity 274 proofing important for any user certificate or should it remain 275 decoupled where it could be automated by a service offering or is 276 there a need for a standardized mechanism to support it for user 277 certificates? 279 Three methods for ACME client authentication, not identity proofing, 280 are proposed in the Challenge Type Section. 282 5. CodeSigning Certificates 284 The process to retrieve a code signing certificate is similar to that 285 of a web server certificate, with differences primarily in the CSR 286 request and the resulting certificate properties. [The storage and 287 access of a code signing certificate must be protected and is 288 typically done through hardware, a hardware security module (HSM), 289 which likely has a PKCS#11 interface. A code signing certificate may 290 either be a standard one or an extended validation (EV) certificate.] 292 For automation purposes, the process described in this document will 293 follow the standard process and any out-of-band preprocessing can 294 increase the level of the issued certificate if the CA offers such 295 options and has additional identity proofing mechanisms (in band or 296 out-of-band). 298 Strict vetting processes are necessary for many code signing 299 certificates to provide a high assurance on the signer. In some 300 cases, issuance of a standard CodeSigning certificate will be 301 appropriate and no additional "challenges" [RFC8555 Section 8] will 302 be necessary. In this case, the standard option could be automated 303 very similar to Web server certificates with the only changes being 304 in the CSR properties. However, this may not apply to all scenarios, 305 such as those requiring EV certificates with the possibility for 306 required out-of-band initial authentication and identity proofing. 308 Organization validation is required for standard code signing 309 certificates from most issuers. The CSR is used to identify the 310 organization from the included domain name in the request. The 311 resulting certificate, however, instead contains the organization's 312 name and for EV certificates, other identifying information for the 313 organization. For EV certificates, this typically requires that the 314 domain is registered with the Certificate Authority provider, listed 315 in CAA [RFC6844], and administrators for the account are named with 316 provided portal access for certificate issuance and management 317 options. 319 While ACME allows for the client to directly establish an account 320 with a CA, an initial out-of-band process for this step may assist 321 with the additional requirements for EV certificates and assurance 322 levels typically required for code signing certificates. For 323 standard certificates, with a recommendation for additional vetting 324 through extended challenge options to enable ACME to establish the 325 account directly. In cases where code signing certificates are used 326 heavily for an organization, having the portal access accessible 327 replaced with ACME authenticated client access with extra challenges 328 for authentication may be an option to automate the functionality. 330 [For standard certificates, is it worth defining SMS and email for 331 the challenge? Obviously, EV needs more, so a few choices are 332 suggested in this revision.] 334 To improve the vetting process, ACME's optional use of CAA [RFC6844] 335 with the Directory "meta" data "caaIdentities" ([RFC8555] 336 Section 9.7.6) assists with the validation that a CA may have issue 337 certificates for any particular domain and is RECOMMENDED for use 338 with code signing certificates for this additional level of 339 validation checking on issued certificates. 341 CAA helps as anyone verifying a certificate used for code signing can 342 verify that the CA used has been authorized to issue certificates for 343 that organization. CSR requests for code signing certificates 344 typically contain a Common Name (CN) using a domain name that is 345 replaced with the organization name to have the expected details 346 displayed in the resulting certificate. Since this work flow already 347 occurs, there is a path to automation and validation via an existing 348 ACME type, "dns". 350 As noted in RFC8555, "the external account binding feature (see 351 Section 7.3.4) can allow an ACME account to use authorizations that 352 have been granted to an external, non-ACME account. This allows ACME 353 to address issuance scenarios that cannot yet be fully automated, 354 such as the issuance of "Extended Validation" certificates." 356 The ACME challenge object, [RFC8555] Section 7.1.5 is RECOMMENDED for 357 use for Pre-authorization ([RFC8555] Section 7.4.1). Additional 358 challenge types are added to provide higher levels of security for 359 this issuance verification step. The use of OTP, FIDO credentials 360 (public/private key pairs), or validation from a certificate issued 361 at account setup time are defined in Section 8. Pre-Authoriziation. 363 Questions for reviewers: 365 [Is there interest to set a specific or default challenge object for 366 CodeSigning Certificates? Or should this be left to individual CAs 367 to decide and differentiate? The current challenge types defined in 368 RFC8555 include HTTPS (provisioning HTTP resources) and DNS 369 (provisioning a TXT resource record). Use of DNS may be possible, 370 but the HTTP resource doesn't necessarily make sense. Since the 371 process to retrieve an EV CodeSigning certificate usually requires 372 proof of the organization and validation from one of 2 named 373 administrators, some other challenge type like public/private key 374 pairs or OTP may be needed as defined challenge types. An 375 organization may want to tie this contact to a role rather than a 376 person and that consideration should be made in the design as well as 377 implementation by organizations.] 379 ACME provides an option for notification of the operator via email or 380 SMS upon issuance/renewal of a certificate after the domain has been 381 validated as owned by the requestor. This option is RECOMMENDED due 382 to the security considerations of code signing certificates as a way 383 to limit or reduce the possibility of a third party gaining access to 384 a code signing certificate inappropriately. Development of 385 additional challenge types is included in this document to support 386 this for pre-authorization, which would better match the security 387 considerations for this certificate type. Additional types may be 388 added if agreed upon by the working group. 390 Since DNS is used to identify the organization in the request, the 391 identifier "type" ([RFC8555]Section 7.4) is set to dns, not requiring 392 any additions to the ACME protocol for this type of certificate. The 393 distinction lies in the CSR, where the values are set to request a 394 CodeSigning certificate for a client certificate. [Question: Is it 395 helpful to define an identifier for the administrator or for the 396 developer to distinguish the certificate type in ACME and not just 397 the CSR?] 399 KeyUsage (DigitalSignature) and ExtendedKeyUsage (CodeSigning) in the 400 CSR MUST be set to the correct values for the CA to see the request 401 is for a Code Signing certificate. The Enhanced Key Usage SHOULD be 402 set to show this is a client certificate., using OID 403 "1.3.6.1.5.5.7.3.2". The CN MUST be set to the expected registered 404 domain with the CA account. 406 An advantage of ACME is the ability to automate rollover to allow for 407 easy management of short expiry times on certificates. The lifetime 408 of CodeSigning certificates is typically a year or two, but 409 automation could allow for shorter expiry times becoming feasible. 411 Automation of storage to an HSM, which typically requires 412 authentication is intentionally left out-of-scope. 414 6. Pre-authorization 416 Additional challenge types are defined here for the verification of 417 administrors at an organization requesting CodeSigning certificates. 418 SMS and email are both defined and may be used singularly or in 419 combination as the ACME protocol allows for multiple pre- 420 authorization challenges to be issued. Additional pre-authorization 421 types are defined that provide a higher level of assurance to 422 authorize a request. 424 7. Challenge Types 426 The challenge types are defined in the following subsections are for 427 use to authenticate individuals or holders of specific pre-issued 428 credentials (users acting in roles for an organization). The 429 challenge types can be used to obtain end user certificate types or 430 as a pre-authorization challenges with certificate types such as the 431 Code Signing Certificate. Please note that the pre-authorization 432 challenge is also coupled with the account certificate in ACME for 433 verification. The process for obtaining EV Code Signing Certificates 434 typically requires authorization from one or more individuals in a 435 role for the organization. The use of pre-issued secure credentials, 436 at an assurance level appropriate for the certificate type being 437 issued, provides a way to automate the issuance and renewal process. 439 7.1. One Time Password (OTP) 441 There are numerous one time password technologies with slight 442 variations between implementations. The response to the challenge is 443 entered in the provided URL, offering flexibility to those using this 444 challenge type to acomodate the specific requirements of their 445 solution. Looking at 2 OTP solutions, the challenge response is 446 provided via a tool or app without any user interaction of 447 information required from the server to generate the challenge. The 448 2 solutions that operate in this manner include SecureID and Duo 449 Security. If a challenge is required to generate the response to be 450 provided in the URL, the token can supply the challenge. 452 type (required, string): The string "otp-01". 454 token (required, string): A random value that uniquely identifies 455 the challenge. OTP types and input vary between technologies. 456 The token value will match the type expected for the pre-issued 457 OTP credential. The user will be able to supply a response in the 458 provided URL from this challenge. It MUST NOT contain any 459 characters outside the base64url alphabet and MUST NOT include 460 base64 padding characters ("="). 462 { 463 "type": "otp-01", 464 "url": "https://example.com/acme/chall/WrV_H87EyD3", 465 "status": "pending", 466 "token": "challenge" 467 } 469 7.1.1. HMAC-Based One-Time Password (HOTP) 471 HOTP([RFC4226]) describes an algorithm for the generation of time- 472 based password values. 474 type (required, string): The string "hotp-01". 476 token (required, string): The HOTP value. This SHOULD be the 6 477 digit representation. 479 { 480 "type": "hotp-01", 481 "url": "https://example.com/acme/chall/WrV_H87EyD3", 482 "status": "pending", 483 "token": "123456" 484 } 486 7.1.2. Time-Based One-Time Password (TOTP) 488 TOTP([RFC6238]) describes an algorithm for the generation of time- 489 based password values, an extension from HOTP. 491 type (required, string): The string "totp-01". 493 token (required, string): The TOTP value. This SHOULD be the 6 494 digit representation. 496 { 497 "type": "totp-01", 498 "url": "https://example.com/acme/chall/WrV_H87EyD3", 499 "status": "pending", 500 "token": "123456" 501 } 503 7.1.3. Generic One Time Password (OTP) 505 There are numerous other one time password technologies with slight 506 variations between implementations. The response to the challenge is 507 entered in the provided URL, offering flexibility to those using this 508 challenge type to acomodate the specific requirements of their 509 solution. Looking at 2 OTP solutions, the challenge response is 510 provided via a tool or app without any user interaction of 511 information required from the server to generate the challenge. The 512 2 solutions that operate in this manner include SecureID and Duo 513 Security. If a challenge is required to generate the response to be 514 provided in the URL, the token can supply the challenge. 516 type (required, string): The string "otp-01". 518 token (required, string): A random value that uniquely identifies 519 the challenge. OTP types and input vary between technologies. 520 The token value will match the type expected for the pre-issued 521 OTP credential. The user will be able to supply a response in the 522 provided URL from this challenge. It MUST NOT contain any 523 characters outside the base64url alphabet and MUST NOT include 524 base64 padding characters ("="). 526 { 527 "type": "otp-01", 528 "url": "https://example.com/acme/chall/WrV_H87EyD3", 529 "status": "pending", 530 "token": "challenge" 531 } 533 7.2. Certificate 535 Certificates may be pre-issued and stored according to assurance 536 level requirements for the purpose of identiying a user's identity. 537 If a higher assurance level is needed for a user serving in a 538 specific role or for that individual, it is posisble for identity 539 proofing to occur in person using identifiers acceptable for the 540 specified process and then stored appropriately for the required 541 assurance level. PKCS#11 software or hardware tokens are both 542 possible options. This model assumes that there may be multiple 543 authorized users with different certificates that can be used for the 544 authorization or pre-authentication challenge. As such, the user 545 first provides the digital signature, so the account management can 546 determine if one of the acceptable certificates was used to digitally 547 sign the token. 549 type (required, string): The string "cert-01". 551 token (required, string): A random value that uniquely identifies 552 the challenge. The token for a certificate authentication 553 challenge includes a value for the recipeint to digitally sign 554 using their private key and post to the provided URL. The ACME 555 server then uses the digitally signed content to verify that the 556 challenge was signed using authorized credentials (certificate 557 issued and authorized for this challenge type). It MUST NOT 558 contain any characters outside the base64url alphabet and MUST NOT 559 include base64 padding characters ("="). 561 { 562 "type": "cert-01", 563 "url": "https://example.com/acme/chall/WrV_H87EyD3", 564 "status": "pending", 565 "token": "Some challenge to digitally sign" 566 } 568 7.3. FIDO or Public/Private Key Pairs 570 FIDO uses public/private key pairs that are issued specific to a 571 service. If FIDO or public/private key pairs (PPKP) are selected as 572 the challenge type, the account and credential issuance will have to 573 occur prior to use of this challenge type. The FIDO or public/ 574 private key pair credentials would be specific to the certificate 575 management account and would be created by the client, then 576 registered with the service as occurs with normal FIDO regisration of 577 credentials. As with normal FIDO and puiblic/private key pairs, the 578 token or challenge is digitally signed to prove possession of the 579 private key. 581 type (required, string): The string "ppkp-01". 583 token (required, string): A random value that uniquely identifies 584 the challenge. This challenge will operate much in the same way 585 as the certificate challenge as the operations are largely the 586 same. The user will be able to supply a response in the provided 587 URL from this challenge. It MUST NOT contain any characters 588 outside the base64url alphabet and MUST NOT include base64 padding 589 characters ("="). 591 { 592 "type": "ppkp-01", 593 "url": "https://example.com/acme/chall/WrV_H87EyD3", 594 "status": "pending", 595 "token": "Some challenge to sign" 596 } 598 8. Security Considerations 600 This will likely be full of considerations and is TBD for this 601 revision until challenge types are settled. 603 9. IANA Considerations 605 This memo includes no request to IANA, yet. 607 10. Contributors 609 Thank you to reviewers and contributors who helped to improve this 610 document. Thank you to Thomas Peterson who added the one-time 611 password types, HOTP and TOTP. 613 11. References 615 11.1. Normative References 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, 619 DOI 10.17487/RFC2119, March 1997, 620 . 622 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and 623 O. Ranen, "HOTP: An HMAC-Based One-Time Password 624 Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005, 625 . 627 [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP: 628 Time-Based One-Time Password Algorithm", RFC 6238, 629 DOI 10.17487/RFC6238, May 2011, 630 . 632 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 633 "Enrollment over Secure Transport", RFC 7030, 634 DOI 10.17487/RFC7030, October 2013, 635 . 637 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 638 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 639 May 2017, . 641 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 642 Kasten, "Automatic Certificate Management Environment 643 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 644 . 646 11.2. Informative References 648 [I-D.ietf-acme-ip] 649 Shoemaker, R., "ACME IP Identifier Validation Extension", 650 draft-ietf-acme-ip-06 (work in progress), May 2019. 652 11.3. URL References 654 [NIST800-63A] 655 US National Institute of Standards and Technology, 656 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 657 NIST.SP.800-63a.pdf". 659 [NIST800-63B] 660 US National Institute of Standards and Technology, 661 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 662 NIST.SP.800-63b.pdf". 664 [NIST800-63C] 665 US National Institute of Standards and Technology, 666 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 667 NIST.SP.800-63c.pdf". 669 [NIST800-63r3] 670 US National Institute of Standards and Technology, 671 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 672 NIST.SP.800-63-3.pdf". 674 Appendix A. Change Log 676 Note to RFC Editor: if this document does not obsolete an existing 677 RFC, please remove this appendix before publication as an RFC. 679 02 draft added subsections contributed from Thomas Peterson on HOTP 680 and TOTP. 682 Appendix B. Open Issues 684 Note to RFC Editor: please remove this appendix before publication as 685 an RFC. 687 Author's Address 689 Kathleen M. Moriarty 690 Dell EMC 691 176 South Street 692 Hopkinton 693 US 695 EMail: Kathleen.Moriarty@dell.com