[OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-jwsreq-12: (with DISCUSS and COMMENT)

"Alexey Melnikov" <aamelnikov@fastmail.fm> Thu, 16 February 2017 11:42 UTC

Return-Path: <aamelnikov@fastmail.fm>
X-Original-To: oauth@ietf.org
Delivered-To: oauth@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6D4129AB8; Thu, 16 Feb 2017 03:42:53 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Alexey Melnikov" <aamelnikov@fastmail.fm>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.43.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148724537375.15981.8662422383544692244.idtracker@ietfa.amsl.com>
Date: Thu, 16 Feb 2017 03:42:53 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/FgE_qVbGEkLwcKvVuYz23CSiHAo>
Cc: oauth@ietf.org, oauth-chairs@ietf.org, draft-ietf-oauth-jwsreq@ietf.org
Subject: [OAUTH-WG] Alexey Melnikov's Discuss on draft-ietf-oauth-jwsreq-12: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 16 Feb 2017 11:42:54 -0000

Alexey Melnikov has entered the following ballot position for
draft-ietf-oauth-jwsreq-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

When referencing RFC 6125 you need to provide more details. In
particular, you need to pretty much answer every question in section 3 of
RFC 6125: <https://tools.ietf.org/html/rfc6125#section-3>

One example of how this might look like is in Section 9.2 of
<https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-rfc6810-bis/?include_text=1>;.
For your convenience the relevant text is pasted below:

   Routers MUST also verify the cache's TLS server certificate, using
   subjectAltName dNSName identities as described in [RFC6125], to
avoid
   man-in-the-middle attacks.  The rules and guidelines defined in
   [RFC6125] apply here, with the following considerations:

      Support for DNS-ID identifier type (that is, the dNSName identity
      in the subjectAltName extension) is REQUIRED in rpki-rtr server
      and client implementations which use TLS.  Certification
      authorities which issue rpki-rtr server certificates MUST support
      the DNS-ID identifier type, and the DNS-ID identifier type MUST
be
      present in rpki-rtr server certificates.

      DNS names in rpki-rtr server certificates SHOULD NOT contain the
      wildcard character "*".

      rpki-rtr implementations which use TLS MUST NOT use CN-ID
      identifiers; a CN field may be present in the server
certificate's
      subject name, but MUST NOT be used for authentication within the
      rules described in [RFC6125].

The only thing missing from the above is explicit mentioning that SRV-ID
and URI-ID are not used. (I think the same should apply to your
document.)


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In 5.2: a document defining HTTPS URI needs to be a normative
reference.

In 5.2.3: can you show an example of response (with relevant HTTP Header
Fields)? Or update example in 5.2 to include HTTP Header Fields.