I'd always heard X.509 public key certificates were a hierarchical, evil, anti-WebOfTrust ISOism. But Netscape is now doing them, and talking S/MIME, so I sat down to read the specs, and they're really not all that bad. (Technically, I've only read PKCS#6 and RFC 1422, and not the real ISOisms...) Yeah, they've got lots of clunky ASN.1 Ambiguous Encoding Rules and X.500 Silly Name Format, but those can be lived with, and the X.500 may be possible to simply ignore in most cases. Steve Kent, author of RFC1422, envisions that a hierarchical world with government certification authorities would be the most convenient implementation, and with the X.500 directory service serving certificates, but that's primarily editorial and not required by the technology. Since a zillion and a half people are about to acquire Netscape 2.0, which supports non-Verisign-signed X.509 certificates and DES, we can definitely extend the Web of Trust concept to that world; can we also extend secure user-to-user messaging? It's time for PGP to mutate and take over the world... An X.509 certificate has the following components 1. version 2. serial number 3. signature (algorithm ID and parameters) 4. issuer name 5. validity period 6. subject name 7. subject public key (and associated algorithm ID) expressed as ASN.1 and signed with the issuer's public key. The issuer and subject names are expressed as X.500 addresses (big deal). The CA's public key is expected to be obtained out of band, or as a chain of signatures from some other CA that you got a signature for out of band; there's no policy implementation that says who can be one. The primary requirements on CAs are to never issue the same serial number twice, maintain uniqueness on signatures for subjects, and maintain a Certificate Revocation List which is accessible somehow. Unfortunately, the data format doesn't support multiple signatures, but the documentation _does_ explicitly indicate that you can _have_ multiple certifications; you just have to drag around a bunch of separate certificates, leading to some obvious implementation opportunities. CRLs are less well-specified, though the PEM RFCs suggest a PEM format; the main requirement is that they be keyed off the serial number, which is why that has to be unique. RFC 1422 proposes a rooted hierarchy of CAs - a root called the Internet Policy Registration Authority, which would certify a bunch of Policy Certification Authorities, which would each have different requirements on what their CAs require from people who want to be certified, ranging from anonymous personas to heavily identified Official People, and would do a certain amount of coordination to preserve uniqueness. Becoming a PCA would require paying money to the IPRA. However, there's no requirement that a _specific_ organization become the _one_ _official_ IPRA; if somebody were to volunteer and announce themselves as the IPRA, there's no particular conflict-resolution mechanism. [ maybe it's time for a Cypherpunks Press Release? No - I didn't say it. Not me! ] But rootedness only really matters to software that cares... and as long as your software accommodates N levels of certification, you can have a Web of Trust getting back to a key you signed yourself, and either get an official personna certificate or plug your public key into your software as the IPRA (and sign the real IPRA's certificate yourself :-) Problems: 1) ITAR - shouldn't be a big deal, because all of this is building a signature/authentication mechanism, it's not doing any encryption. The encryption, if any, is a user agent issue, and that's Netscape's problem; the Web of Trust tool is an add-on. 2) RSA patent - can this be built with RSAREF? Or RSAREF with permission for a couple extra activities? Or built out of RIPEM or RIPEM-SIG? The latter has the benefit of already being exportable. 3) Netscape compliance - the Netscape folks have been real friendly, and I hope they'll leave their format for getting certificates open. 4) Other software and CA policy-makers - getting out first is worth something; then you're the standard that they have to follow instead of the other way around. For some issues, like X.500 name vs. DNS name, there are probably people in the IETF or community in general working on it, or alternatively you can do an ugly hack abusing the organization and address fields. 5) S/MIME - real S/MIME compliance requires support for RC2 as well as publicly available algorithms, though this is really just an X.509 handler. 6) It's a lot of work - well, yeah, it is. And I'm lazy. Is there enough related code in SSLeay to steal to help implement it? #--- # Bill Stewart, Freelance Information Architect, stewarts@ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---