[certid] Fwd: Review of draft-saintandre-tls-server-id-check

[Paul Hoffman <[e-mail]>]

>From the ietf-general list:

>From: Bernard Aboba <[e-mail]>
>To: <[e-mail]>rg>, <[e-mail]>
>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.