Actually, _some_ of the PKIX-heavy APPS might want to restrict usability of server certificates by "extendedKeyUsage" in addition to what we define as server endpoint identification here.
The wording in rfc-5280 section 4.2.1.12 appears a self-contradictory to me, because it conditionalizes "MUST only" with "applications MAY do whatever they see fit", and application negligence is likely to be the norm. And btw. how "applications MAY" is used it refers to individual implementations and such an interpretation aligns well with the more easily understandable text in rfc-2459. If the extension is present, then the certificate MUST only be used for one of the purposes indicated. If multiple purposes are indicated the application need not recognize all purposes indicated, as long as the intended purpose is present. Certificate using applications MAY require that the extended key usage extension be present and that a particular purpose be indicated in order for the certificate to be acceptable to that application. -Martin 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). > > 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. _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
