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.
###
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
