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

[Peter Saint-Andre <[e-mail]>]

On 6/30/10 2:00 PM, Paul Hoffman wrote:
> At 1:53 PM -0600 6/30/10, Peter Saint-Andre wrote:
>> Upon further reflection, I think there are two dimensions here:
>> 
>> 1. From the client's perspective, some names are direct (provided
>> by the user = DNS-ID, CN-ID, URI-ID) and some names are indirect
>> (resolved by the client based on the input provided by the user =
>> SRV-ID). This dimension matters for verification.
>> 
>> 2. From the service provider's persective, some names are
>> unrestricted (can be used in any application = DNS-ID and CN-ID)
>> and some names are unrestricted (can be used in only one kind of
>> application = SRV-ID and URI-ID). This dimension matters for
>> issuance.
> 
> That should be "...and some names are restricted (can be used in
> only...". 

Typing too fast here. :)

> But, yes, this is a good distinction.
> 
>> I'll work to formulate this distinction more carefully in text that
>> can be included in the spec.
> 
> That would help implementers (and hopefully CAs) a lot.

Here is a first draft...

###

2.1.  Naming Applications

   This specification assumes that an Internet application is named
   based on a DNS domain name (e.g., "example.com") -- supplemented in
   some circumstances by an application type (e.g., "the IMAP server at
   example.com").

   From the perspective of the application client or user, some names
   are direct because they are provided directly by the user (e.g., via
   runtime input or prior configuration) whereas other names are
   indirect because they are resolved by the client based on input
   provided by the user (e.g., a target name resolved from a source name
   using DNS SRV records).  This dimension matters for certificate
   verification.

   From the perspective of the application server or service provider,
   some names are unrestricted because they can be used in any kind of
   application (e.g., a certificate might be re-used for both the HTTP
   service and the IMAP service at example.com) whereas other names are
   restricted because they can be used in only one kind of application
   (e.g., a special-purpose certificate that can be used only for an
   IMAP service).  This dimension matters for certificate issuance.

   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).

   We summarize this taxonomy in the following table.

   +-----------+-----------+---------------+
   |           |  Direct   |  Restricted   |
   +-----------+-----------+---------------+
   |  CN-ID    |  Yes      |  No           |
   +-----------+-----------+---------------+
   |  DNS-ID   |  Yes      |  No           |
   +-----------+-----------+---------------+
   |  SRV-ID   |  No       |  Yes          |
   +-----------+-----------+---------------+
   |  URI-ID   |  Yes      |  Yes          |
   +-----------+-----------+---------------+

   When implementing software, deploying services, and issuing
   certificates for secure PKIX-based authentication, it is important to
   keep these distinctions in mind.  In particular, best practices
   differ somewhat for application server implementations, application
   client implementations, service providers, and certification
   authorities.  Protocol specifications that reference this document
   MUST specify which identifiers are mandatory-to-implement by servers
   and clients, which identifiers are to be preferred by service
   providers, and which identifiers ought to be supported by certificate
   issuers.  Because these requirements differ across applications, it
   is impossible to categorically stipulate universal rules (e.g., that
   all software implementations, service providers, and certification
   authorities for all application protocols need to use or support DNS-
   IDs as a baseline for the purpose of interoperability); however, it
   is preferable that each application protocol will at least define a
   baseline that applies to the community of software developers,
   service providers, and CAs actively using or supporting that
   technology.


###