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 mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
