>From the ietf-general list:
>From: Bernard Aboba <[email protected]> >To: <[email protected]>, <[email protected]> >Subject: Review of draft-saintandre-tls-server-id-check >Date: Tue, 24 Aug 2010 17:38:30 -0700 > >I reviewed draft-saintandre-tls-server-id-check. > >In a number of instances, this document is vague on the verification of an >SRV-ID, and in one instance, it appears to contradict RFC 4985, even though it >does not update that document. > >Section 2.1 states: > > o An SRV-ID can be either direct (provided by a user) or more > typically indirect (resolved by a client) and is restricted (can > be used for only a single application). > >This is consistent with RFC 4985 Section 2.1 which states: > > The SRVName, if present, MUST contain a service name and a domain > name in the following form: > > _Service.Name > >Yet, Section 5.1 states: > >When the connecting application is an interactive client, the source >domain name and service type MUST be provided by a human user (e.g. >when specifying the server portion of the user's account name on the >server or when explicitly configuring the client to connect to a >particular host or URI as in >[<http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-09#ref-SIP-LOC>SIP-LOC]) > and MUST NOT be derived from >the user inputs in an automated fashion (e.g., a host name or domain >name discovered through DNS resolution of the source domain). This >rule is important because only a match between the user inputs (in >the form of a reference identifier) and a presented identifier >enables the client to be sure that the certificate can legitimately >be used to secure the connection. > >However, an interactive client MAY provide a configuration setting >that enables a human user to explicitly specify a particular host >name or domain name (called a "target domain") to be checked for >connection purposes. > >[BA] As I understand RFC 4985, the SRV-ID provided in the target certificate >is to be >matched against components (service name and domain name) of the SRV RR >obtained >via lookup within the source domain. As a result, I don't believe that RFC >4985 is >consistent with this advice (e.g. the reference identifier is not matched >against the >SRV-ID). > >Section 4.1 is not as clear as it could be on this point, given that it talks >about both >matching of the source domain and the target domain: > > 4. When checking a reference identifier against a presented > identifier, the client (a) MUST match the source domain (or, in > some cases, target domain) of the identifiers and (b) MAY also > match the service type of the identifiers. > > Implementation Note: Naturally, in addition to checking > identifiers, a client might complete further checks to ensure that > the server is authorized to provide the requested service. > However, such checking is not a matter of verifying the > application service identity presented in a certificate, and > therefore methods for doing so (e.g., consulting local policy > information) are out of scope for this document. _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
