Automated Certificate Management Environment (ACME) Extension for Single Sign On Challenges
draft-biggs-acme-sso-00
ACME WG A. Biggs
Internet-Draft R.L. Barnes
Intended status: Informational Cisco
Expires: 11 June 2021 8 December 2020
Automated Certificate Management Environment (ACME) Extension for Single
Sign On Challenges
draft-biggs-acme-sso-00
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.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/bifurcation/acme-sso.
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 11 June 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
Biggs & Barnes Expires 11 June 2021 [Page 1]
Internet-Draft ACME-SSO December 2020
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
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. CAA for Email Address Certificates . . . . . . . . . . . . . 7
6.1. CAA issueemail property . . . . . . . . . . . . . . . . . 8
6.2. Usage of the CAA validationmethods Parameter . . . . . . 8
6.3. CAA ssoproviders Parameter . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Collaboration applications are increasingly using end-to-end
encryption to protect user content. These applications 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 & Barnes Expires 11 June 2021 [Page 2]
Show full document text