idnits 2.17.1
draft-ietf-acme-client-04.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 (29 September 2021) is 933 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 588, but not
defined
== Missing Reference: 'NIST800-63A' is mentioned on line 593, but not
defined
== Missing Reference: 'NIST800-63C' is mentioned on line 603, but not
defined
== Missing Reference: 'RFC6844' is mentioned on line 263, but not defined
** Obsolete undefined reference: RFC 6844 (Obsoleted by RFC 8659)
== Missing Reference: 'NIST800-63B' is mentioned on line 598, but not
defined
== Unused Reference: 'RFC2119' is defined on line 548, but no explicit
reference was found in the text
== Unused Reference: 'RFC8174' is defined on line 563, but no explicit
reference was found in the text
== Unused Reference: 'RFC7030' is defined on line 572, but no explicit
reference was found in the text
== Unused Reference: 'I-D.ietf-acme-ip' is defined on line 579, 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 29 September 2021
5 Expires: 2 April 2022
7 ACME End User Client and Code Signing Certificates
8 draft-ietf-acme-client-04
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 2 April 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 and key in this case may be stored in a browser, PKCS-#11
133 container, Key Management Interoperability Protocol (KMIP) (possible,
134 but just code signing and device client certificates in practice), or
135 another key container. To obtain an end user client certificate and
136 associated key pair, there are several possibilities to automate
137 authentication of an identity credential intended to be tied to an
138 end user.
140 [We need to determine if it is important in ACME to define an
141 automated method that tests the identity or the user or to just have
142 consistent credentials for the authentication challenges. The
143 credentials may be distributed through an out-of-band method that
144 involves identity proofing.]
146 [Several authentication options with identity proofing are
147 intentionally provided for review and discussion by the ACME working
148 group.]
150 A trusted federated service that ties the user to an email address
151 with a reputation of the user attached to the email may be possible.
152 One such example might be the use of a JSON Web Token (JWT) signed
153 OAuth token.
155 Risk based authentication used for identity proofing with red herring
156 questions is a third option that could utilize public information on
157 individuals to authenticate. This would be similar to the signup
158 process used in some financial applications.
160 Existing credentials - for instance, FIDO. FIDO uses a public key
161 pair and does not perform identity proofing. FIDO authentication
162 provides a different key pair to each service using FIDO for
163 authentication, which are generated at the client and registered by
164 the server. This may require using the FIDO credentials from a
165 specific service for authentication to gain ACME issued crededentials
166 (not advised based on how FIDO credentials are supposed to be used).
167 Are there instances where the same provider would issue both sets of
168 credentials? You wouldn't want to expose your FIDO credentials to a
169 different party, that's why each service has their own. Would you
170 set up a mechanism to get FIDO credentials to then obtain a
171 certificate? (What use cases would this be necessary? When do you
172 need a certificate where you already have a specific public/private
173 key pair?) This can be defined as an auth type, but should it be?
175 One-time password (OTP) authentication is a secure option. In cases
176 where a higher assurance level is needed, OTP may be a good choice
177 and many options exist today for OTP that could use an app on a phone
178 for instance tied to an existing (or newly established) password.
179 The OTP may be tied to an out-of-band process and may be associated
180 with a username/password and other accounts.
182 One consideration is to understand if the use case could just use
183 FIDO and not create anything new (ACME client certificates). FIDO
184 provides a mechanism to have unique public key pair based access for
185 client authentication to web sites and they are working on non-web.
186 Identity proofing is intentionally decoupled from authentication in
187 this model as that is in line with NIST 800-63r3 recommendations for
188 privacy protections of the user. The credential in this case is
189 authenticated and would be consistent for it's use, but the identity
190 proofing for that credential is not performed. Obviously, identity
191 proofing is more important for some services, like financial
192 applications where tying the user to the identity for access to
193 financial information is important. However, is automated identity
194 proofing important for any user certificate or should it remain
195 decoupled where it could be automated by a service offering or is
196 there a need for a standardized mechanism to support it for user
197 certificates?
199 Three methods for ACME client authentication, not identity proofing,
200 are proposed in the Challenge Type Section.
202 4. CodeSigning Certificates
204 The process to retrieve a code signing certificate is similar to that
205 of a web server certificate, with differences primarily in the CSR
206 request and the resulting certificate properties. [The storage and
207 access of a code signing certificate must be protected and is
208 typically done through hardware, a hardware security module (HSM),
209 which likely has a PKCS#11 interface. A code signing certificate may
210 either be a standard one or an extended validation (EV) certificate.]
212 For automation purposes, the process described in this document will
213 follow the standard process and any out-of-band preprocessing can
214 increase the level of the issued certificate if the CA offers such
215 options and has additional identity proofing mechanisms (in band or
216 out-of-band).
218 Strict vetting processes are necessary for many code signing
219 certificates to provide a high assurance on the signer. In some
220 cases, issuance of a standard CodeSigning certificate will be
221 appropriate and no additional "challenges" [RFC8555 Section 8] will
222 be necessary. In this case, the standard option could be automated
223 very similar to Web server certificates with the only changes being
224 in the CSR properties. However, this may not apply to all scenarios,
225 such as those requiring EV certificates with the possibility for
226 required out-of-band initial authentication and identity proofing.
228 EV code signing certificates have a distinct set of requirements from
229 EV web certificates. In particular, they don't have associated
230 domain names, nor is CAA checking done. The code signing certificate
231 links a public key to an organization, not a domain. CAs may chose
232 different methods to enable the use of ACME for EV code signing
233 certificates. The intent of this work is to provide additional
234 authentication challenge types that may enable their automation
235 process.
237 Organization validation is required for standard code signing
238 certificates from most issuers. The CSR is used to identify the
239 organization from the included domain name in the request. The
240 resulting certificate, however, instead contains the organization's
241 name and for EV certificates, other identifying information for the
242 organization. For EV certificates, this could require that the
243 domain is registered with the Certificate Authority provider, listed
244 in CAA [RFC6844], and administrators for the account are named with
245 provided portal access for certificate issuance and management
246 options.
248 While ACME allows for the client to directly establish an account
249 with a CA, an initial out-of-band process for this step may assist
250 with the additional requirements for EV certificates and assurance
251 levels typically required for code signing certificates. For
252 standard certificates, with a recommendation for additional vetting
253 through extended challenge options to enable ACME to establish the
254 account directly. In cases where code signing certificates are used
255 heavily for an organization, having the portal access replaced with
256 ACME authenticated client access with extra challenges for
257 authentication may be an option to automate the functionality.
259 [For standard certificates, is it worth defining SMS and email for
260 the challenge? Obviously, EV needs more, so a few choices are
261 suggested in this revision.]
263 To improve the vetting process, ACME's optional use of CAA [RFC6844]
264 with the Directory "meta" data "caaIdentities" ([RFC8555]
265 Section 9.7.6) assists with the validation that a CA may have issue
266 certificates for any particular domain and is RECOMMENDED for use
267 with code signing certificates for this additional level of
268 validation checking on issued certificates.
270 As noted in RFC8555, "the external account binding feature (see
271 Section 7.3.4) can allow an ACME account to use authorizations that
272 have been granted to an external, non-ACME account. This allows ACME
273 to address issuance scenarios that cannot yet be fully automated,
274 such as the issuance of "Extended Validation" certificates."
276 The ACME challenge object, [RFC8555] Section 7.1.5 is RECOMMENDED for
277 use for Pre-authorization ([RFC8555] Section 7.4.1). Additional
278 challenge types are added to provide higher levels of security for
279 this issuance verification step. The use of OTP, FIDO credentials
280 (public/private key pairs), or validation from a certificate issued
281 at account setup time are defined in Section 8. Pre-Authoriziation.
283 Questions for reviewers:
285 [Is there interest to set a specific or default challenge object for
286 CodeSigning Certificates? Or should this be left to individual CAs
287 to decide and differentiate? The current challenge types defined in
288 RFC8555 include HTTPS (provisioning HTTP resources) and DNS
289 (provisioning a TXT resource record). Use of DNS may be possible,
290 but the HTTP resource doesn't necessarily make sense. Since the
291 process to retrieve an EV CodeSigning certificate usually requires
292 proof of the organization and validation from one of 2 named
293 administrators, some other challenge type like public/private key
294 pairs or OTP may be needed as defined challenge types. An
295 organization may want to tie this contact to a role rather than a
296 person and that consideration should be made in the design as well as
297 implementation by organizations.]
299 ACME provides an option for notification of the operator via email or
300 SMS upon issuance/renewal of a certificate after the domain has been
301 validated as owned by the requestor. This option is RECOMMENDED due
302 to the security considerations of code signing certificates as a way
303 to limit or reduce the possibility of a third party gaining access to
304 a code signing certificate inappropriately. Development of
305 additional challenge types is included in this document to support
306 this for pre-authorization, which would better match the security
307 considerations for this certificate type. Additional types may be
308 added if agreed upon by the working group.
310 Since DNS is used to identify the organization in the request, the
311 identifier "type" ([RFC8555]Section 7.4) is set to dns, not requiring
312 any additions to the ACME protocol for this type of certificate. The
313 distinction lies in the CSR, where the values are set to request a
314 CodeSigning certificate for a client certificate. [Question: Is it
315 helpful to define an identifier for the administrator or for the
316 developer to distinguish the certificate type in ACME and not just
317 the CSR?]
319 KeyUsage (DigitalSignature) and ExtendedKeyUsage (CodeSigning) in the
320 CSR MUST be set to the correct values for the CA to see the request
321 is for a Code Signing certificate. The Enhanced Key Usage SHOULD be
322 set to show this is a client certificate., using OID
323 "1.3.6.1.5.5.7.3.2". The CN MUST be set to the expected registered
324 domain with the CA account.
326 An advantage of ACME is the ability to automate rollover to allow for
327 easy management of short expiry times on certificates. The lifetime
328 of CodeSigning certificates is typically a year or two, but
329 automation could allow for shorter expiry times becoming feasible.
330 However, lifetimes are less of an issue for code signing certificates
331 than other certificate types. however there is a legitmate case for
332 "one signature per certificate." Automation might be helpful in this
333 case if patches or software updates were frequent or to minimize the
334 knowledge needed for the organization using this method.
336 Automation of storage to a hardware security module (HSM), which
337 typically requires authentication is intentionally left out-of-scope.
339 5. Pre-authorization
341 Additional challenge types are defined here for the verification of
342 administrators at an organization requesting CodeSigning
343 certificates. Email is listed as possible in RFC8555 and may be used
344 singularly or in combination as the ACME protocol allows for multiple
345 pre-authorization challenges to be issued. Additional pre-
346 authorization types are defined that provide a higher level of
347 assurance to authorize a request.
349 6. Challenge Types
351 The challenge types defined in the following subsections are to
352 authenticate individuals or holders of specific pre-issued
353 credentials (users acting in roles for an organization). The
354 challenge types can be used to obtain end user certificate types or
355 as a pre-authorization challenges with certificate types such as the
356 Code Signing Certificate. Please note that the pre-authorization
357 challenge is also coupled with the account certificate in ACME for
358 verification. The process for obtaining EV Code Signing Certificates
359 typically requires authorization from one or more individuals in a
360 role for the organization. The use of pre-issued secure credentials,
361 at an assurance level appropriate for the certificate type being
362 issued, provides a way to automate the issuance and renewal process.
364 6.1. One Time Password (OTP)
366 There are numerous one time password technologies with slight
367 variations between implementations. The response to the challenge is
368 entered in the provided URL, offering flexibility to those using this
369 challenge type to acomodate the specific requirements of their
370 solution. Looking at 2 OTP solutions, the challenge response is
371 provided via a tool or app without any user interaction of
372 information required from the server to generate the challenge. The
373 2 solutions that operate in this manner include SecureID and Duo
374 Security. If a challenge is required to generate the response to be
375 provided in the URL, the token can supply the challenge.
377 type (required, string): The string "otp-01".
379 token (required, string): A random value that uniquely identifies
380 the challenge. OTP types and input vary between technologies.
381 The token value will match the type expected for the pre-issued
382 OTP credential. The user will be able to supply a response in the
383 provided URL from this challenge. It MUST NOT contain any
384 characters outside the base64url alphabet and MUST NOT include
385 base64 padding characters ("=").
387 {
388 "type": "otp-01",
389 "url": "https://example.com/acme/chall/WrV_H87EyD3",
390 "status": "pending",
391 "token": "challenge"
392 }
394 6.1.1. HMAC-Based One-Time Password (HOTP)
396 HOTP([RFC4226]) describes an algorithm for the generation of time-
397 based password values.
399 type (required, string): The string "hotp-01".
401 token (required, string): The HOTP value. This SHOULD be the 6
402 digit representation.
404 {
405 "type": "hotp-01",
406 "url": "https://example.com/acme/chall/WrV_H87EyD3",
407 "status": "pending",
408 "token": "123456"
409 }
411 6.1.2. Time-Based One-Time Password (TOTP)
413 TOTP([RFC6238]) describes an algorithm for the generation of time-
414 based password values, an extension from HOTP.
416 type (required, string): The string "totp-01".
418 token (required, string): The TOTP value. This SHOULD be the 6
419 digit representation.
421 {
422 "type": "totp-01",
423 "url": "https://example.com/acme/chall/WrV_H87EyD3",
424 "status": "pending",
425 "token": "123456"
426 }
428 6.1.3. Generic One Time Password (OTP)
430 There are numerous other one time password technologies with slight
431 variations between implementations. The response to the challenge is
432 entered in the provided URL, offering flexibility to those using this
433 challenge type to acomodate the specific requirements of their
434 solution. Looking at 2 OTP solutions, the challenge response is
435 provided via a tool or app without any user interaction of
436 information required from the server to generate the challenge. The
437 2 solutions that operate in this manner include SecureID and Duo
438 Security. If a challenge is required to generate the response to be
439 provided in the URL, the token can supply the challenge.
441 type (required, string): The string "otp-01".
443 token (required, string): A random value that uniquely identifies
444 the challenge. OTP types and input vary between technologies.
445 The token value will match the type expected for the pre-issued
446 OTP credential. The user will be able to supply a response in the
447 provided URL from this challenge. It MUST NOT contain any
448 characters outside the base64url alphabet and MUST NOT include
449 base64 padding characters ("=").
451 {
452 "type": "otp-01",
453 "url": "https://example.com/acme/chall/WrV_H87EyD3",
454 "status": "pending",
455 "token": "challenge"
456 }
458 6.2. Public Key Cryptography
460 Certificates may be pre-issued and stored according to assurance
461 level requirements for the purpose of identifying a user's identity.
462 If a higher assurance level is needed for a user serving in a
463 specific role or for that individual, it is possible for identity
464 proofing to occur in person using identifiers acceptable for the
465 specified process and the private key stored appropriately for the
466 required assurance level. PKCS#11 software or hardware tokens are
467 both possible options. This model assumes that there may be multiple
468 authorized users with different certificates that can be used for the
469 authorization or pre-authentication challenge. As such, the user
470 first provides the digital signature, so the account management can
471 determine if one of the acceptable certificates was used to digitally
472 sign the token.
474 type (required, string): The string "cert-01".
476 token (required, string): A random value that uniquely identifies
477 the challenge. The token for a certificate authentication
478 challenge includes a value for the recipeint to digitally sign
479 using their private key and post to the provided URL. The ACME
480 server then uses the digitally signed content to verify that the
481 challenge was signed using authorized credentials (certificate
482 issued and authorized for this challenge type). It MUST NOT
483 contain any characters outside the base64url alphabet and MUST NOT
484 include base64 padding characters ("=").
486 {
487 "type": "cert-01",
488 "url": "https://example.com/acme/chall/WrV_H87EyD3",
489 "status": "pending",
490 "token": "Some challenge to digitally sign"
491 }
493 6.3. WebAuthn or Public/Private Key Pairs
495 W3C's WebAuthn uses raw public/private key pairs that are issued
496 specific to a service. If WebAuthn or public/private key pairs
497 (PPKP) are selected as the challenge type, the account and credential
498 issuance will have to occur prior to use of this challenge type. The
499 WebAuthn or public/private key pair credentials would be specific to
500 the certificate management account and would be created by the
501 client, then registered with the service as occurs with normal
502 WebAuthn regisration of credentials. As with normal WebAuthn and
503 public/private key pairs, the token or challenge is digitally signed
504 to prove possession of the private key.
506 type (required, string): The string "ppkp-01".
508 token (required, string): A random value that uniquely identifies
509 the challenge. This challenge will operate much in the same way
510 as the certificate challenge as the operations are largely the
511 same. The user will be able to supply a response in the provided
512 URL from this challenge. It MUST NOT contain any characters
513 outside the base64url alphabet and MUST NOT include base64 padding
514 characters ("=").
516 {
517 "type": "ppkp-01",
518 "url": "https://example.com/acme/chall/WrV_H87EyD3",
519 "status": "pending",
520 "token": "Some challenge to sign"
521 }
523 7. Security Considerations
525 This will likely be full of considerations and is TBD for this
526 revision until challenge types are settled.
528 8. IANA Considerations
530 This memo includes no request to IANA, yet.
532 9. Contributors
534 Thank you to reviewers and contributors who helped to improve this
535 document. Thank you to Thomas Peterson who added the one-time
536 password types, HOTP and TOTP. Thank you to Tim Hollebeek for your
537 early review and added text specific to EV certificate issuance and
538 one time use code signing certificates. Thank you to Andrei Popov
539 and Deb Cooley for your reviews and suggestions made in -04. Thank
540 you to those who reviewed the CAA text removed in version -05
541 including: Carl Mehner, Roland Shoemaker, Ben Schwartz, and Ryan
542 Sleevi. Posted WG version. -02 updates authors email address.
544 10. References
546 10.1. Normative References
548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
549 Requirement Levels", BCP 14, RFC 2119,
550 DOI 10.17487/RFC2119, March 1997,
551 .
553 [RFC4226] M'Raihi, D., Bellare, M., Hoornaert, F., Naccache, D., and
554 O. Ranen, "HOTP: An HMAC-Based One-Time Password
555 Algorithm", RFC 4226, DOI 10.17487/RFC4226, December 2005,
556 .
558 [RFC6238] M'Raihi, D., Machani, S., Pei, M., and J. Rydell, "TOTP:
559 Time-Based One-Time Password Algorithm", RFC 6238,
560 DOI 10.17487/RFC6238, May 2011,
561 .
563 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
564 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
565 May 2017, .
567 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
568 Kasten, "Automatic Certificate Management Environment
569 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
570 .
572 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
573 "Enrollment over Secure Transport", RFC 7030,
574 DOI 10.17487/RFC7030, October 2013,
575 .
577 10.2. Informative References
579 [I-D.ietf-acme-ip]
580 Shoemaker, R. B., "Automated Certificate Management
581 Environment (ACME) IP Identifier Validation Extension",
582 Work in Progress, Internet-Draft, draft-ietf-acme-ip-08, 1
583 October 2019, .
586 10.3. URL References
588 [NIST800-63r3]
589 US National Institute of Standards and Technology,
590 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
591 NIST.SP.800-63-3.pdf".
593 [NIST800-63A]
594 US National Institute of Standards and Technology,
595 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
596 NIST.SP.800-63a.pdf".
598 [NIST800-63B]
599 US National Institute of Standards and Technology,
600 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
601 NIST.SP.800-63b.pdf".
603 [NIST800-63C]
604 US National Institute of Standards and Technology,
605 "https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
606 NIST.SP.800-63c.pdf".
608 Appendix A. Change Log
610 Note to RFC Editor: if this document does not obsolete an existing
611 RFC, please remove this appendix before publication as an RFC.
613 02 draft added subsections contributed from Thomas Peterson on HOTP
614 and TOTP.
616 Appendix B. Open Issues
618 Note to RFC Editor: please remove this appendix before publication as
619 an RFC.
621 Author's Address
623 Kathleen M. Moriarty
624 Dell Technologies
625 176 South Street
626 Hopkinton,
627 United States of America
629 Email: Kathleen.Moriarty.ietf@gmail.com