idnits 2.17.1 draft-moriarty-acme-client-00.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 (March 29, 2019) is 1852 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 482, but not defined == Missing Reference: 'NIST800-63A' is mentioned on line 467, but not defined == Missing Reference: 'NIST800-63B' is mentioned on line 472, but not defined == Missing Reference: 'NIST800-63C' is mentioned on line 477, but not defined == Missing Reference: 'RFC6844' is mentioned on line 341, but not defined ** Obsolete undefined reference: RFC 6844 (Obsoleted by RFC 8659) == Unused Reference: 'RFC2119' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 450, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-acme-ip-05 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF K. Moriarty 2 Internet-Draft Dell EMC 3 Intended status: Standards Track March 29, 2019 4 Expires: September 19, 2019 6 ACME Client Extension 7 draft-moriarty-acme-client-00 9 Abstract 11 Automated Certificate Management Environment (ACME) core protocol 12 addresses the use case of web server certificates for TLS. This 13 document extends the ACME protocol to support end user client, device 14 client, and code signing certificates. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 19, 2019. 33 Copyright Notice 35 Copyright (c) 2019 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Identity Proofing for Client Certificates . . . . . . . . . . 2 52 3. Key Storage . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. Why Not EST . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Device Certificates . . . . . . . . . . . . . . . . . . . . . 5 55 6. End USer Client Certificates . . . . . . . . . . . . . . . . 6 56 7. CodeSigning Certificates . . . . . . . . . . . . . . . . . . 7 57 8. Pre-authorization . . . . . . . . . . . . . . . . . . . . . . 9 58 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 59 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 60 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 61 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 63 12.2. Informative References . . . . . . . . . . . . . . . . . 10 64 12.3. URL References . . . . . . . . . . . . . . . . . . . . . 10 65 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 66 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 12 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 69 1. Introduction 71 ACME [RFC8555] is a mechanism for automating certificate management 72 on the Internet. It enables administrative entities to prove 73 effective control over resources like domain names, and automates the 74 process of generating and issuing certificates. 76 ACME was designed for web server certificates with the possibility to 77 create extensions for other use cases and certificate types. End 78 user and device certificates may also benefit from automated 79 management to ease the deployment and maintenance of these 80 certificates type, thus the definition of the extension for that 81 purpose in this document. 83 2. Identity Proofing for Client Certificates 85 As with the TLS certificates defined in the core ACME document, 86 identity proofing for ACME issued end user client, device client, and 87 code signing certificates was not covered in RFC8555. 89 Identity proofing for these certificate types present some challenges 90 for process automation. NIST SP 800-63 r3 [NIST800-63r3] serves as 91 guidance for identity proofing further detailed in NIST SP 800-63A 92 [NIST800-63A] that may occur prior to the ability to automate 93 certificate management via ACME or may obviate the need for it 94 weighing end user privacy as a higher concern and allowing for 95 credential issuance to be decoupled from identity proofing (IAL1). 97 Using this guidance, a CA might select from the identity proofing 98 levels to assert claims on the issued certificates as follows from 99 NIST SP 800-63 r3 [NIST800-63r3]: 101 "IAL1: There is no requirement to link the applicant to a specific 102 real-life identity. Any attributes provided in conjunction with the 103 authentication process are self-asserted or should be treated as such 104 (including attributes a Credential Service Provider, or CSP, asserts 105 to an RP). 107 IAL2: Evidence supports the real-world existence of the claimed 108 identity and verifies that the applicant is appropriately associated 109 with this real-world identity. IAL2 introduces the need for either 110 remote or physically-present identity proofing. Attributes can be 111 asserted by CSPs to RPs in support of pseudonymous identity with 112 verified attributes. 114 IAL3: Physical presence is required for identity proofing. 115 Identifying attributes must be verified by an authorized and trained 116 representative of the CSP. As with IAL2, attributes can be asserted 117 by CSPs to RPs in support of pseudonymous identity with verified 118 attributes." 120 The certificate issuing CA may make this choice by certificate type 121 issued. Once identity proofing has been performed, in cases where 122 this is part of the process, and certificates have been issued, NIST 123 SP 800-63 r3 [NIST800-63r3] has the following recommendations for 124 authentication or in the context of ACME, management of issuance for 125 subsequent client, device, or code-signing certificates: 127 "For services in which return visits are applicable, a successful 128 authentication provides reasonable risk-based assurances that the 129 subscriber accessing the service today is the same as that which 130 accessed the service previously. The robustness of this confidence 131 is described by an AAL categorization. NIST SP 800-63 B 132 [NIST800-63B] addresses how an individual can securely authenticate 133 to a CSP to access a digital service or set of digital services. SP 134 800-63B contains both normative and informative material. 136 The three AALs define the subsets of options agencies can select 137 based on their risk profile and the potential harm caused by an 138 attacker taking control of an authenticator and accessing agencies? 139 systems. The AALs are as follows: 141 AAL1: AAL1 provides some assurance that the claimant controls an 142 authenticator bound to the subscriber?s account. AAL1 requires 143 either single-factor or multi-factor authentication using a wide 144 range of available authentication technologies. Successful 145 authentication requires that the claimant prove possession and 146 control of the authenticator through a secure authentication 147 protocol. 149 AAL2: AAL2 provides high confidence that the claimant controls 150 authenticator(s) bound to the subscriber?s account. Proof of 151 possession and control of two distinct authentication factors is 152 required through secure authentication protocol(s). Approved 153 cryptographic techniques are required at AAL2 and above. 155 AAL3: AAL3 provides very high confidence that the claimant controls 156 authenticator(s) bound to the subscriber?s account. Authentication 157 at AAL3 is based on proof of possession of a key through a 158 cryptographic protocol. AAL3 authentication SHALL use a hardware- 159 based authenticator and an authenticator that provides verifier 160 impersonation resistance; the same device MAY fulfill both these 161 requirements. In order to authenticate at AAL3, claimants SHALL 162 prove possession and control of two distinct authentication factors 163 through secure authentication protocol(s). Approved cryptographic 164 techniques are required." 166 If federations and assertions are used for authorizing certificate 167 issuance, NIST SP 800-63 C [NIST800-63C] may be referenced for 168 guidance on levels of assurance. 170 Existing PKI certification authorities (CAs) tend to use a set of ad 171 hoc protocols for certificate issuance and identity verification. 172 For each certificate usage type, a basic process will be described to 173 obtain an initial certificate and for the certificate renewal 174 process. If higher assurance levels are desired, the guidance from 175 NIST SP 800-63 r3 [NIST800-63r3] may be useful and out-of-band 176 identity proofing options are possible options for pre-authorization 177 challenges or notifications. 179 3. Key Storage 181 [The following text may be left out in the next revision as it is 182 decoupled already: A design goal for the automated workflow for these 183 certificate types via ACME is to allow for use of the Key Management 184 Interoperability Protocol (KMIP) for key management and storage or 185 PKCS-11 for key storage. In the case of KMIP, the KMIP enterprise 186 key manager could use ACME to communicate with the CA server, leaving 187 the device communications between devices and the KMIP server. 188 However, the use of ACME can be standalone integrating with the 189 available client key storage method (for example, PKCS-#11) provided 190 for accessibility and to prevent cost barriers for automating key 191 management for some implementations. The ACME client on the device 192 or system storing the code signing certificate would authenticate to 193 the CA running an ACME server to obtain initial certificates or renew 194 certificates. With the proliferation of open source implementations 195 of ACME for TLS server certificates, this seems like a reasonable 196 goal.] 198 4. Why Not EST 200 [These discussions have happened already for the core ACME protocol, 201 expect this to be removed for the next version: 203 Enrollment over Secure Transport (EST) [RFC7030] and OpenStack's 204 Keystone are options for automating client certificates. [OpenSSL 205 can be combined with libest to automate the management of client 206 certificates.] 208 The authentication options used in EST to obtain a client certificate 209 are described in [RFC7030] Section 2.2 and are stated as follows: 211 TLS with a previously issued client certificate (e.g., an existing 212 certificate issued by the EST CA); 214 TLS with a previously installed certificate (e.g., manufacturer- 215 installed certificate or a certificate issued by some other 216 party); 218 Certificate-less TLS (e.g., with a shared credential distributed 219 out-of-band); 221 HTTP-based with a username/password distributed out-of-band. 223 Although a fine a protocol, none of these options enable the protocol 224 to establish authentication of the entity (device, user, owner of 225 code signing certificate) without a pre-established and external 226 process to the protocol. In some cases, higher levels of assertion 227 are necessary and EST may be more suited for those purposes or 228 additional out-of-band processing could be used in conjunction with 229 ACME if adopted widely for the automation of client certificate 230 management.] 232 5. Device Certificates 234 A device certificate is a client certificate issued to a device 235 identified through device credentials such as an IP address, 236 hostname, or MAC address. This process is separate from an end user 237 client certificate that may be stored on a device, but identifies a 238 person using the device described in the next subsection. While 239 there are automated processes in place today for device certificate 240 renewal, most are specific to the CA and not open standards. The 241 general workflow is similar to that described in RFC8555 with the 242 differences being in the CSR, requesting a client certificate. [IP 243 addresses may be necessary for some devices and it may be best to 244 extend [I-D.ietf-acme-ip] to cover varying CSR types that include 245 client certificates for devices explicitly.] 247 A typical process to obtain a device certificate may be similar to 248 the following workflow described in the introduction of RFC8555 with 249 the exception of certificate type and usage. 251 [Is an additional type definition helpful to distinguish that this is 252 for a client certificate?] 254 6. End USer Client Certificates 256 [Should this be done in ACME? I'm leaning towards no.] 258 A client certificate used to authenticate an end user may be used for 259 mutual authentication in TLS or another example would be with EAP- 260 TLS. The client certificate in this case may be stored in a browser, 261 PKCS-#11 container, KMIP, or another key container. To obtain an end 262 user client certificate, there are several possibilities to automate 263 authentication of an identity credential presumably tied to an end 264 user. 266 [Several authentication options are intentionally provided for review 267 and discussion by the ACME working group.] 269 A trusted federated service that ties the user to an email address 270 with a reputation of the user attached to the email may be possible. 271 One such example might be the use of a JWT signed OAuth token. 273 Risk based authentication used for identity proofing with red herring 274 questions is a third option that could utilize public information on 275 individuals to authenticate. 277 Just use FIDO and don't create anything new. FIDO provides a 278 mechanism to have unique certificate based access for client 279 authentication to web sites and they are working on non-web. 280 Identity proofing is intentionally decoupled from authentication in 281 this model as that is in line with NIST 800-63r3 recommendations for 282 privacy protections of the user. The credential in this case is 283 authenticated and would be consistent for it's use, but the identity 284 proofing for that credential is not performed. Obviously, identity 285 proofing is more important for some services, like financial 286 applications where tying the user to the identity for access to 287 financial information is important. However, is automated identity 288 proofing important for any user certificate or should it remain 289 decoupled where it could be automated by a service offering or is 290 there a need for a standardized mechanism to support it for user 291 certificates? 293 7. CodeSigning Certificates 295 The process to retrieve a code signing certificate is similar to that 296 of a web server certificate, with differences primarily in the CSR 297 request and the resulting certificate properties. [The storage and 298 access of a code signing certificate must be protected and is 299 typically done through hardware, a hardware security module (HSM) 300 which likely has a PKCS#11 interface. A code signing certificate may 301 either be a standard one or an extended validation (EV) certificate.] 303 [For automation purposes, the process described in this document will 304 follow the standard process and any out-of-band preprocessing can 305 increase the level of the issued certificate if the CA offers such 306 options and has additional identity proofing mechanisms (in band or 307 out-of-band).] 309 Strict vetting processes are necessary for many code signing 310 certificates to provide a high assurance on the signer. In some 311 cases, issuance of a standard CodeSigning certificate will be 312 appropriate and no additional "challenges" [RFC8555 Section 8] will 313 be necessary. In this case, the standard option could be automated 314 very similar to Web server certificates with the only changes being 315 in the CSR properties. However, this may not apply to all scenarios, 316 such as those requiring EV certificates with the possibility for 317 required out-of-band initial authentication. 319 Organization validation is required for standard code signing 320 certificates from most issuers. The CSR is used to identify the 321 organization from the included domain name in the request. The 322 resulting certificate, however, instead contains the organization's 323 name and for EV certificates, other identifying information for the 324 organization. For EV certificates, this typically requires that the 325 domain is registered with the Certificate Authority provider, listed 326 in CAA [RFC6844], and administrators for the account are named with 327 provided portal access for certificate issuance and management 328 options. 330 While ACME allows for the client to directly establish an account 331 with a CA, an initial process for this step may assist with the 332 additional requirements for EV certificates and assurance levels 333 typically required for code signing certificates. For standard 334 certificates, with a recommendation for additional vetting through 335 extended challenge options to enable ACME to establish the account 336 directly. In cases where code signing certificates are used heavily 337 for an organization, having the portal access accessible replaced 338 with ACME authenticated client access with extra challenges for 339 authentication may be an option to automate the functionality. 341 To improve the vetting process, ACME's optional use of CAA [RFC6844] 342 with the Directory "meta" data "caaIdentities" ([RFC8555] 343 Section 9.7.6) assists with the validation that a CA may have issue 344 certificates for any particular domain and is RECOMMENDED for use 345 with code signing certificates for this additional level of 346 validation checking on issued certificates. 348 CAA helps as anyone verifying a certificate used for code signing can 349 verify that the CA used has been authorized to issue certificates for 350 that organization. CSR requests for code signing certificates 351 typically contain a Common Name (CN) using a domain name that is 352 replaced with the organization name to have the expected details 353 displayed in the resulting certificate. Since this work flow already 354 occurs, there is a path to automation and validation via an existing 355 ACME type, "dns". 357 As noted in RFC8555, "the external account binding feature (see 358 Section 7.3.4) can allow an ACME account to use authorizations that 359 have been granted to an external, non-ACME account. This allows ACME 360 to address issuance scenarios that cannot yet be fully automated, 361 such as the issuance of "Extended Validation" certificates." 363 The ACME challenge object, [RFC8555] Section 7.1.5 is RECOMMENDED for 364 use for Pre-authorization ([RFC8555] Section 7.4.1). 366 Questions for reviewers: 368 [Is there interest to set a specific challenge object for CodeSigning 369 Certificates? Or should this be left to individual CAs to decide and 370 differentiate? The current challenge types defined in RFC8555 371 include HTTPS (provisioning HTTP resources) and DNS (provisioning a 372 TXT resource record). Use of DNS may be possible, but the HTTP 373 resource doesn't necessarily make sense. Since the process to 374 retrieve an EV CodeSigning certificate usually requires proof of the 375 organization and validation from one of 2 named administrators, SMS 376 or email may be needed as defined challenge types. AN organization 377 may want to tie this contact to a role rather than a person and that 378 consideration should be made in the design as well as implementation 379 by organizations.] 381 ACME provides an option for notification of the operator via email or 382 SMS upon issuance/renewal of a certificate after the domain has been 383 validated as owned by the requestor. This option is RECOMMENDED due 384 to the security considerations of code signing certificates as a way 385 to limit or reduce the possibility of a third party gaining access to 386 a code signing certificate inappropriately. [Development of 387 additional challenge types is likely to support this for pre- 388 authorization, which would better match the security considerations 389 for this certificate type.] 391 Since DNS is used to identify the organization in the request, the 392 identifier "type" ([RFC8555]Section 7.4) is set to dns, not requiring 393 any additions to the ACME protocol for this type of certificate. The 394 distinction lies in the CSR, where the values are set to request a 395 CodeSigning certificate for a client certificate. [Question: Is it 396 helpful to define an identifier for the administrator or for the 397 developer to distinguish the certificate type in ACME and not just 398 the CSR?] 400 KeyUsage (DigitalSignature) and ExtendedKeyUsage (CodeSigning) in the 401 CSR MUST be set to the correct values for the CA to see the request 402 is for a Code Signing certificate. The Enhanced Key Usage SHOULD be 403 set to show this is a client certificate., using OID 404 "1.3.6.1.5.5.7.3.2". The CN MUST be set to the expected registered 405 domain with the CA account. 407 An advantage of ACME is the ability to automate rollover to allow for 408 easy management of short expiry times on certificates. The lifetime 409 of CodeSigning certificates is typically a year or two, but 410 automation could allow for shorter expiry times becoming feasible. 412 Automation of storage to an HSM, which typically requires 413 authentication is intentionally left out-of-scope. 415 8. Pre-authorization 417 Additional challenge types are defined here for the verification of 418 administrors at an organization requesting CodeSigning certificates. 419 SMS and email are both defined and may be used singularly or in 420 combination as the ACME protocol allows for multiple pre- 421 authorization challenges to be issued. 423 TBD 425 9. Security Considerations 427 This will likely be full of considerations and is TBD for revision 428 one. 430 10. IANA Considerations 432 This memo includes no request to IANA, yet. 434 11. Contributors 436 12. References 438 12.1. Normative References 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, 442 DOI 10.17487/RFC2119, March 1997, 443 . 445 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 446 "Enrollment over Secure Transport", RFC 7030, 447 DOI 10.17487/RFC7030, October 2013, 448 . 450 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 451 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 452 May 2017, . 454 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 455 Kasten, "Automatic Certificate Management Environment 456 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 457 . 459 12.2. Informative References 461 [I-D.ietf-acme-ip] 462 Shoemaker, R., "ACME IP Identifier Validation Extension", 463 draft-ietf-acme-ip-05 (work in progress), February 2019. 465 12.3. URL References 467 [NIST800-63A] 468 US National Institute of Standards and Technology, 469 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 470 NIST.SP.800-63a.pdf". 472 [NIST800-63B] 473 US National Institute of Standards and Technology, 474 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 475 NIST.SP.800-63b.pdf". 477 [NIST800-63C] 478 US National Institute of Standards and Technology, 479 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 480 NIST.SP.800-63c.pdf". 482 [NIST800-63r3] 483 US National Institute of Standards and Technology, 484 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/ 485 NIST.SP.800-63-3.pdf". 487 Appendix A. Change Log 489 Note to RFC Editor: if this document does not obsolete an existing 490 RFC, please remove this appendix before publication as an RFC. 492 Appendix B. Open Issues 494 Note to RFC Editor: please remove this appendix before publication as 495 an RFC. 497 Author's Address 499 Kathleen M. Moriarty 500 Dell EMC 501 176 South Street 502 Hopkinton 503 US 505 EMail: Kathleen.Moriarty@dell.com