Subject: [Acme] Fwd: New Version Notification for draft-biggs-acme-sso-00.txt

From: Richard Barnes <[email-masked]>
Date: Wed, 9 Dec 2020 12:00:08 -0500

Hi ACME folks,

I'd like to bring this proposed extension to ACME to the attention of the
working group.  This work builds on Alexei's document defining the "email"
identifier type, and defines (1) a mechanism for validating email addresses
using SSO, and (2) some CAA mechanisms to manage issuance of certificates
with email addresses.

I would like for the ACME WG to take this on as a work item, as a logical
next step following on draft-ietf-acme-email-smime.  Any feedback on the
draft would be very welcome.

Thanks,
--Richard

---------- Forwarded message ---------
From: <[email-masked]>
Date: Tue, Dec 8, 2020 at 10:09 AM
Subject: New Version Notification for draft-biggs-acme-sso-00.txt
To: Andrew Biggs <[email-masked]>, Richard L. Barnes <[email-masked]>

A new version of I-D, draft-biggs-acme-sso-00.txt
has been successfully submitted by Richard Barnes and posted to the
IETF repository.

Name:           draft-biggs-acme-sso
Revision:       00
Title:          Automated Certificate Management Environment (ACME)
Extension for Single Sign On Challenges
Document date:  2020-12-08
Group:          Individual Submission
Pages:          12
URL:            https://www.ietf.org/archive/id/draft-biggs-acme-sso-00.txt
Status:         https://datatracker.ietf.org/doc/draft-biggs-acme-sso/
Html:           https://www.ietf.org/archive/id/draft-biggs-acme-sso-00.html
Htmlized:       https://tools.ietf.org/html/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.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 9 Dec 2020 17:08:44 -0500

On Wed, Dec 9, 2020 at 12:00 PM Richard Barnes <[email-masked]> wrote:

> identifier type, and defines
>

> (1) a mechanism for validating email addresses using SSO,
>

Apologies for pedantry here, but is this really validating e-mail
addresses? It seems like it's delegating validation to an IDP? This might
be more of a "Web PKI" semantic quibble, and I understand your plan is to
*not* use such CAs and might be moot, but it seems an important enough
distinction to call out.

That is, as I understand it, the domain holder indicates an SSO IDP that
the CA may trust assertions for. The CA then directs the Applicant to
authenticate with the IDP, and the IDP returns an assertion to the CA. The
CA then accepts that assertion, provided that the global-part (dot-atom)
matches, right? The validation isn't of an e-mail address; the validation
is of an IDP declaring that e-mail address associated with a given account
(e.g. a JWT, a SAML assertion, etc).

Note: Is referencing dot-atom correct, in this case, since rfc822Name is
restricted to preferred name syntax by virtue of the dependency on RFC
2821, as constrained by Section 2.3.5 (
https://tools.ietf.org/html/rfc2821#section-2.3.5 )

> and (2) some CAA mechanisms to manage issuance of certificates with email
> addresses.
>

Did I miss a normative dependency on / informative reference to RFC 8657
here? It seems relevant, since this is repurposing the parameter space that
is CA specific (as called out by
https://tools.ietf.org/html/rfc8657#section-6 ), and there's explicitly no
IANA registry to deconflict because of that. I realize that the parameters
are also specific to the tag, which you're defining a new tag here, but
this all seems... messy? That is, to have "validationmethods"  semantics
not depend on the CA (as it does for issue/issuewild) but instead depend on
whether it's issue vs issue-email.

> draft would be very welcome.

I'm hesitant as to whether this is a good idea, because this seems like a
significant shift in the level of assurance / what's validated, so I don't
think it's as clear a logical next step. While I don't plan to implement
(and would be opposed to implementing for trusted S/MIME CAs, for example),
I acknowledge it has interest for other use cases, and so would be
supportive of adopting in order to continue refining the security
considerations to be more explicit that validation is being delegated to a
third-party, rather than performed by the CA.

> URL:
> https://www.ietf.org/archive/id/draft-biggs-acme-sso-00.txt
> Html:
> https://www.ietf.org/archive/id/draft-biggs-acme-sso-00.html
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>