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
>