idnits 2.17.1 draft-biggs-acme-sso-01.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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 19 characters in excess of 72. ** The abstract seems to contain references ([RFC8659], [RFC8555]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (8 April 2021) is 1111 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TODO Working Group A. Biggs 3 Internet-Draft R.L. Barnes 4 Intended status: Informational R. Moynihan 5 Expires: 10 October 2021 Cisco 6 8 April 2021 8 Automated Certificate Management Environment (ACME) Extension for Single 9 Sign On Challenges 10 draft-biggs-acme-sso-01 12 Abstract 14 This document specifies an extension to the ACME protocol [RFC8555] 15 to enable ACME servers to validate a client's control of an email 16 identifier using single sign-on (SSO) technologies. An extension to 17 the CAA [RFC8659] resource record specification is also defined to 18 provide domain owners a means to declare a set of SSO providers that 19 ACME servers may rely upon when employing SSO for identifier 20 validation on their domain. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 10 October 2021. 39 Copyright Notice 41 Copyright (c) 2021 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Simplified BSD License text 50 as described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 57 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 58 4. ACME email Identifier Type . . . . . . . . . . . . . . . . . 6 59 5. ACME sso-01 Challenge Type . . . . . . . . . . . . . . . . . 6 60 6. Single Sign-On & Order fulfillment . . . . . . . . . . . . . 7 61 7. Guidance for Email Verification . . . . . . . . . . . . . . . 8 62 7.1. SAML . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 7.2. OpenID . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 8. CAA for Email Address Certificates . . . . . . . . . . . . . 9 65 8.1. CAA issueemail property . . . . . . . . . . . . . . . . . 10 66 8.2. Usage of the CAA validationmethods Parameter . . . . . . 10 67 8.3. CAA ssoproviders Parameter . . . . . . . . . . . . . . . 11 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 69 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 72 11.2. Informative References . . . . . . . . . . . . . . . . . 13 73 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 Applications are increasingly using end-to-end encryption to protect 79 user content and frequently use email addresses to identify users. 80 In such contexts, the use of X.509 certificates binding email 81 addresses to public keys is a natural authentication mechanism. If 82 the issuer of the certificate is separate from the application 83 provider, and validates control of the email address independently of 84 the application provider, then the resulting certificate can be used 85 to provide end-to-end authentication, in the sense that the 86 application provider is unable to impersonate the authenticated user. 88 Historically, certificates for email addresses have been difficult to 89 obtain. Current end-to-end encrypted communications applications 90 typically rely on laborious, error-prone manual authentication 91 processes, often based on comparing opaque "security codes" or 92 "safety numbers". Thus, in practice, end-to-end encrypted 93 communications are usually vulnerable to impersonation attacks by the 94 application provider. 96 When ACME was first introduced, its primary focus was on issuing 97 certificates for domain names, and the base specification contains 98 challenges for validating a client's control over a domain name 99 identifier [RFC8555]. ACME has since been extended to support 100 validation email identifiers [I-D.ietf-acme-email-smime], in support 101 of the issuance of certificates containing email addresses. This 102 latter specification defines a validation method using SMTP, which is 103 unsuitable for applications other than MUAs. 105 This specification introduces a new ACME challenge type to enable 106 validation of email identifiers using common web-oriented single sign 107 on (SSO) identity standards such as SAML [SAML] and OpenID Connect 108 [OPENID]. These standards generally follow a pattern whereby a 109 client initiates authentication with a browser request to some 110 service, the service redirects the client to an identity provider, 111 the provider authenticates the client, the provider redirects the 112 client back to the service along with some assertion as to the 113 client's identity, and finally the service produces some credential 114 or resource authorization to the client. 116 The details of the interaction described above can become complex, 117 and are well documented in the aforementioned specifications. 118 However, since these are web-based interactions, an ACME client need 119 only know how to launch the initial authentication request by opening 120 a given URL within a browser context, and then recognizing when that 121 interaction has concluded. Once concluded, an ACME client can query 122 the ACME server for the status of the challenge to determine whether 123 or not it was successful and, if successful, complete the standard 124 ACME issuance flow. When properly integrated with an application, 125 this extension can allow fully automated certificate issuance, with 126 no user interaction at all. 128 Note that all interactions between an ACME server and the identity 129 providers it relies upon are governed by the specifications of the 130 web-based authentication protocols supported by those services. 131 These are therefore considered out of scope for this document. 133 This document also defines extensions to the Certificate Authority 134 Authorization (CAA) DNS Resource Record type that allows the 135 operators of email domains to express authorizations policies related 136 to email certificates. 138 2. Conventions and Definitions 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in 143 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 3. Protocol Overview 148 The general flow of an SSO challenge is illustrated below, within the 149 context of a standard ACME certificate issuance order. It begins 150 with a new order request to the server, and a response that indicates 151 the authorizations that must be satisfied by the client. The client 152 performs a request on one of these authorizations, and the server 153 response includes a series of challenges that may be used to satisfy 154 the authorization. Among these may be one or more challenges of type 155 "sso-01", each with a distinct "start URL" for initiating a browser- 156 based authentication flow. 158 If the client is already browser-based, it may simply navigate 159 directly to the SSO start URL, providing a redirect URI as a query 160 parameter such that control can eventually return to the client on 161 completion of the authentication flow. If the client is not browser- 162 based, it may launch a native or embedded browser and direct it to 163 the SSO start URL. In many cases this initial request will be 164 serviced directly by the ACME server, however this is not required. 165 The initial request will ultimately redirect the client to an 166 identity provider, along with a request object specific to the SSO 167 standard being employed (e.g. a SAML request). 169 Client ACME Server 171 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ACME client ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 173 request new order -------> 174 <------- required authorizations 175 request authorization -------> 176 <------- SSO challenge with start URL 178 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Browser ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 180 request on SSO start URL -------> 181 <------- ACME redirect to provider 182 w/ authentication request 184 provider authenticates client (not shown) 186 provider redirect to ACME -------> 187 w/ identity assertion 188 validate provider assertion 189 record challenge as valid 190 <------- redirect to client 192 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ACME client ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 194 request challenge -------> 195 <------- valid 196 request finalize (CSR) -------> 197 <------- finalize URL 198 finalize -------> 199 <------- certificate 201 Figure 1: Overview of the SSO Challenge Flow 203 On successful authentication to the identity provider, the client is 204 redirected back to the origin of the provider request, where the 205 provider assertion (e.g. a SAML assertion) is verified, and the ACME 206 server records the associated challenge as having been validated (or 207 not). The client may then be redirected to a redirect URI that was 208 optionally provided as a parameter on the initial SSO start request. 210 The navigation of the browser back to the redirect URI indicates to 211 the client that the authentication flow has completed. At this point 212 the client can invoke the challenge URL to determine whether or not 213 it has been recorded as valid, and subsequently complete the usual 214 ACME issuance flow. 216 4. ACME email Identifier Type 218 The "sso-01" challenge type described in this document applies 219 exclusively to order requests with identifiers of type "email", as 220 described in detail in "Extensions to Automatic Certificate 221 Management Environment for end-user S/MIME certificates" 222 [I-D.ietf-acme-email-smime]. Implementations MUST NOT present 223 challenges of type "sso-01" as options for validation of non-email 224 type identifiers. 226 "identifier": { "type": "email", "value":"alice@example.org"} 228 5. ACME sso-01 Challenge Type 230 The "sso-01" challenge type challenges the client to prove control 231 over an identifier by browsing to the indicated "sso_url" and 232 completing an SSO login for that identifier. A challenge of this 233 type MUST include all required fields described in section 8 of 234 [RFC8555]. In addition, the following fields are defined for this 235 specific type of challenge: 237 sso_url (required, string): The URL from which a web-based 238 identifier validation flow may be initiated. The server must 239 include sufficient information in the URL to allow it to associate 240 the request to a specific challenge so that the challenge status 241 can be updated when the SSO provider redirects the client back to 242 the server. 244 sso_provider (optional, string): The domain of the SSO provider 245 relied upon for this challenge. An ACME server MAY rely upon any 246 number of providers for validating a given identifier, however 247 each MUST be represented as a distinct entry in the "challenges" 248 array. It allows clients to disambiguate lists of providers and 249 choose the most appropriate one. 251 The optional "sso_provider" field is provided as a guide to the 252 client in selecting which "sso-01" challenge to fulfill. For 253 example, a client with access to a browsing context that already has 254 authentication state for a given SSO provider might choose to use a 255 challenge for that provider in order to avoid the need for user 256 interaction. If an "sso_provider" value is not specified, then the 257 web page indicated in the "sso_url" field SHOULD allow the user to 258 select which SSO provider is used for login. The server MUST NOT 259 present more than one "sso-01" challenge in a single authorization 260 with the same "sso_provider" value, including the "value" in which 261 the field is not provided (that is, at most one "sso-01" challenge 262 may omit the "sso_provider" field). 264 A client fulfills to the challenge by first sending an ACME response, 265 then browsing to the SSO URL. The challenge response has a single, 266 optional field: 268 redirect_uri (optional, string): If present, the client will be 269 redirected to the given URI on completion of the "sso-01" 270 challenge. 272 The "redirect_uri" value provides a means for recognizing and 273 resuming client control at the conclusion of an "sso-01" type 274 challenge. For web-based clients, this may mean the redirection of 275 the browser back to the client. For native clients, this may mean 276 the redirection of the browser to a custom scheme handler. A client 277 can also recognize that the SSO process has completed by polling the 278 challenge resource; even a client that receives explicit notification 279 via a "redirect_uri" callback SHOULD verify that the challenge is now 280 valid. 282 The server MUST set the status of the challenge to "processing" after 283 receiving a response from the client. If the client completes the 284 required SSO interaction and the resulting identity assertion 285 validates the claimed email identifier, then the status of the 286 challenge is set to "valid". If the client fails to complete the SSO 287 interaction or the interaction fails to validates the claimed 288 identifier, then the status of the challenge is set to "invalid". 290 { 291 "type": "sso-01", 292 "url": "https://example.org/acme/chall/prV_B7yEyA4", 293 "status": "pending", 294 "sso_url": "https://example.org/acme/start-sso/", 295 "sso_provider": "https://identity-provider.org/sso" 296 } 298 6. Single Sign-On & Order fulfillment 300 The SSO URL allows the client to initiate the SSO flow. It is 301 recommended that this flow be executed in the user's browser. The 302 server must accept GET requests for the SSO URL. On reciept of such 303 a request the must redirect the client to the appropriate SSO 304 provider so that the user may be appropriately authenticated. When 305 the SSO provider has successfully authenticated the user it will 306 redirect the client back to the CA, to a location provided by the CA 307 when the SSO flow was initiated, with an appropriate attestation. 308 The server MUST then verify the providers attestation is valid as 309 specified in the SAML [SAML] or Open ID [OPENID] specifications. 310 Additionally The server MUST verify that the IdP's attestation is 311 valid for the email address the challenge is intended to validate. 313 When the attestation verification is complete it must then update the 314 order status accordingly based on the outcome of the verification. 315 See the {Guidance} section for more information. 317 As defined in section 7.4 of [RFC8555] once the client has been 318 authorized it can proceed with order finalisation. The client SHOULD 319 include the users email identifier in subjectAltName, and if no other 320 identifiers are included in the cert, put it in commonName of the CSR 321 that is submitted to the server. 323 7. Guidance for Email Verification 325 In order to issue a certificate the ACME server requires that the 326 email address be attested by an authoritative service for that email 327 identifier. When the ACME server receives a response from the SSO 328 provider it must verify the provider attestation for the user and 329 then must update the apporpriate challenge status. If the 330 verification of the provider attestation is successful the server 331 updates the challenge status to valid; if not it updates the status 332 to invalid. Any attestation service and method should employ methods 333 to ensure the confidentiality and integrity using the guidance 334 specific to the protocol and/or service chosen. 336 7.1. SAML 338 In the case where SAML is the preferred protocol it is recommended 339 that the 'SSO Profiles of SAML' be used as guidance when implementing 340 the ability to get and handle SAML assertions. In this scenario, an 341 identity provider will act as the asserting party that will generate 342 SAML assertions about a subject (user). The ACME server acts as the 343 relying party that receives assertions from the identity provider. 344 The ACME server should use the relaystate parameter to track order 345 requests between it and the relevant identity provider. When the 346 ACME server receives SAML assertions from the identity provider it 347 should use the afforementioned relaystate to find the order request 348 for which the assertion has been returned. Then using the assertion 349 the ACME server extracts the asserted email identifier and verifies 350 that it matches exactly the email address for which has been 351 specififed in the order. The email address is defined by NameID or 352 specified by the NameIdentifier in the received SAML assertion. This 353 is dependent on the specific SAML configuration for the identity 354 provider. See also [SAML]. Note that there may be specific 355 configuration required to ensure that the email address is 356 appropriately asserted in the SAML assertion generated by the 357 identity provider. 359 7.2. OpenID 361 In this scenario, an OpenID provider will act as the asserting party 362 that will generate ID Tokens about a subject (user). The ACME server 363 acts as the relying party that receives ID Tokens from the OpenID 364 provider. The ACME server only requires ID Tokens with Claims which 365 identify a user - it does not require codes or any other token types 366 and should not request them. It should use the state parameter of 367 the authorize request to track order requests between it OpenID 368 providers. The ACME server on receipt of ID tokens uses the state 369 parameter value to find the appropriate order information. The 370 claims within the ID Token are then used to verify that the email 371 identifier matches exactly the email address for which has been 372 specififed in the order. Specifically the email address will be 373 defined by the email attribute of the ID Token. The server MUST also 374 check that the email_verified attribute of the token is set. The 375 order state is updated with the appropriate valid or invalid state 376 indicating the outcome of this verification. 378 8. CAA for Email Address Certificates 380 The holder of a DNS domain can provision CAA resource records to 381 control which CAs are authorized to issue certificates for the domain 382 and its subdomains [RFC8659]. Here, we extend CAA to allow control 383 over issuance of certificates for email addresses within that domain. 384 The following controls are available: 386 * Which CAs may issue email certificates 388 * What validation methods they may use 390 * What SSO providers the CA may use (a new mechanism defined here) 392 The Relevant RRSet for an email address is located using the "domain" 393 portion of the email address. CAA is only supported for email 394 addresses using the "dot-atom" production for the domain portion, in 395 which case the domain portion is a DNS domain name [RFC5322]. The 396 Relevant RRSet is the Relevant RRSet for this FQDN, according to the 397 algorithm defined in [RFC8659]. 399 Before issuing a certificate, a compliant CA MUST check for 400 publication of a Relevant RRset. If such an RRset exists, a CA MUST 401 NOT issue a certificate unless the CA determines that either (1) the 402 certificate request is consistent with the applicable CAA RRset or 403 (2) an exception specified in the relevant CP or CPS applies. If the 404 Relevant RRset for an email address contains no Property Tags that 405 restrict issuance (for instance, if it contains only iodef Property 406 Tags or only Property Tags unrecognized by the CA), CAA does not 407 restrict issuance. 409 A certificate request MAY specify more than one email address. 410 Issuers MUST verify authorization for all email addresses specified 411 in the request. 413 8.1. CAA issueemail property 415 The CAA "issueemail" property has the same syntax as the "issue" 416 property, and similar semantics. The only difference is that the 417 designated CA is being authorized to issue email address certificates 418 rather than domain name certificates. The CA is requested to: 420 1. Perform CAA issue restriction processing for the FQDN, and 422 2. Grant authorization to issue certificates containing email 423 addresses with domain part equal to the FQDN to the holder of the 424 issuer-domain-name or a party acting under the explicit authority 425 of the holder of the issuer-domain-name. 427 example.com. IN CAA 0 issueemail "ca1.example.net" 428 example.com. IN CAA 0 issueemail "ca2.example.net" 430 A CA consulting CAA records in the process of issuing an email 431 address certificate MUST rely only on "issueemail" Property Tags. In 432 particular, "issue" Property Tags MUST be ignored. Presence of an 433 issueemail Property Tag does not authorize issuance of certificates 434 containing the FQDN or related Wildcard Domain Names. 436 8.2. Usage of the CAA validationmethods Parameter 438 As with domain names, validation of email addresses can be controlled 439 with the "validationmethods" parameter. Validation methods SHOULD 440 NOT be included in this parameter if they are not applicable to email 441 identifiers. As of this writing, the only validation methods defined 442 for email identifiers are "smime-01" and "sso-01" (see 443 [I-D.ietf-acme-email-smime] and Section 5). 445 For example: 447 example.com. IN CAA 0 issueemail "ca1.example.net; validationmethods=email-reply-00" 448 example.com. IN CAA 0 issueemail "ca2.example.net; validationmethods=email-reply-00,sso-01" 450 The above CAA resource record set declares a policy whereby compliant 451 CAs will not issue certificates on the example.com domain unless they 452 self-identify as either ca1.example.net or ca2.example.net. In 453 addition, if these are ACME CAs, then ca1.example.net may only 454 present "smime-01" challenges, whereas ca2.example.net may present 455 both "smime-01" and "sso-01" challenges. 457 8.3. CAA ssoproviders Parameter 459 This document also defines the "ssoproviders" CAA parameter for the 460 "issueemail" Properties. The value of this parameter, if specified, 461 MUST be a comma-separated string of zero or more domain names 462 identifying SSO providers. 464 These domain names correspond to the "sso_provider" attribute of an 465 "sso-01" challenge. The "ssoproviders" parameter SHOULD NOT be 466 provided if "sso-01" is not an allowed challenge type (e.g., if the 467 Property has a "validationmethods" parameter that does not include 468 "sso-01"). 470 The presence of this parameter constrains the Property to which it is 471 attached. A CA MUST only consider a Property with the "ssoproviders" 472 parameter to authorize issuance validation with the "sso-01" 473 validation method if the SSO provider being used is identified by one 474 of the domain names in the comma-separated list. 476 The value of the "ssoproviders" parameter MUST comply with the 477 following ABNF [RFC5234]: 479 provider-domain-name = issuer-domain-name ; see RFC 8659 480 ssoproviders = [\*(provider-domain-name ",") provider-domain-name] 482 Extending the previous example to constrain "ca2.example.net" to only 483 use two specific SSO providers: 485 example.com. IN CAA 0 issueemail "ca1.example.net; validationmethods=email-reply-00" 486 example.com. IN CAA 0 issueemail "ca2.example.net; \ 487 validationmethods=smime-01,sso-01 \ 488 ssoproviders=idp1.example.net,idp2.example.net" 490 The presence of this parameter MUST be regarded by compliant CAs as a 491 restriction on the set of providers they are allowed to rely upon for 492 "sso-01" type challenges. However, an implementation MAY choose to 493 not rely upon any one or all providers named in this property. 495 If this parameter is present but has a zero-length value, 496 implementations MUST NOT rely on any SSO provider. Since the "sso- 497 01" challenge requires an SSO provider, the effect is thus the same 498 as if the "validationmethods" parameter were present and did not 499 include "sso-01". 501 9. Security Considerations 503 This document is an extension to ACME to provide an additional 504 validation method for email identifiers. For general security 505 considerations related to the ACME certificate issuance process, see 506 [RFC8555]. 508 As usual with ACME validation methods, the security of SSO validation 509 comes down to the risk of the validation process being subverted and 510 the strength of the binding between the validation process and the 511 ACME transaction. 513 The binding of the validation process to the ACME transaction is 514 managed via the transaction association mechanisms built into the 515 underlying SSO protocols. For example, in OpenID Connect, the 516 relying party provides a "state" value in its authentication request, 517 which the SSO provider returns alongside the authentication response 518 [OPENID]. 520 As to the security of the SSO-based authentication itself, the usual 521 risks and mitigations associated with user login apply. If the 522 authentication is based solely on passwords, then an attacker that 523 can obtain a user's password can obtain certificates for that user's 524 email address. Standard mitigations such as multi-factor 525 authentication are common features of SSO providers. Especially to 526 the degree that these mitigations provide protections against 527 phishing (as for example with WebAuthentication 528 [W3C.REC-webauthn-1-20190304]), they also protect against the risk 529 that the CA could direct the client to a phishing site instead of the 530 real SSO provider. 532 In SSO-based certificate issuance, the SSO provided is trusted to 533 assert whether a given user owns a given email address. A malicious 534 SSO provider could falsify these assertions to cause a CA relying on 535 it to issue a bad certificate. This risk is especially acute given 536 that the ACME client is trusted to choose which SSO provider is used 537 for a given validation -- a malicious client can direct the CA to use 538 an SSO provider that the client has subverted. 540 The CA's choice of trusted SSO providers is the first line of defense 541 against these risks. The client can only choose from among the SSO 542 providers offered by the CA, so if the CA is judicious in its choice 543 of SSO providers, it can reduce the risk of misissuance. The 544 "ssoproviders" CAA parameter provides a second line of defense, 545 allowing an email domain operator to further restrict the client's 546 choice to the specific set of SSO providers authorized by the email 547 domain operator. 549 10. IANA Considerations 551 [[ TODO ]] 553 11. References 555 11.1. Normative References 557 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 558 Requirement Levels", BCP 14, RFC 2119, 559 DOI 10.17487/RFC2119, March 1997, 560 . 562 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 563 Specifications: ABNF", STD 68, RFC 5234, 564 DOI 10.17487/RFC5234, January 2008, 565 . 567 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 568 DOI 10.17487/RFC5322, October 2008, 569 . 571 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 572 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 573 May 2017, . 575 [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. 576 Kasten, "Automatic Certificate Management Environment 577 (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, 578 . 580 [RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews, 581 "DNS Certification Authority Authorization (CAA) Resource 582 Record", RFC 8659, DOI 10.17487/RFC8659, November 2019, 583 . 585 11.2. Informative References 587 [I-D.ietf-acme-email-smime] 588 Melnikov, A., "Extensions to Automatic Certificate 589 Management Environment for end-user S/MIME certificates", 590 Work in Progress, Internet-Draft, draft-ietf-acme-email- 591 smime-14, 15 February 2021, 592 . 595 [OPENID] Sakimura, N., Bradley, J., Jones, M., De Medeiros, B., and 596 C. Mortimore, "OpenID Connect Core 1.0", November 2014, 597 . 599 [SAML] Cantor, S., Kemp, J., Philpott, R., and E. Maler, 600 "Assertions and Protocol for the OASIS Security 601 Assertion", March 2005, . 604 [W3C.REC-webauthn-1-20190304] 605 Balfanz, D., Czeskis, A., Hodges, J., Jones, J., Jones, 606 M., Kumar, A., Liao, H., Lindemann, R., and E. Lundberg, 607 "Web Authentication:An API for accessing Public Key 608 Credentials Level 1", World Wide Web Consortium 609 Recommendation REC-webauthn-1-20190304, 4 March 2019, 610 . 612 Appendix A. Acknowledgements 614 The authors would like to thank Eric Rescorla, Ryan Hurst, and J.C. 615 Jones for providing feedback on this document and the ideas that went 616 into it. 618 Authors' Addresses 620 Andrew Biggs 621 Cisco 623 Email: adb@cisco.com 625 Richard L. Barnes 626 Cisco 628 Email: rlb@ipv.sx 630 Rory Moynihan 631 Cisco 633 Email: rmoyniha@cisco.com