Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls
Brian Campbell <bcampbell@pingidentity.com> Wed, 03 July 2019 11:29 UTC
Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3923212021C for <oauth@ietfa.amsl.com>; Wed, 3 Jul 2019 04:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
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 j8ExbagP38Sk for <oauth@ietfa.amsl.com>; Wed, 3 Jul 2019 04:29:12 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 D5C3D120778 for <oauth@ietf.org>; Wed, 3 Jul 2019 04:29:11 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id i10so3816766iol.13 for <oauth@ietf.org>; Wed, 03 Jul 2019 04:29:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n3Dz5qeyBfMnLBEHPZm8giTKzjT5npZDEBCy3KpvXKM=; b=Ee+KyKlnkrOCbQEAPB8GYqUFJICnNcomMy2GLfET9VOv1Dwsn2Gm0NRBhXx5PVeQ4W B9bm9hXq+Y2ljY64EDfw+IApIDmGAc4irMOpPPuQYfScTyWThy+cmh9T8htwTkM44oXs S7k5h0kMfjwB9ZaTFJ56kve8ymCIDatj1bLLI=
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=n3Dz5qeyBfMnLBEHPZm8giTKzjT5npZDEBCy3KpvXKM=; b=Kqn88/r5Rq5t1rUCox2xGZ9u2IBKhRAvn1mqMB7gS001JSmk5QrobnqmKoiP54z2z7 pvOn99FYU+Gd0qScd9xoGi8fLwq2ojY7VH0lvpbrCNjerApRKkT55UUa6G+qoK6yZj28 98a48utkBocqUTzZJT27xlpGlOTs325+Kqd0OJ8w7vKTUKsE37EZcZKkr/F65bCSZcf4 xZGpRsTE9vr+OkmXlkOVSXEx7FxGZ4n7S9UhW5v7AjPvjGBGn/MLUc6+wUBiwH7C+GEb a/zU4n79hGdxPLc1d+AE62ItoJimWTLW3lTy/1LYRtrjyC0RrEYdCYilBzEA/tZOovyY qyzw==
X-Gm-Message-State: APjAAAVBBe7T+G2t/N237cqxgVk2Dmq10nBQ96ln0t3JTcIJFtNAbpuY WZS0xGAWbDp64xjG5KNMFJB+IiO7YGt8mnwvHmjhCZcI2lw2LQx/CY2YklUqJ3HHwZ8l2lBko69 a/WJMXdyMmWfyXQ==
X-Google-Smtp-Source: APXvYqzaEFZsal09jM3gmiR8/5QgdW26AiPxZC1V/i4fh2Zfezt1Nc2iaIufT7yEnlLiuTagP+cd/93Ygo087Jgy8ng=
X-Received: by 2002:a6b:ce19:: with SMTP id p25mr8752840iob.201.1562153351003; Wed, 03 Jul 2019 04:29:11 -0700 (PDT)
MIME-Version: 1.0
References: <359EC4B99E040048A7131E0F4E113AFC01B33A25D2@marathon> <CA+k3eCRmhy+o4eG-=rsuwJPsAwRx=XoqbHWHq-bNDFz_9NgT6w@mail.gmail.com> <359EC4B99E040048A7131E0F4E113AFC01B33A3BFC@marathon> <CA+k3eCRp_Wpj9F38b6Eci4z0+XhTOHFHnpkfgk1o=g6UE=k8EQ@mail.gmail.com>
In-Reply-To: <CA+k3eCRp_Wpj9F38b6Eci4z0+XhTOHFHnpkfgk1o=g6UE=k8EQ@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Wed, 03 Jul 2019 07:28:44 -0400
Message-ID: <CA+k3eCQFmBQcu1gQarZ8wZd=kei5r1wmER7cYSW8C5wOEPqtCA@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009260f8058cc52bde"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/0_G0gtuZsHj7fSVWaxjtUCJpSPs>
Subject: Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jul 2019 11:29:15 -0000
Okay, -15 has been published and incorporates those fixes and suggestions: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-15 On Mon, Jun 24, 2019 at 5:04 PM Brian Campbell <bcampbell@pingidentity.com> wrote: > Thanks Roman, I'll work to incorporate those suggestions into the next > revision before the impending I-D submission cutoff date. > > On Mon, Jun 24, 2019 at 2:14 PM Roman Danyliw <rdd@cert.org> wrote: > >> Hi Brian! >> >> >> >> My response is inline ... >> >> >> >> *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] >> *Sent:* Monday, June 24, 2019 1:17 PM >> *To:* Roman Danyliw <rdd@cert.org> >> *Cc:* oauth <oauth@ietf.org> >> *Subject:* Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls >> >> >> >> Thanks for the additional review, Roman. I feel lucky, it's not often one >> gets *two* AD reviews :) Please see below for replies inline with a few >> followup questions. >> >> >> >> [Roman] *chuckle* >> >> >> >> On Sat, Jun 22, 2019 at 12:29 PM Roman Danyliw <rdd@cert.org> wrote: >> >> Hi! >> >> I conducted as second AD review of draft-ietf-oauth-mtls per the AD >> hand-off. I have the following additional feedback: >> >> ** Per ekr's earlier review at >> https://mozphab-ietf.devsvcdev.mozaws.net/D3657, paraphrasing: >> -- Section 2.1.2, How is these metadata parameters being obtained? >> >> >> >> The authorization server can obtain client metadata via the Dynamic >> Client Registration Protocol [RFC7591], which is referenced in the top of >> that section. Also the metadata defined by RFC7591, and registered >> extensions to it, implies a general data model for clients that is used by >> most authorization server implementations even when the Dynamic Client >> Registration Protocol isn't in play. Such implementations typically have >> some sort of user interface available for managing client configuration. >> >> >> >> Dose that answer your question? Do you believe more should be said in the >> document to better explain or clarify that? >> >> >> >> [Roman] It does clear it up. Thanks. I think it’s worth a short >> statement about how the AS would get the fields. >> >> >> >> >> >> -- Section 3.2, Figure 3. In this example, what new information is the >> auth server providing to the relying party here? >> >> >> >> The new info here (and in Section 3.1 too) is the hash of the client >> certificate to which the access token is bound, which is in the "cnf" >> confirmation method at the bottom as the "x5t#S256" member. >> >> >> >> [Roman] Makes sense. To make the example clearer, I’d call out this out >> in the prose introducing the example. >> >> >> >> >> ** Section 2.0. What is the expected behavior if the presented >> certificate doesn't match expected client_id? How is this signaled? >> >> >> >> With a normal OAuth 2.0 error response using the "invalid_client" error >> code per https://tools.ietf.org/html/rfc6749#section-5.2 >> >> >> >> Do you think that needs to be stated more explicitly in this document? >> >> >> >> [Roman] Yes, I’d explicit state it with that citation, especially since >> Section 3 discusses of how errors are returned. >> >> >> >> >> ** Section 2.2. Per the sentence "As pre-requisite, the client registers >> its X.509 certificate ... or a trusted source for its X.509 certificates >> ... with the authorization server. >> -- Editorial: s/As pre-requisite/As a prerequisite/ >> >> >> >> done >> >> >> >> -- What's a "trusted source" in this case? Is that just a jwks_uri? If >> so, maybe s/a trusted source/a reference to a trust source/. If not, can >> you please elaborate. >> >> >> >> Yes, it's just a jwks_uri. I'll change that. >> >> >> >> >> A few editorial nits: >> ** Section 2.2.2. Typo. s/sec 4.7/Section 4.7/ >> >> >> >> fixed >> >> >> >> >> ** Section 3.1 Cite DER encoding as: >> [X690] ITU-T, "Information Technology -- ASN.1 encoding rules: >> Specification of Basic Encoding Rules (BER), Canonical >> Encoding Rules (CER) and Distinguished Encoding Rules >> (DER)", ITU-T Recommendation X.690, 2015. >> >> >> >> will do >> >> >> >> ** Section 5. Typo. s/metatdata/metadata/ >> >> >> >> yup >> >> >> >> >> ** Section 6. Typo. s/The the/The/ >> >> >> >> got it >> >> >> >> >> ** Section 7.2. Typo. s/the the/the/ >> >> >> >> done >> >> >> >> >> ** Appendix. Cite the figures numbers (#5 - 7) in the text describing the >> contents of the section. >> >> >> >> will do >> >> >> >> >> The shepherd write-up is in good shape. Thank you. >> >> Regards, >> Roman >> >> >> >> [Roman] Thanks for all of the above. >> >> >> >> Roman >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> *CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly prohibited. >> If you have received this communication in error, please notify the sender >> immediately by e-mail and delete the message and any file attachments from >> your computer. Thank you.* >> > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
- [OAUTH-WG] Second AD Review: draft-ietf-oauth-mtls Roman Danyliw
- Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth… Brian Campbell
- Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth… Roman Danyliw
- Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth… Brian Campbell
- Re: [OAUTH-WG] Second AD Review: draft-ietf-oauth… Brian Campbell