[Uta] Roman Danyliw's No Objection on draft-ietf-uta-rfc6125bis-14: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Mon, 31 July 2023 19:03 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-uta-rfc6125bis@ietf.org, uta-chairs@ietf.org, uta@ietf.org, orie@transmute.industries, orie@transmute.industries
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <169083022271.26583.17573686765363108458@ietfa.amsl.com>
Date: Mon, 31 Jul 2023 12:03:42 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/uta/c9d3TB3MlphMn0JIKMRK66ObUdE>
Subject: [Uta] Roman Danyliw's No Objection on draft-ietf-uta-rfc6125bis-14: (with COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-uta-rfc6125bis-14: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



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

Thank you to Derrell Piper for the SECDIR review.

Thank you for this critical maintenance to RFC6125.

** Section 5.

   If the certificate will be used for only a single type of application
   service, the service provider SHOULD request a certificate that
   includes DNS-ID or IP-ID values that identify that service or, if
   appropriate for the application service type, SRV-ID or URI-ID values
   that limit the deployment scope of the certificate to only the
   defined application service type.

Given the scope of the document being restricted to DNS-, IP-, SRV-, and
URI-ID, what is the circumstances under which this “SHOULD” guidance would NOT
be followed?

   If a service provider offers multiple application service types and
   wishes to limit the applicability of certificates using SRV-IDs or
   URI-IDs, they SHOULD request multiple certificates, rather than a
   single certificate containing multiple SRV-IDs or URI-IDs each
   identifying a different application service type.

The SHOULD in this text implies there is an alternative to requesting multiple
certificates?  What is that?

** Section 6.1.1
   *  If a server for the application service type is typically
      associated with a URI for security purposes (i.e., a formal
      protocol document specifies the use of URIs in server
      certificates), then the reference identifier SHOULD be a URI-ID.

I appreciate that this is unchanged language from RFC6125.  If the application
service is using a URI, under what circumstances would the reference identifier
NOT be a URI-ID?

** Section 6.2
   The
   search succeeds if any presented identifier matches one of the
   reference identifiers, at which point the client SHOULD stop the
   search.

What is the standardized behavior if the client keeps looking after the first
match (i.e., it is a SHOULD, not a MUST to stop)?

** From idnits:

  == Outdated reference: draft-ietf-tls-subcerts has been published as RFC
     9345

[Uta] Roman Danyliw's No Objection on draft-ietf-… Roman Danyliw via Datatracker
Re: [Uta] Roman Danyliw's No Objection on draft-i… Peter Saint-Andre