On Tue, 2011-01-18 at 11:54 -0800, =JeffH wrote: > > Are you saying that a client that "supports checking of identifiers of > > type SRV-ID and URI-ID" MUST NOT compare two DNS-IDs, because they do > > not contain the service type information that the client is required to > > check? If so, then in the following example: > > > > Reference identifiers: > > 1. SRV-ID _imaps.example.net > > 2. DNS-ID example.net > > > > Presented identifiers: > > 4. DNS-ID example.net > > > > we would get "no match", when it seems a match would be helpful for > > backward compatibility. > > > I think we may have intended to allow for the latter with the "SHOULD" clause > of the 2nd bullet of S6.2.1.. > > o If a server for the service type is typically discovered by means > of DNS SRV records, then the list SHOULD include an SRV-ID. > > ..i.e. if the client wishes to be more lenient in what presented idents it > checks against, it could leave the reference SRV-ID off it's list of > reference > idents to use to check against the presented idents. > > And so the resultant behavior is ambiguous given the way S6.5's "MUST" clause > is crafted where it says "If a client supports checking of identifiers of > type > SRV-ID..." > > It should probably say something like.. > > If a client supports checking of identifiers of type SRV-ID or > URI-ID, and identifiers of those type(s) are included in the > reference identifier list, then it MUST also check the service type...
This is an improvement. You could just say "if at least one identifier of type SRV-ID or URI-ID is included in the reference identifier list", because presumably clients that do not support them will not add them to the list. However, you are still forcing the client to decide in advance whether to require a service type. Alternatively, the requirement could apply if at least one reference identifier /and/ at least one presented identifier contain a service type. This would realize the general principle of providing the highest level of security supported by both sides. This will be a more realistic client behavior for applications currently transitioning to the use of SRV-IDs, though it means those clients do not get any additional security connecting to a service until all other certificates for that DNS name contain SRV-IDs. (Note that clients for the other services need not actually use the SRV-IDs.) Applications that used SRV-IDs from the beginning can continue to require a presented SRV-ID. Proposed replacement for the text in Section 6.5 preceding Section 6.5.1: ----- Identifiers of type SRV-ID and URI-ID contain service type information. Clients are usually designed to communicate with one type of service, such as websites, email services, VoIP services, or IM services, and can use this information to check that they are communicating with the intended service. If at least one reference identifier and at least one presented identifier contain service type information, then the client MUST check the service type of the application service with which it communicates (in addition to checking the domain name as described above). That is, a reference identifier and a presented identifier cannot match unless they both contain service type information and the service types match, as described below. If at least one reference identifier contains a service type, but no presented identifier does, the client MAY accept a match of DNS name only for backward compatibility. ----- I regret sending this at the eleventh hour. I identified this concern as soon as I read your message, but I got busy and let the issue slip. Assuming others agree with this proposed change, if it is too late to go in RFC 6125, at least it can be queued for the next update. -- Matt _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
