Hi Roman, thanks for your feedback. Comments inline.
On 7/31/23 1:03 PM, Roman Danyliw via Datatracker wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-uta-rfc6125bis-14: No Objection
----------------------------------------------------------------------
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?
I can imagine several practical constraints that might limit the ability
of the service provider to request a more tightly-scoped ID type, e.g.,
the SRV-ID type might not be supported by the service provider's
preferred CA or by tooling used to generate certificate requests.
It's also possible that, even if service provider's tooling and its
preferred CA support a more tightly scoped ID-type, the service provider
wishes to include both the more tightly-scoped ID type *and* a less
tightly-scoped ID type (e.g., DNS-ID) in order to maximize interoperability.
I think we can address this by adding text along those lines; here is a
proposal:
If the certificate will be used for only a single type of application
service, then the service provider SHOULD request a certificate whose
deployment scope is limited only to that application service type
(i.e., by means of an SRV-ID or URI-ID); this applies if the relevant
protocol has defined such an ID type and if the service provider and
CA both support the more tightly-scoped ID type. However, in the
interest of wider interoperability, even when requesting a
certificate that includes an SRV-ID or URI-ID, the service provider
MAY also request that the certificate will include either a DNS-ID
or IP-ID.
Do you think that is more accurate?
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?
The alternative is mentioned in the very next clause: "a single
certificate containing multiple SRV-IDs or URI-IDs each identifying a
different application service type."
Suggestions are welcome on how to make that clearer.
** 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?
This is the same situation as the first paragraph you mentioned. We
should probably refer back to the modified text above so that we don't
define the behavior in two places.
** 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)?
I don't think we need to define standardized behavior here because this
belongs to the realm of implementation; thus we could route around this
confusion by changing the text to:
The
search succeeds if any presented identifier matches one of the
reference identifiers, at which point there is no need for the client
to continue the search.
** From idnits:
== Outdated reference: draft-ietf-tls-subcerts has been published as RFC
9345
Good to know.
Thanks again,
Peter
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
