Randy -
One comment on "... disadvantages of ASN.1" I have heard several blanket
statements concerning the "evils" of using ASN.1 and I can't help but
wonder do those who oppose the use of ASN.1 know of a good alternative?
If so when will that alternative be described in detail showing that it
solves problems as adequately as ASN.1?
Pending a stable, well defined alternative, I recommend that debate on the
use of ASN.1 be kept to a minimum and that we assume that it will be used for
transactions that support CA access.
- John
On Wed, 27 Dec 1995, Randy Catoe wrote:
The question which began this thread can be paraphrased as
"Where can we discuss the variety of formats in which
requests for public key certificates are presented to
certificate authorities"?
I suggest that the motivation for such a discussion would be
to understand what formats need to be supported by certificate
authorities now and in the future and by what means it would be
possible to support a variety of request formats and
potentially a variety of certificate formats ( x509 v1, x509 v3,
PGP, PKCS etc.)
The most prevalent use of such requests "now" seems to be the purpose of
requesting certificates for SSL based Web servers at least within
the U.S.
With the advent of "personal certificates" for secure email in the next
release of certain well-known browser products, the use of certificate
requests for other purposes can be expected to increase. The
Canadian implementation of a Public Key Infrastructure for use within
the National Health Service and the impending U.S. pilot of the
use of certificates for the electronic filing of income tax returns
point the way to a future in which the number of uses for certificates
will increase. One of the fundamental enabling factors to the success
of PKI is the adoption of uniform standards for the representation
and communication of public key certificates.
In an earlier response in this thread I pointed out that the
discussions regarding the future of the dialogues between certificate
issuers and certificate issuers are in the charter of the IETF PKIX
working group. The efforts of that group can be expected to produce
a new set of protocols for this dialoque in order to support the
new certificate attributes defined by x509 v3.
The PKIX WG is (wisely, IMHO), not addressing the issues that
are raised by Peter Williams question regarding the status of PEM
requests, so I believe that this discussion could form the basis
of a different workging group.
An alternative to creating a working group to specify best practices
for existing standards would be to discourage use of the existing certificate
handling standards entirely in favor of adopting those which will emerge
from the PKIX WG. Is the extent of the existing Public Key Infrastructure
great enough to make this a problem?
A related and perhaps more important question is "Are the advantages
of X.509 v3 certificate extensions great enough to obsolete the
existing certificate request formats?".
For many reasons I believe the answer is yes.
By virtue of the ability to create a certificate infrastructure based on
information _in_ the certificates X.509 v3 offers not only the ability to
construct a rigid certificate hierarchy as specified by the PEM
specifications, but also the ability to for certificate users to
operate in a "web of trust" model such as PGP's. ( For that matter,
can anyone comment on the rumors that PGP 3.x will adopt the x.509 v3 format?)
Use of x.509 v3 certificates also allows alternate naming for
the subject of certificates and in this way supports the use
of a internet email address in addition to a X.500 Distinquished Name.
A Public Key Infrastructure based on X.509 v3 extensions also allows
certificate users and creators to designate the intended use of a certificate
in ways that support cryptographically stronger implementations (for
example by designating that a key's usage is restricted to digital
signature, as opposed to key management, for which another key is to be
used).
The strongest non-technical reason to believe that X.509 v3
will supplant existing standards is the imminent adoption of
X.509 v3 in both credit card and electronic check electronic
payment designs backed by the financial industry.
The thrust of the current PKIX effort is to formulate ASN.1 definitions
for the messages that handle the communication between certificate issuers
and certificate users and to transport these messages via HTTP or SMTP.
Such a design has the advantage of containing all the certificate
handling syntax in the same representation rather than relying on
an architecurally higher layer (such as MIME) for this service.
It has all the disadvantages of ASN.1 and is an issue which
I believe merits further discussion ( on the PKIX list).
I'd like to suggest that the energy spent on attempts to
make rational the current certificate handling morass is better
spent on designing the X.500 v3 certifiate handling protocols and
in planning for the transition of current certificate handling
implementations to support x509 v3 and the results of the PKIX WG.
Randy
At 11:23 AM 12/26/95 -0800, Ali Bahreman wrote:
Thanks for explaining the process. The only reason I feel that classic-
PEM could co-exist with MOSS is to provide a message security standard
independent of MIME. This is purely a technical opinion.
I have to admit, I have no desire or the strength to invest in pursuing
this myself, but if there are communities who do, I would think it is
fare to let them do so. And if IETF/IESG has formally stated its lack of
desire to home this effort, maybe that community could find another home.
Regards,
Ali