[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ANNOUNCEMENT: SPKI mailing list and BOF at Los Angeles


This is much longer than I had intended. I apologize for the length
and repetition.

Jueneman@gte.com writes:
> Perry, I admit to some ambivalence in joining this discussion. On
> the one hand, I am greatly concerned that an attempt to open a
> "second front" in a public key infrastructure will be divisive,
> contentious, and confusing to potential vendors and end-users
> alike. On the other hand, if there are legitimate issues that people
> feel cannot be adequately addressed by the existing X.509
> certificates, I'd like to understand them and fix them.

I want to say, from the outset, that I really do not believe that
X.509 can be "fixed". It has lots of good ideas, but it has ISOisms
that are embedded deep inside it.

> I'm never quite sure who the "we" is, or exactly who the "internet
> community" is. but I'm not sure that I would agree with you. You
> seem to feel that X.509 was somehow foisted upon the Internet by
> some external forces, but that simply wasn't so.

I really don't want to spend large amounts of space arguing this
point. There are a lot of people, myself included, who are not happy
with X.509 and felt that it was being adopted not because of its
technical merits but because it was all that happened to be around. We
are trying to make an honest effort here to design a system based on
the Internet's requirements and not on ISO requirements. That means
that things like distinguished names and ASN.1 are likely not going to
be design starting points. This does not mean that the experience that
you and others have gained over the years in working with X.509 should
be abandoned, although there are those like Carl Ellison who argue
that the model is wrong, and their ideas are also going to be
considered. However, I really don't think much is going to be
accomplished by trying to make this into the "patch up X.509" working
group. There obviously is a constituency for such a group, but it
already exists; this group exists to meet the needs of a different
constituency.

[...]
> I'm just saying all this in the spirit of "been there, done that."
[...]
> Gee, isn't that funny -- those seem to be precisely the issues that we are 
> still facing, even in this new forum!

Your experience is valuable and valued by me. I meant it when I said
that the input of people with experience both in the X.509 design
efforts and in the use of X.509 certificate systems was actively
solicited. I must repeat, however, that this isn't the "fix up X.509
slightly" group. Starting from a blank sheet, X.500 distinguished
names would not naturally arise in an IETF context. Neither would ASN.1

> You may or may not like the geopolitical naming scheme that is often
> cited as an example of a distinguished name in X.500, but I would
> contend that if you want to communicate securely with someone and
> you don't have the luxury of having that person physically hand you
> a disk with his public keys on it, then you had better be pretty
> sure that he is who you think he is, and not one of the other 23,000
> William Smiths in the US.

I perhaps don't have the same model of how such communication would
occur. For example, in a commerce situation, I don't think a bank
should be depending on a signature from a third party on a
certificate. Liability is reduced and flexibility improved if the bank
agrees with the customer on what public key can access the account at
the point that the account is opened -- similarly for Mastercard,
Visa, etc, and for things like your company's charge account with
Staples.

I'm also not sure that distinguished names help the uniqueness problem
you are trying to address, and they introduce all sorts of other
problems.

In any case, the whole point of the SPKI group is to address the
concerns of the constituency that would like an honest attempt to
start the design process from scratch.

> So if you want really good privacy, and trustworthy digital signatures, you 
> have to solve the problem of uniquely naming/identifying an individual in a 
> manner that is repeatable.

I'm not sure of that. Almost all the applications I am dealing with
regularly, especially in the financial community, deal with situations
in which you want to identify that someone has access to a particular
capability -- like sending buy orders on a brokerage account -- and
not that a person is a specific human being. The two might seem
functionally equivalent to you, but I do not think they are,
especially since very often one person needs to take on many roles,
some roles are taken on by multiple people, and some roles are taken
on by non-humans entirely. Do I really want to come up with a
distinguished name for a particular instantiation of a running
ftp daemon? Something much simpler is called for.

In the case of electronic mail systems, what I'm really interested in
is the assurance from the entity controlling the mail system at
gte.com that the key I have looked up for "jueneman@gte.com" is
claimed to be the key that will be used by the entity reading email at
that address. I very much do *not* want to spend time and effort
mapping that into a distinguished name, nor is a distinguished name a
natural lookup mechanism in an internet where domain names and the DNS
are the directory of choice, not the X.500 directory.

In any case, I believe I've said enough. The purpose of this group
really is NOT to debate the merits of ASN.1 or distinguished
names.

*If* the group were to come to consensus that an encoding scheme
equipped with a definition language and compilers were needed, *then*
we would consider encoding schemes like that -- but at that point I
don't see why the IDL from the OSF wouldn't have as good or better
claim on our hearts and minds. Starting from scratch means everyone
has to justify their design choices, and I don't think that the
ASN.1/DER choice is so obvious as to require our selecting it.

*If* the group were to come to consensus that a mechanism for uniquely
naming humans across the planet were needed, *then* we would consider
schemes to do that -- but again, at that point I don't see why X.500
distinguished names would necessarily be the obvious choice. We would
have to consider the design decisions afresh, and other schemes might
very well have a better claim.

> A lot of people don't like ASN.1. It isn't terribly easy to read,
> there aren't a lot of high quality compilers lying around that are
> free (like a lot of other things in life), and some of the purists
> would argue that like a lot of standards, the people that designed
> it didn't know when to quit. OK, let's stipulate that. So what's
> your next choice -- COBOL?

Recently, in attempting to represent a strawman certificate format, a
colleague of mine and I actually went through the exercise of playing
with binary wire formats.

The format we ended up with seemed very simple. There were only about
four different types we needed to represent. "We need dates." "Fine,
lets go Unixy, and pick seconds since an epoch, and use network byte
order." "Fine." "We need to represent strings". "Fine. We can use C
strings or length/byte array strings." "Lets use the latter, it will
allow us to embed nulls." "Fine". And so forth.

The exercise took about three minutes.

The whole argument for ASN.1/DER seems to be based on the perception
that there is a problem here that I personally do not perceive. I
believe a version byte at the head of a binary certificate would do
far more to improve forward changes than picking an extremely large,
over-extensible system for representing what is essentially very simple
information.

It is for this reason that I do not see the need for a definition
language or non-ad hoc encoding method here.

If, however, we needed one, I do not see why ASN.1 would have the
automatic claim on being "the right way" to do this.

> Certainly a lot of the "Internet -way" standards seem to have been
> written by people who afraid to ever represent anything in binary --
> they'd rather parse a bastardized, more or less human readable
> string.

I don't see it as fear or bastardization. I see it as an enviable
pragmatism. This pragmatism meant that once a few years ago when I
needed to write some very specialized mail transport code I managed it
in 77 lines of Perl code, including alias expansion. I will never be
able to do such a thing for an X.400 mail system.

> The point is that even if you admit to the faults that people
> criticize ASN.1 for, it's still better than any other even
> reasonably popular metalanguage.

Again, I am not sure we *need* a metalanguage. We've come this far
without one and we haven't suffered for it. Also, the assertion that
ASN.1 is the best metalanguage would have to be rigorously defended --
I think there are better ones out there.

> So if this group is just going to go on an anti-ASN.1 kick, count me
> out.

I am sorry that you feel that way. We aren't on an "anti-ASN.1 kick".
We are on a "use what we need" kick. The use of ASN.1 has to be
justified on better than abstract philosophical grounds. It has to be
shown to be of direct and important benefit to this effort. I can't
see the point myself, frankly, and the impression I get from the
people who I discussed this all with before forming this group was
that ASN.1 was more part of the problem set than the solution set --
something they did not feel was needed to solve our problems.

> We are too close to having a real consensus emerge on an X.509-base
> public key infrastructure to spend all of the time and effort
> debating that point again.

There is such a consensus in the PKIX working group. There isn't a
consensus in the broader internet community. Thus, the SPKI group.

> We went through it all back in the PEM days

And we all know what a glaring success PEM has been. Do you want
another PEM? Frankly, I don't think we can afford that luxury again.

> Even if you can't stand the thought of ASN.1, introducing a
> completely different encoding scheme would have to have almost
> overwhelming advantages to make it worth the bother of having two
> different and incompatible kinds of certificates formats at this
> point in time.

Were the problem compatibility, I would argue that PGP would have to
be the certificate format of choice. Virtually everyone I correspond
with has PGP and a PGP key certificate. I routinely use two other
public key representation formats, neither of which is
X.509. Personally, I only use X.509 in once place -- when using SSL
inside Netscape -- and I don't think that the hard coded certificate
handling there constitutes an installed base that we need sweat over
at night.

> Likewise, if people want to argue that there really isn't any
> purpose in havng some form of globally unambiguous naming
> information, whether based on e-mail addresses,
> geopolitical/organizations hierarchies, or a number tatootted on you
> at birth, I can't help you much, for such systems would simply not
> be sufficiently reliable in a global village environment to be very
> useful.

1) Perhaps such a system is needed, but starting from a blank sheet,
   assuming an internet environment, X.500 DNs are not the answer that
   comes to mind.
2) Commerce is conducted every day in the world I work in without a
   universal identifier for all possible counterparties. I am not saying
   that there aren't uses for global unique names. I am merely saying
   that your assumption isn't obvious from the real world experience
   the world of commerce yields.

> So if people have problems that they feel can't be accommodated by
> the existing X.509 structure, I'm more than willing to listen,
> because I believe that those problem are more imaginary than
> real.

An old mainframer I know still argues with me about how defective the
operating system I use day to day is, and how anything I mention can
be done easily and conveniently on my platform can be done just fine
on the mainframe with just a little bit of work.

After a while, such discussions usually end with my walking away and
wondering if the people actually understand the difference between
"can be done given enough work" and "is easy, convenient, and even
fun".

Perry
References: