[Search] [txt|html|xml|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
TODO Working Group                                              A. Biggs
Internet-Draft                                               R.L. Barnes
Intended status: Informational                               R. Moynihan
Expires: 10 October 2021                                           Cisco
                                                            8 April 2021


Automated Certificate Management Environment (ACME) Extension for Single
                           Sign On Challenges
                        draft-biggs-acme-sso-01

Abstract

   This document specifies an extension to the ACME protocol [RFC8555]
   to enable ACME servers to validate a client's control of an email
   identifier using single sign-on (SSO) technologies.  An extension to
   the CAA [RFC8659] resource record specification is also defined to
   provide domain owners a means to declare a set of SSO providers that
   ACME servers may rely upon when employing SSO for identifier
   validation on their domain.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 10 October 2021.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components



Biggs, et al.            Expires 10 October 2021                [Page 1]


Internet-Draft                  ACME-SSO                      April 2021


   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
   4.  ACME email Identifier Type  . . . . . . . . . . . . . . . . .   6
   5.  ACME sso-01 Challenge Type  . . . . . . . . . . . . . . . . .   6
   6.  Single Sign-On & Order fulfillment  . . . . . . . . . . . . .   7
   7.  Guidance for Email Verification . . . . . . . . . . . . . . .   8
     7.1.  SAML  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.2.  OpenID  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   8.  CAA for Email Address Certificates  . . . . . . . . . . . . .   9
     8.1.  CAA issueemail property . . . . . . . . . . . . . . . . .  10
     8.2.  Usage of the CAA validationmethods Parameter  . . . . . .  10
     8.3.  CAA ssoproviders Parameter  . . . . . . . . . . . . . . .  11
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     11.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   Applications are increasingly using end-to-end encryption to protect
   user content and frequently use email addresses to identify users.
   In such contexts, the use of X.509 certificates binding email
   addresses to public keys is a natural authentication mechanism.  If
   the issuer of the certificate is separate from the application
   provider, and validates control of the email address independently of
   the application provider, then the resulting certificate can be used
   to provide end-to-end authentication, in the sense that the
   application provider is unable to impersonate the authenticated user.

   Historically, certificates for email addresses have been difficult to
   obtain.  Current end-to-end encrypted communications applications
   typically rely on laborious, error-prone manual authentication
   processes, often based on comparing opaque "security codes" or
   "safety numbers".  Thus, in practice, end-to-end encrypted
   communications are usually vulnerable to impersonation attacks by the
   application provider.





Biggs, et al.            Expires 10 October 2021                [Page 2]


Internet-Draft                  ACME-SSO                      April 2021


   When ACME was first introduced, its primary focus was on issuing
   certificates for domain names, and the base specification contains
   challenges for validating a client's control over a domain name
   identifier [RFC8555].  ACME has since been extended to support
   validation email identifiers [I-D.ietf-acme-email-smime], in support
   of the issuance of certificates containing email addresses.  This
   latter specification defines a validation method using SMTP, which is
   unsuitable for applications other than MUAs.

   This specification introduces a new ACME challenge type to enable
   validation of email identifiers using common web-oriented single sign
   on (SSO) identity standards such as SAML [SAML] and OpenID Connect
   [OPENID].  These standards generally follow a pattern whereby a
   client initiates authentication with a browser request to some
   service, the service redirects the client to an identity provider,
   the provider authenticates the client, the provider redirects the
   client back to the service along with some assertion as to the
   client's identity, and finally the service produces some credential
   or resource authorization to the client.

   The details of the interaction described above can become complex,
   and are well documented in the aforementioned specifications.
   However, since these are web-based interactions, an ACME client need
   only know how to launch the initial authentication request by opening
   a given URL within a browser context, and then recognizing when that
   interaction has concluded.  Once concluded, an ACME client can query
   the ACME server for the status of the challenge to determine whether
   or not it was successful and, if successful, complete the standard
   ACME issuance flow.  When properly integrated with an application,
   this extension can allow fully automated certificate issuance, with
   no user interaction at all.

   Note that all interactions between an ACME server and the identity
   providers it relies upon are governed by the specifications of the
   web-based authentication protocols supported by those services.
   These are therefore considered out of scope for this document.

   This document also defines extensions to the Certificate Authority
   Authorization (CAA) DNS Resource Record type that allows the
   operators of email domains to express authorizations policies related
   to email certificates.










Biggs, et al.            Expires 10 October 2021                [Page 3]


Internet-Draft                  ACME-SSO                      April 2021


2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Protocol Overview

   The general flow of an SSO challenge is illustrated below, within the
   context of a standard ACME certificate issuance order.  It begins
   with a new order request to the server, and a response that indicates
   the authorizations that must be satisfied by the client.  The client
   performs a request on one of these authorizations, and the server
   response includes a series of challenges that may be used to satisfy
   the authorization.  Among these may be one or more challenges of type
   "sso-01", each with a distinct "start URL" for initiating a browser-
   based authentication flow.

   If the client is already browser-based, it may simply navigate
   directly to the SSO start URL, providing a redirect URI as a query
   parameter such that control can eventually return to the client on
   completion of the authentication flow.  If the client is not browser-
   based, it may launch a native or embedded browser and direct it to
   the SSO start URL.  In many cases this initial request will be
   serviced directly by the ACME server, however this is not required.
   The initial request will ultimately redirect the client to an
   identity provider, along with a request object specific to the SSO
   standard being employed (e.g. a SAML request).





















Biggs, et al.            Expires 10 October 2021                [Page 4]


Internet-Draft                  ACME-SSO                      April 2021


   Client                                                    ACME Server

   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ACME client ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   request new order             ------->
                                 <-------        required authorizations
   request authorization         ------->
                                 <-------   SSO challenge with start URL

   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Browser ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   request on SSO start URL      ------->
                                 <-------      ACME redirect to provider
                                               w/ authentication request

                provider authenticates client (not shown)

   provider redirect to ACME     ------->
   w/ identity assertion
                                             validate provider assertion
                                               record challenge as valid
                                 <-------             redirect to client

   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ACME client ~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   request challenge             ------->
                                 <-------                          valid
   request finalize (CSR)        ------->
                                 <-------                   finalize URL
   finalize                      ------->
                                 <-------                    certificate

                Figure 1: Overview of the SSO Challenge Flow

   On successful authentication to the identity provider, the client is
   redirected back to the origin of the provider request, where the
   provider assertion (e.g. a SAML assertion) is verified, and the ACME
   server records the associated challenge as having been validated (or
   not).  The client may then be redirected to a redirect URI that was
   optionally provided as a parameter on the initial SSO start request.

   The navigation of the browser back to the redirect URI indicates to
   the client that the authentication flow has completed.  At this point
   the client can invoke the challenge URL to determine whether or not
   it has been recorded as valid, and subsequently complete the usual
   ACME issuance flow.





Biggs, et al.            Expires 10 October 2021                [Page 5]


Internet-Draft                  ACME-SSO                      April 2021


4.  ACME email Identifier Type

   The "sso-01" challenge type described in this document applies
   exclusively to order requests with identifiers of type "email", as
   described in detail in "Extensions to Automatic Certificate
   Management Environment for end-user S/MIME certificates"
   [I-D.ietf-acme-email-smime].  Implementations MUST NOT present
   challenges of type "sso-01" as options for validation of non-email
   type identifiers.

   "identifier": { "type": "email", "value":"alice@example.org"}

5.  ACME sso-01 Challenge Type

   The "sso-01" challenge type challenges the client to prove control
   over an identifier by browsing to the indicated "sso_url" and
   completing an SSO login for that identifier.  A challenge of this
   type MUST include all required fields described in section 8 of
   [RFC8555].  In addition, the following fields are defined for this
   specific type of challenge:

   sso_url (required, string):  The URL from which a web-based
      identifier validation flow may be initiated.  The server must
      include sufficient information in the URL to allow it to associate
      the request to a specific challenge so that the challenge status
      can be updated when the SSO provider redirects the client back to
      the server.

   sso_provider (optional, string):  The domain of the SSO provider
      relied upon for this challenge.  An ACME server MAY rely upon any
      number of providers for validating a given identifier, however
      each MUST be represented as a distinct entry in the "challenges"
      array.  It allows clients to disambiguate lists of providers and
      choose the most appropriate one.

   The optional "sso_provider" field is provided as a guide to the
   client in selecting which "sso-01" challenge to fulfill.  For
   example, a client with access to a browsing context that already has
   authentication state for a given SSO provider might choose to use a
   challenge for that provider in order to avoid the need for user
   interaction.  If an "sso_provider" value is not specified, then the
   web page indicated in the "sso_url" field SHOULD allow the user to
   select which SSO provider is used for login.  The server MUST NOT
   present more than one "sso-01" challenge in a single authorization
   with the same "sso_provider" value, including the "value" in which
   the field is not provided (that is, at most one "sso-01" challenge
   may omit the "sso_provider" field).




Biggs, et al.            Expires 10 October 2021                [Page 6]


Internet-Draft                  ACME-SSO                      April 2021


   A client fulfills to the challenge by first sending an ACME response,
   then browsing to the SSO URL.  The challenge response has a single,
   optional field:

   redirect_uri (optional, string):  If present, the client will be
      redirected to the given URI on completion of the "sso-01"
      challenge.

   The "redirect_uri" value provides a means for recognizing and
   resuming client control at the conclusion of an "sso-01" type
   challenge.  For web-based clients, this may mean the redirection of
   the browser back to the client.  For native clients, this may mean
   the redirection of the browser to a custom scheme handler.  A client
   can also recognize that the SSO process has completed by polling the
   challenge resource; even a client that receives explicit notification
   via a "redirect_uri" callback SHOULD verify that the challenge is now
   valid.

   The server MUST set the status of the challenge to "processing" after
   receiving a response from the client.  If the client completes the
   required SSO interaction and the resulting identity assertion
   validates the claimed email identifier, then the status of the
   challenge is set to "valid".  If the client fails to complete the SSO
   interaction or the interaction fails to validates the claimed
   identifier, then the status of the challenge is set to "invalid".

   {
        "type": "sso-01",
        "url": "https://example.org/acme/chall/prV_B7yEyA4",
        "status": "pending",
        "sso_url": "https://example.org/acme/start-sso/",
        "sso_provider": "https://identity-provider.org/sso"
   }

6.  Single Sign-On & Order fulfillment

   The SSO URL allows the client to initiate the SSO flow.  It is
   recommended that this flow be executed in the user's browser.  The
   server must accept GET requests for the SSO URL.  On reciept of such
   a request the must redirect the client to the appropriate SSO
   provider so that the user may be appropriately authenticated.  When
   the SSO provider has successfully authenticated the user it will
   redirect the client back to the CA, to a location provided by the CA
   when the SSO flow was initiated, with an appropriate attestation.
   The server MUST then verify the providers attestation is valid as
   specified in the SAML [SAML] or Open ID [OPENID] specifications.
   Additionally The server MUST verify that the IdP's attestation is
   valid for the email address the challenge is intended to validate.



Biggs, et al.            Expires 10 October 2021                [Page 7]


Internet-Draft                  ACME-SSO                      April 2021


   When the attestation verification is complete it must then update the
   order status accordingly based on the outcome of the verification.
   See the {Guidance} section for more information.

   As defined in section 7.4 of [RFC8555] once the client has been
   authorized it can proceed with order finalisation.  The client SHOULD
   include the users email identifier in subjectAltName, and if no other
   identifiers are included in the cert, put it in commonName of the CSR
   that is submitted to the server.

7.  Guidance for Email Verification

   In order to issue a certificate the ACME server requires that the
   email address be attested by an authoritative service for that email
   identifier.  When the ACME server receives a response from the SSO
   provider it must verify the provider attestation for the user and
   then must update the apporpriate challenge status.  If the
   verification of the provider attestation is successful the server
   updates the challenge status to valid; if not it updates the status
   to invalid.  Any attestation service and method should employ methods
   to ensure the confidentiality and integrity using the guidance
   specific to the protocol and/or service chosen.

7.1.  SAML

   In the case where SAML is the preferred protocol it is recommended
   that the 'SSO Profiles of SAML' be used as guidance when implementing
   the ability to get and handle SAML assertions.  In this scenario, an
   identity provider will act as the asserting party that will generate
   SAML assertions about a subject (user).  The ACME server acts as the
   relying party that receives assertions from the identity provider.
   The ACME server should use the relaystate parameter to track order
   requests between it and the relevant identity provider.  When the
   ACME server receives SAML assertions from the identity provider it
   should use the afforementioned relaystate to find the order request
   for which the assertion has been returned.  Then using the assertion
   the ACME server extracts the asserted email identifier and verifies
   that it matches exactly the email address for which has been
   specififed in the order.  The email address is defined by NameID or
   specified by the NameIdentifier in the received SAML assertion.  This
   is dependent on the specific SAML configuration for the identity
   provider.  See also [SAML].  Note that there may be specific
   configuration required to ensure that the email address is
   appropriately asserted in the SAML assertion generated by the
   identity provider.






Biggs, et al.            Expires 10 October 2021                [Page 8]


Internet-Draft                  ACME-SSO                      April 2021


7.2.  OpenID

   In this scenario, an OpenID provider will act as the asserting party
   that will generate ID Tokens about a subject (user).  The ACME server
   acts as the relying party that receives ID Tokens from the OpenID
   provider.  The ACME server only requires ID Tokens with Claims which
   identify a user - it does not require codes or any other token types
   and should not request them.  It should use the state parameter of
   the authorize request to track order requests between it OpenID
   providers.  The ACME server on receipt of ID tokens uses the state
   parameter value to find the appropriate order information.  The
   claims within the ID Token are then used to verify that the email
   identifier matches exactly the email address for which has been
   specififed in the order.  Specifically the email address will be
   defined by the email attribute of the ID Token.  The server MUST also
   check that the email_verified attribute of the token is set.  The
   order state is updated with the appropriate valid or invalid state
   indicating the outcome of this verification.

8.  CAA for Email Address Certificates

   The holder of a DNS domain can provision CAA resource records to
   control which CAs are authorized to issue certificates for the domain
   and its subdomains [RFC8659].  Here, we extend CAA to allow control
   over issuance of certificates for email addresses within that domain.
   The following controls are available:

   *  Which CAs may issue email certificates

   *  What validation methods they may use

   *  What SSO providers the CA may use (a new mechanism defined here)

   The Relevant RRSet for an email address is located using the "domain"
   portion of the email address.  CAA is only supported for email
   addresses using the "dot-atom" production for the domain portion, in
   which case the domain portion is a DNS domain name [RFC5322].  The
   Relevant RRSet is the Relevant RRSet for this FQDN, according to the
   algorithm defined in [RFC8659].












Biggs, et al.            Expires 10 October 2021                [Page 9]


Internet-Draft                  ACME-SSO                      April 2021


   Before issuing a certificate, a compliant CA MUST check for
   publication of a Relevant RRset.  If such an RRset exists, a CA MUST
   NOT issue a certificate unless the CA determines that either (1) the
   certificate request is consistent with the applicable CAA RRset or
   (2) an exception specified in the relevant CP or CPS applies.  If the
   Relevant RRset for an email address contains no Property Tags that
   restrict issuance (for instance, if it contains only iodef Property
   Tags or only Property Tags unrecognized by the CA), CAA does not
   restrict issuance.

   A certificate request MAY specify more than one email address.
   Issuers MUST verify authorization for all email addresses specified
   in the request.

8.1.  CAA issueemail property

   The CAA "issueemail" property has the same syntax as the "issue"
   property, and similar semantics.  The only difference is that the
   designated CA is being authorized to issue email address certificates
   rather than domain name certificates.  The CA is requested to:

   1.  Perform CAA issue restriction processing for the FQDN, and

   2.  Grant authorization to issue certificates containing email
       addresses with domain part equal to the FQDN to the holder of the
       issuer-domain-name or a party acting under the explicit authority
       of the holder of the issuer-domain-name.

   example.com. IN CAA 0 issueemail "ca1.example.net"
   example.com. IN CAA 0 issueemail "ca2.example.net"

   A CA consulting CAA records in the process of issuing an email
   address certificate MUST rely only on "issueemail" Property Tags.  In
   particular, "issue" Property Tags MUST be ignored.  Presence of an
   issueemail Property Tag does not authorize issuance of certificates
   containing the FQDN or related Wildcard Domain Names.

8.2.  Usage of the CAA validationmethods Parameter

   As with domain names, validation of email addresses can be controlled
   with the "validationmethods" parameter.  Validation methods SHOULD
   NOT be included in this parameter if they are not applicable to email
   identifiers.  As of this writing, the only validation methods defined
   for email identifiers are "smime-01" and "sso-01" (see
   [I-D.ietf-acme-email-smime] and Section 5).

   For example:




Biggs, et al.            Expires 10 October 2021               [Page 10]


Internet-Draft                  ACME-SSO                      April 2021


example.com. IN CAA 0 issueemail "ca1.example.net; validationmethods=email-reply-00"
example.com. IN CAA 0 issueemail "ca2.example.net; validationmethods=email-reply-00,sso-01"

   The above CAA resource record set declares a policy whereby compliant
   CAs will not issue certificates on the example.com domain unless they
   self-identify as either ca1.example.net or ca2.example.net.  In
   addition, if these are ACME CAs, then ca1.example.net may only
   present "smime-01" challenges, whereas ca2.example.net may present
   both "smime-01" and "sso-01" challenges.

8.3.  CAA ssoproviders Parameter

   This document also defines the "ssoproviders" CAA parameter for the
   "issueemail" Properties.  The value of this parameter, if specified,
   MUST be a comma-separated string of zero or more domain names
   identifying SSO providers.

   These domain names correspond to the "sso_provider" attribute of an
   "sso-01" challenge.  The "ssoproviders" parameter SHOULD NOT be
   provided if "sso-01" is not an allowed challenge type (e.g., if the
   Property has a "validationmethods" parameter that does not include
   "sso-01").

   The presence of this parameter constrains the Property to which it is
   attached.  A CA MUST only consider a Property with the "ssoproviders"
   parameter to authorize issuance validation with the "sso-01"
   validation method if the SSO provider being used is identified by one
   of the domain names in the comma-separated list.

   The value of the "ssoproviders" parameter MUST comply with the
   following ABNF [RFC5234]:

provider-domain-name = issuer-domain-name ; see RFC 8659
        ssoproviders = [\*(provider-domain-name ",") provider-domain-name]

   Extending the previous example to constrain "ca2.example.net" to only
   use two specific SSO providers:

example.com. IN CAA 0 issueemail "ca1.example.net; validationmethods=email-reply-00"
example.com. IN CAA 0 issueemail "ca2.example.net; \
  validationmethods=smime-01,sso-01 \
  ssoproviders=idp1.example.net,idp2.example.net"

   The presence of this parameter MUST be regarded by compliant CAs as a
   restriction on the set of providers they are allowed to rely upon for
   "sso-01" type challenges.  However, an implementation MAY choose to
   not rely upon any one or all providers named in this property.




Biggs, et al.            Expires 10 October 2021               [Page 11]


Internet-Draft                  ACME-SSO                      April 2021


   If this parameter is present but has a zero-length value,
   implementations MUST NOT rely on any SSO provider.  Since the "sso-
   01" challenge requires an SSO provider, the effect is thus the same
   as if the "validationmethods" parameter were present and did not
   include "sso-01".

9.  Security Considerations

   This document is an extension to ACME to provide an additional
   validation method for email identifiers.  For general security
   considerations related to the ACME certificate issuance process, see
   [RFC8555].

   As usual with ACME validation methods, the security of SSO validation
   comes down to the risk of the validation process being subverted and
   the strength of the binding between the validation process and the
   ACME transaction.

   The binding of the validation process to the ACME transaction is
   managed via the transaction association mechanisms built into the
   underlying SSO protocols.  For example, in OpenID Connect, the
   relying party provides a "state" value in its authentication request,
   which the SSO provider returns alongside the authentication response
   [OPENID].

   As to the security of the SSO-based authentication itself, the usual
   risks and mitigations associated with user login apply.  If the
   authentication is based solely on passwords, then an attacker that
   can obtain a user's password can obtain certificates for that user's
   email address.  Standard mitigations such as multi-factor
   authentication are common features of SSO providers.  Especially to
   the degree that these mitigations provide protections against
   phishing (as for example with WebAuthentication
   [W3C.REC-webauthn-1-20190304]), they also protect against the risk
   that the CA could direct the client to a phishing site instead of the
   real SSO provider.

   In SSO-based certificate issuance, the SSO provided is trusted to
   assert whether a given user owns a given email address.  A malicious
   SSO provider could falsify these assertions to cause a CA relying on
   it to issue a bad certificate.  This risk is especially acute given
   that the ACME client is trusted to choose which SSO provider is used
   for a given validation -- a malicious client can direct the CA to use
   an SSO provider that the client has subverted.

   The CA's choice of trusted SSO providers is the first line of defense
   against these risks.  The client can only choose from among the SSO
   providers offered by the CA, so if the CA is judicious in its choice



Biggs, et al.            Expires 10 October 2021               [Page 12]


Internet-Draft                  ACME-SSO                      April 2021


   of SSO providers, it can reduce the risk of misissuance.  The
   "ssoproviders" CAA parameter provides a second line of defense,
   allowing an email domain operator to further restrict the client's
   choice to the specific set of SSO providers authorized by the email
   domain operator.

10.  IANA Considerations

   [[ TODO ]]

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
              Kasten, "Automatic Certificate Management Environment
              (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
              <https://www.rfc-editor.org/info/rfc8555>.

   [RFC8659]  Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews,
              "DNS Certification Authority Authorization (CAA) Resource
              Record", RFC 8659, DOI 10.17487/RFC8659, November 2019,
              <https://www.rfc-editor.org/info/rfc8659>.

11.2.  Informative References

   [I-D.ietf-acme-email-smime]
              Melnikov, A., "Extensions to Automatic Certificate
              Management Environment for end-user S/MIME certificates",
              Work in Progress, Internet-Draft, draft-ietf-acme-email-



Biggs, et al.            Expires 10 October 2021               [Page 13]


Internet-Draft                  ACME-SSO                      April 2021


              smime-14, 15 February 2021,
              <https://www.ietf.org/archive/id/draft-ietf-acme-email-
              smime-14.txt>.

   [OPENID]   Sakimura, N., Bradley, J., Jones, M., De Medeiros, B., and
              C. Mortimore, "OpenID Connect Core 1.0", November 2014,
              <https://openid.net/specs/openid-connect-core-1_0.html>.

   [SAML]     Cantor, S., Kemp, J., Philpott, R., and E. Maler,
              "Assertions and Protocol for the OASIS Security
              Assertion", March 2005, <http://docs.oasis-
              open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.

   [W3C.REC-webauthn-1-20190304]
              Balfanz, D., Czeskis, A., Hodges, J., Jones, J., Jones,
              M., Kumar, A., Liao, H., Lindemann, R., and E. Lundberg,
              "Web Authentication:An API for accessing Public Key
              Credentials Level 1", World Wide Web Consortium
              Recommendation REC-webauthn-1-20190304, 4 March 2019,
              <https://www.w3.org/TR/2019/REC-webauthn-1-20190304>.

Appendix A.  Acknowledgements

   The authors would like to thank Eric Rescorla, Ryan Hurst, and J.C.
   Jones for providing feedback on this document and the ideas that went
   into it.

Authors' Addresses

   Andrew Biggs
   Cisco

   Email: adb@cisco.com


   Richard L. Barnes
   Cisco

   Email: rlb@ipv.sx


   Rory Moynihan
   Cisco

   Email: rmoyniha@cisco.com






Biggs, et al.            Expires 10 October 2021               [Page 14]