On Wed, 2011-03-30 at 15:49 +0200, Peter Saint-Andre wrote: > You're right. Jeff and I looked at this issue in detail and worked with > our sponsoring AD (Alexey Melnikov) to address it during AUTH48. This > was a bit challenging because we wanted to keep the changeset as small > as possible. Although we considered more significant modifications, we > ended up doing two things in Section 6.2.1 (which defines the rules for > constructing a list of reference identifiers)... > > 1. Changed MUST to SHOULD for DNS-ID: > > ### > > Using the combination of fully qualified DNS domain name(s) and > application service type, the client constructs a list of reference > identifiers in accordance with the following rules: > > o The list SHOULD include a DNS-ID. A reference identifier of type > DNS-ID can be directly constructed from a fully qualified DNS > domain name that is (a) contained in or securely derived from the > inputs (i.e., the source domain), or (b) explicitly associated > with the source domain by means of user configuration (i.e., a > derived domain). > > ### > > 2. Added a paragraph clarifying the need for the change from MUST to SHOULD: > > ### > > Which identifier types a client includes in its list of reference > identifiers is a matter of local policy. For example, in certain > deployment environments, a client that is built to connect only to > a particular kind of service (e.g., only IM services) might be > configured to accept as valid only certificates that include an > SRV-ID for that application service type; in this case, the client > would include only SRV-IDs matching the application service type > in its list of reference identifiers (not, for example, DNS-IDs). > By contrast, a more lenient client (even one built to connect only > to a particular kind of service) might include both SRV-IDs and > DNS-IDs in its list of reference identifiers. > > ###
Unfortunately, this change does not solve the problem. Consider the following three client behaviors with respect to presented identifiers: 1. Accept only an SRV-ID. 2. Accept an SRV-ID or a DNS-ID. 3. Accept a SRV-ID, or accept a DNS-ID if there are no SRV-IDs. Both the old and new versions of the spec allow #1 and #2, but there is no way consistent with the spec to achieve #3 because the first sentence of section 6.2.1 requires that the reference identifier list be independent the presented identifier list. And #3 is what is required for existing applications that use DNS-IDs to transition smoothly to SRV-IDs and achieve the highest level of security supported by both sides. Here is why: - If a new server is to work with old clients, its certificate must include a DNS-ID as well as a SRV-ID. - If a new client is to work with old servers, it must accept a certificate that contains a correct DNS-ID and no SRV-IDs. - When a new client connects to a new server, it should achieve the highest level of security supported by both sides, which in this case means verification of the service type. I.e., if a MITM attacker diverts the connection to a server that has the desired DNS name but does not provide the desired service type, the connection should fail. In this case, the client will see a certificate that contains a correct DNS-ID and one or more SRV-IDs, none of which have the correct service type, and it should reject the certificate. (You can replace "SRV-ID" with "identifier that contains service type information" throughout the above if you like.) -- Matt _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
