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. _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
