Re: [certid] What DNS-ID if also using a DNS-SRV?

[Shumon Huque <[e-mail]>]

On 6/30/10 2:00 PM, Paul Hoffman wrote:
[...]
> I agree that we have to look at the details of the service. To me, 
> there are two types of names:
> - direct (CN-ID, DNS-ID, and URI-ID)
> - indirect (SRV-ID)

On Wed, Jun 30, 2010 at 04:01:05PM -0600, Peter Saint-Andre wrote:
[...]
>    Therefore:
> 
>    o  A CN-ID identifier is direct (provided by a user) and unrestricted
>       (can be used for any application).
>    o  A DNS-ID identifier is direct (provided by a user) and
>       unrestricted (can be used for any application).
>    o  An SRV-ID identifier is indirect (resolved by a client) and
>       restricted (can be used for only a single application).
>    o  A URI-ID identifier is direct (provided by a user) and restricted
>       (can be used for only a single application).

I'm not sure I buy this classification. I was trying to figure out
what Paul meant by "direct" and "indirect" - it looks like direct
means "provided by client" and indirect means "DNS resolution
was involved". In that sense I don't see any distinct category for
SRV-ID. The information in the SRV-ID *is* provided by the client.
If the client is attempting to connect to the IMAP service at
example.com, it already has all the information to construct the
SRV identity (_imap.example.com) - no DNS resolution was involved.

DNS resolution is involved in all 4 of these identity types in order
to get the network layer address of the server for connection 
establishment purposes. This should be differentiated from the identity
of the server used for TLS/PKIX authentication. CN-ID, DNS-ID, URI-ID
will involve A, AAAA DNS resolutions. And don't forget that they might
also involve aliases (CNAMEs).

The more meaningful classification to me involves the difference 
between generic domain name identities (CN-ID, DNS-ID) and application 
specific identities (SRV-ID, URI-ID).

(Actually URI-ID can be even more granular, by also specifying a
particular resource/path within an application, but I don't think
we want to deal with that in this draft -- to manage the scope of
this draft, maybe we need to constrain the format of URIs that we
are addressing).

--Shumon.