On Wed, Dec 9, 2020 at 12:00 PM Richard Barnes <r...@ipv.sx> wrote: > 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, > 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. > 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. > 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. > > Thanks, > --Richard > > > ---------- Forwarded message --------- > From: <internet-dra...@ietf.org> > Date: Tue, Dec 8, 2020 at 10:09 AM > Subject: New Version Notification for draft-biggs-acme-sso-00.txt > To: Andrew Biggs <a...@cisco.com>, Richard L. Barnes <r...@ipv.sx> > > > > 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 > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
