[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: one possible motivation for X.509
At 02:22 PM 7/18/96 +0000, Buffam, William J TR wrote:
>Okay, Carl, I'll take the bait. I'm never afraid of asking the really dumb
>questions....
Excellent questions.
>The way I heard it was that PEM, which was the first real deployed attempt to
>use a PKI, ran into a lot of problems because of the paucity of information in
>the X.509 certificate. Hence all the stuff added in v1 and v3.
I was a very early (non-)user of TIS/PEM. It failed to catch on at my
company (Stratus) because it required the generation of a certificate which
required generation of a DN -- and there was no corporate organization
willing to take on the job of creating an X.500 name space.
Much though I wanted to deploy PEM, I couldn't, because I couldn't get a DN
for anyone.
So, I used RIPEM until I got the MIT version of PGP and then switched to that.
The problem, then, wasn't one of too little information -- but of too much.
Later I joined TIS and had occasion to work on the code of PEM. The ASN.1
for certificates slowed it down and enlarged it tremendously. If you have
access to the source (I think it's still available) take a look -- comparing
it to PGP's source code.
>Now (okay, this is a bit of a punt - I haven't gone in and done a bit-by-bit
>comparison) SPKI appears to have said "let's get rid of this X.509 complexity
>and get back to something simpler" , essentially ending up with something
>similar to an X.509 v1 cert (okay, with simpler naming).
SPKI certificates differ from X.509 in several ways:
1. no ASN.1
2. no extra fields to check
3. (the biggest, perhaps) SPKI is an authorization cert, not an
identity cert
>So why will SPKI not run into the same problems that caused v1 certs to get
>expanded to v3?
I wasn't part of the effort to make v3 from v1. However, X.509 Identity
certs lack meaning to an implementor. What's needed is authorization for a
public key to perform some action or get some access. If all you have is an
IDCert, then you need an ACL (or attribute cert). Those latter aren't
defined as part of X.509. SPKI collapses that pair of certs into one,
leaves out the DN and goes straight for the authorization. That's a
simplification and it addresses the real need of the implementor. We need
to do I&A&A -- not just I&A. If it's the authorization you really care
about, then there's an implicit Identification in a person's public key and
normal authentication -- to get you I&A&A without DNs.
Meanwhile, we allow the implementor to form his/her own <auth> fields to fit
his/her application, so we don't get committee meetings to vote on extensions.
>And why will naming problems go away, and the whole business become magically
>simple, by doing away with DNs?
DNs perform no useful purpose for me, the verifier. For a (name,key)
binding to mean anything to me, the name must be in my name space. A DN is
in the CA's name space. That means that to use a CA's (name,key) binding, I
need a mapping from the DN to my name (nickname) for the entity in question.
I have to get that mapping over a secure channel. If I have to go to that
trouble, then I can get the public key hash rather than the DN over that
channel and I won't have needed the DN.
>And why are S-expressions so much easier than ASN.1? (I personally am not an
>actual code implementor, but at least one commentator on these channels has
>claimed there's no lower work factor with S-exprs).
I'm not advocating S-expressions. The binary format I've proposed for SPKI
certificates (with free C code to translate to/from ASCII) is parsed/packed
very easily by a normal C program doing normal stream I/O. The free C code
will make that very plain, once I post it.
Thanks again for the questions.
- Carl
+--------------------------------------------------------------------------+
|Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme |
|CyberCash, Inc. http://www.cybercash.com/ |
|207 Grindall Street PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 |
+--------------------------------------------------------------------------+