On Tue, Dec 26, 2000 at 06:13:58PM +0800, [EMAIL PROTECTED] wrote:
>
> I've learned some materials of certificate extensions,
> and have found that certificates of different CA
> have different certificate extensions, such as:
>
> certs from:
> Microsoft : Enhanced Key Usage, Authority Key Identifier;
> Verisign : Key Usage, Certificate Policies, Basic Constraints;
> Openssl : including netscape-cert-type, etc. (it seems
> that netscape cert extensions aren't declared
> by x509v3, so they're not standard, aren't they?)
>
> But I'm still very confused about how to identify
> SSL certs or SET certs through cert extensions.
> are there uniform definitions about cert extensions of
> SSL, SMIME and SET? or just lie on distinct company or
> applications?
You're on the right track. X.509 defines the certificate extension
mechanism and several extensions. Then communities and/or
implementations define the certificate profile appropriate for
their use. The certificate profile describes in detail the requirements
that certificates must meet for use within the community.
These requirements may include things like DN element ordering,
extensions that may be included and extensions that must be included,
etc.
Extensions may be defined by anyone for any purpose. X.509 has
defined some extensions, as has PKIX (both considered standards-defined
extensions); many other organizations have defined their own
extensions for their own purposes (known as private extensions).
There's nothing evil about private extensions, though if you create
a private extension, don't expect anyone else to know what it means
-- and don't mark it critical if you want to interoperate with any
common applications (e.g., Netscape).
There really isn't such as thing as an 'SSL' certificate in the
sense of a certificate that is good for SSL, but not any other
application. There are just certificates that meet the certificate
profile for a given application or community, and certificates that
do not. One certificate may -- intentionally or unintentionally --
meet the requirements for many applications.
SSL itself doesn't put very many requirements on certificate
construction (see TLS 7.4.2 for some like when keyUsage is present,
digSig bit must be set for certificates used in signing).
To determine what extensions are required for a particular application,
you need to look at the standard for any protocols being used, a
certificate policy (for the certificate profile), if one exists,
the standards and documents for that particular application, and
the documentation for the products using certificates.
For example, if you just want a certificate that works for SSL,
you don't have to do much at all. If you want a certificate that
works for SET, on the other hand, you need to dig into the SET
documentation and determine what requirements for SET certificates,
as well as any products being used in your deployment. (e.g., no
protocol requires you to include a netscape-cert-type extension in
the certificate, nor do recent versions of Netscape products, but
if you do include a netscape-cert-type extension, many products
have implementation-defined behavior related to that extension)
> can openssl issue SET certs? and SMIME?
OpenSSL can issue certificates with arbitrary extensions. For some
extensions you many find this simple and convenient, for others
you may find yourself writing code to do so in an equally convenient
manner (more or less true of other CA products as well, actually).
-scott
--
Scott Renfro <[EMAIL PROTECTED]> +1 650 906 9618
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
