Re: Certificate proposal & X509 clarifications

The Distinguished Name of X509 is NOT intended to be the
unique identifier of a person or a public key.  In the X509 world
two different DNs can have the same public key, and a single
DN can have multiple certificates with possibly different
public keys.  The same public key naturally appears in multiple
certificates when each certificate is only valid for a certain
period of time (e.g., weekly certificates have been proposed for
applications that do not want to implement revocation lists).
        The unique identifier in an X509 certificate is the
DN of the issuer and the serial number that the issuer attached
to the certificate.  Both of these fields appear in the version 1 X509
certificate.  Of course, this assumes that issuers are
following the rule of not issuing two certificates with the same
serial number.
        The designers of version 1 of the X509 certificate format
have realized that they need to allow issuers to attach all kinds
of different attributes to a public key.  This lead to version 3
of the X509 format, which provides for general extensions.  Of course,
this means that there is more rope to hang yourself with when it
comes to designing an overall system, but with careful design,
lots of good things can be done.
        For example, for the S/MIME secure mail effort, the certificates
include the email address of the owner, as certified by the company
that is providing the email post office (e.g., the employer or
service provider).  Note that Netscape Navigator 2.x will support
Version 3 X509 certificates and S/MIME.

        Question: what's a good way to have the existing PGP public
key infrastructure interoperate with the X509 infrastructure?

                --Bob

-----BEGIN PGP SIGNED MESSAGE-----

>Date: Mon, 02 Oct 95 12:51:11 PST
>From: "baldwin" <baldwin@RSA.COM (Robert W. Baldwin)>


>	   The designers of version 1 of the X509 certificate format
>have realized that they need to allow issuers to attach all kinds
>of different attributes to a public key.  This lead to version 3
>of the X509 format, which provides for general extensions.

However, in true ASN.1 form, they called for these extensions to be tied to
object identifiers (defining the attribute being defined).  Therefore, you
have to get someone owning an OBJID tree branch to define meanings for you
- -- and you have to publish some worldwide book of mappings, etc.  To me,
this needs nothing more elaborate than text.  In fact, text is a fine
machine-independent coding.

[Thought experiment: imagine Postscript using ASN.1 coding rather than
ASCII.  How many Postscript printers would there be today?]

>	   Question: what's a good way to have the existing PGP public
>key infrastructure interoperate with the X509 infrastructure?

Answer: wait until X.509 dies under its own weight and let them ask how to
interoperate with PGP.

 - Carl

+--------------------------------------------------------------------------+
|Carl M. Ellison      cme@tis.com    http://www.clark.net/pub/cme	   |
|Trusted Information Systems, Inc.   http://www.tis.com/                   |
|3060 Washington Road          PGP 2.6.2:  61E2DE7FCB9D7984E9C8048BA63221A2|
|Glenwood MD  21738         Tel:(301)854-6889      FAX:(301)854-5363       |
+--------------------------------------------------------------------------+

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMHBj0VQXJENzYr45AQHVUAP/Xrb199NEwRoYydDGQK5l424k7neMRpp/
XZtU+7QO760v2YEPmf5EdWZ6S25wKLtaIVUhVr1MLyCRLyfRedXLdYzBqEVlHd2k
dGarIqkB/HOcmjYvZGxnYE+s2gLiTJ1FShgdWWGtC3qCMqlE3h4r5WuiGIotg/IL
WbzKq2oGzYA=
=qBPm
-----END PGP SIGNATURE-----