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-----
participants (2)
-
baldwin -
Carl Ellison