Re: [Acme] Fwd: New Version Notification for draft-biggs-acme-sso-00.txt
Ryan Sleevi <ryan-ietf@sleevi.com> Wed, 09 December 2020 22:09 UTC
Return-Path: <ryan.sleevi@gmail.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3085E3A17A7 for <acme@ietfa.amsl.com>; Wed, 9 Dec 2020 14:09:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.419
X-Spam-Level:
X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weero7H1L7IU for <acme@ietfa.amsl.com>; Wed, 9 Dec 2020 14:08:57 -0800 (PST)
Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4DAB3A1207 for <acme@ietf.org>; Wed, 9 Dec 2020 14:08:57 -0800 (PST)
Received: by mail-pl1-f170.google.com with SMTP id u4so1688077plr.12 for <acme@ietf.org>; Wed, 09 Dec 2020 14:08:57 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lfUd53gA6hcjnGurxSLEScSffjQc8SIqOsNh9h9qomk=; b=Cjjc7O8jtetPdPVuE6xIohy9s4ssQdEAi8gl9A9gtPOzpEzR08MBrl22WgVriZkqfm 7FMS3/IvNpTrsF42ThdHGxTe1wQbp7xqnv+EBGPUReCQblD8aA+IeumROGzLOA1CjwX+ g85RGChfRjPrZk4ivmPSwXy1Sae6xxIfdkLRlPgvVf7KcCGMH02adnabiOhed3BeD7nz 3mJjUyBbhKQZ6zHS74kHl+aUNojiXFl4yZYYKbQ8DKEIhDAH0VZA2YutFT1v5SPLAr0s BR0hjD7NNVtkgvDyAkNGxoDfDJA+bJBKYjo1B/15JG0pNJs94af0TRGTUf5eA7+NZofa RAyw==
X-Gm-Message-State: AOAM530ojUEMN0GAf+29bVtTPelBOxI5fvA+4FVcoDwYgnDypSSERLuD r+zjNeSrxgssfMVIj1Z7d1NLaJJ8fZM=
X-Google-Smtp-Source: ABdhPJyyvSJVZbHXZScsBJiJ9XvWaCqVuMxIqi+Y10mwF7Lg7Yrz2JoCJezkeBFk7WOqFZKBQV+gOw==
X-Received: by 2002:a17:902:7297:b029:da:861e:eae1 with SMTP id d23-20020a1709027297b02900da861eeae1mr3850829pll.8.1607551736892; Wed, 09 Dec 2020 14:08:56 -0800 (PST)
Received: from mail-pg1-f179.google.com (mail-pg1-f179.google.com. [209.85.215.179]) by smtp.gmail.com with ESMTPSA id k18sm3223318pjz.26.2020.12.09.14.08.56 for <acme@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 09 Dec 2020 14:08:56 -0800 (PST)
Received: by mail-pg1-f179.google.com with SMTP id n7so2237094pgg.2 for <acme@ietf.org>; Wed, 09 Dec 2020 14:08:56 -0800 (PST)
X-Received: by 2002:a63:494f:: with SMTP id y15mr3823277pgk.364.1607551735445; Wed, 09 Dec 2020 14:08:55 -0800 (PST)
MIME-Version: 1.0
References: <160744016926.7556.727252086744891540@ietfa.amsl.com> <CAL02cgSti9SQ7Z6mq9oD-4GeNU+ver7MZCueff2A3SmZn=4gOw@mail.gmail.com>
In-Reply-To: <CAL02cgSti9SQ7Z6mq9oD-4GeNU+ver7MZCueff2A3SmZn=4gOw@mail.gmail.com>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Wed, 09 Dec 2020 17:08:44 -0500
X-Gmail-Original-Message-ID: <CAErg=HGEuOUbPSixs4713VixfXn+FozNq0gC2xWpUBA29wKGxQ@mail.gmail.com>
Message-ID: <CAErg=HGEuOUbPSixs4713VixfXn+FozNq0gC2xWpUBA29wKGxQ@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
Cc: IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000263f6305b60f4e6c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/fMq7Xa0QdkTyovaHKG6fHC2ucDw>
Subject: Re: [Acme] Fwd: New Version Notification for draft-biggs-acme-sso-00.txt
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Dec 2020 22:09:03 -0000
On Wed, Dec 9, 2020 at 12:00 PM Richard Barnes <rlb@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-drafts@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 <adb@cisco.com>, Richard L. Barnes <rlb@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] Fwd: New Version Notification for draft-bi… Richard Barnes
- Re: [Acme] Fwd: New Version Notification for draf… Ryan Sleevi
- Re: [Acme] Fwd: New Version Notification for draf… Salz, Rich