[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ANNOUNCEMENT: SPKI mailing list and BOF at Los Angeles
I'll keep this as short as possible, and go along for the ride.
>
>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.
Whether that is good, bad, or indifferent depends on what your intended
applications are, I suppose. Maybe we should come to some consensus as to what
the problems are that we are trying to solve (for which X.509 is allegedly
unsatisfactory/insufficient) before we jump to such a conclusion.
> 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.
I'm interested to hear his argument, as I do not yet understand the concept
that X.509 is a "model".
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.
It appears that there may be two different groups of people who would like to
discuss these issues -- the virtuous and the unwashed, saints and sinners,
Republicans and Democrats, etc. What isn't yet clear to me, at least, as that
there are two different constituencies of END USERS, with sufficiently
different requirements as to justify deploying two different infrastructures
that will apparently do the same thing. But I'm willing to listen.
>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
This seems a little disingenuous. The paper was pretty darned blank five years
ago when an IETF working group composed of some pretty bright people with a lot
more Internet savvy than I had picked that format for secure electronic mail.
Do we have shades of IETF-ness here?
>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 happen to agree with you, and we can now see that MasterCard and Visa intend
to operate their own CAs (on behalf of their member banks). You aren't going to
go to the equivalent of a Department of Motor Vehicles and get a certificate
that says that you are a MasterCard customer. No independent third-party CA
would want the responsibility or liability for determining credit worthiness,
unless they got a percentage of each transaction to cover their risks.
>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.
I'm interested in identifying and solving those problems, whether they occur
inside of an X.509 certificate itself or elsewhere in the infrastructure. The
problems that I have heard to date involve the infrastructure, and/or the way
that people think that DNs "ought" to be composed (the schema), and have very
little to do with distinguished names in and of themselves, and even less to do
with X.509 itself.
>
>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.
Sorry, an elistist, antropomorphic slip of the tongue. I meant "entity."
>
>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.
Now we are finally getting down to something that might be quite interesting
and useful, regardless of how we get around to encoding the results.
I certainly agree with the need for different roles, and have argued that the
present set of X.520 attributes is inadequate to represent a matrix management
situation, for example. I may want to have a commonName (John Doe), a title
(Department Manager I), and a roleName (QA Team Leader).
In some cases, a certain amount of anonymity may be required, e.g., Pajama
Inspector No. 7. But this could also be handled by omitting the commonName and
optional title, and giving that entity a roleName of "Pajama Inspector" and an
optional serialNumber.
In the case of a client, server, or other process, it would be quite useful and
of immediate benefit to think through what the naming/identification
requirements really are.
If by instantiation you mean which task ID a reentrant process is running that
happens to need a certificate, I would tend to agree with you. Presumably it
would be sufficient to identify the name of the application program that
implements it, qualified by the processor name it is running on. (Sort of like
an individual's name and address, isn't it.)
But the name of the application isn't all that would be nice to know when
something goes wrong, goes wrong, goes wrong, ... We'd probably like to know
who is standing behind and responsible for this surrogate that is signing
checks issuing credits, etc. After all, I can't put a PC on the witness stand
-- at least not yet. (A Macintosh might be a different story, at least if you
believe the more vocal Mac users.)
>
>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.
But Jueneman@gte.com _IS_ a distinguished name, at least in one particular
schema (actually, it's an alias of the real account name, which is too cryptic
for external users.)
Is there some computationally-infeasible hard problem here? We can either look
at that name space as one enormous flat file (not too good for searching), or
we can divide it into a mailbax name plus a domain name (very reasonable), or
we can interate the decomposition of the domain name into its constitutent
parts (probably unnecessary).
However, I'm not entirely sure that I would want to link my key "name" with my
mailbox name too tightly. If I make a mistake in selecting someone's mailbox
address from my address book, it would be less than helpful if I also selected
the (wrong) key at the same time, and sent the message to the wrong person in
that person key, instead of the person I intended to send it to.
>
>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.
Althouhg you stressed that the IETF is an engineering organization, it is in
fact astandards setting body like most others. It's just that the voting
process is messy.
But the notion of starting with a blank piece of paper strikes me as naive.
It's perfectly fair to rethink the design decisions that have been made, but
assuming that you can then ignore the practical, pragmatic issues of existing
users, a process that is moving and gaining ground, etc., doesn't make a lot of
sense.
>
>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.
Then I think that you do not understand the problem, or to be more charitiable,
the problem set that you are focusssing on is much smaller and more amenable to
such solutions. Are you suggesting, for example, that there is no need for
private extensions in X.509, e.g., as defined in the masterCard SEPP spec and
more recently in the joint MC/Visa SET spec?
>
>It is for this reason that I do not see the need for a definition
>language or non-ad hoc encoding method here.
>> We are too close to having a real consensus emerge on an X.509-based
>> 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.
I don't mean for this to be a two-person dialog. So far, I haven't heard many
others join in the help define their problem set, so I'm unable to gauge
whether there is a concensus for an alternate view or not.
>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.
Out of curiosity, what are they?
>> 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".
Ease of use, convenience, pleasure, and even pure laziness are valid reasons
for picking one alternative over another. I'm claiming, after having thought
and written about many of these problems rather extensively over the last five
years, that with the imminent arrival and support of X.509 V, there is little
of any certificate work per se that has to be done to support any application I
have been able to think of so far, from casual e-mail up to certifying billion
dollar CyberNotary transactions.
But it's certainly possible that missed some important applications, so I'm
more than willing to listen. I'd just like to focus on the problem set first,
and the solution set second.
Bob
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Jueneman@gte.com
1-617/466-2820
"The opinions expressed are my own, and may not
reflect the official position of GTE, if any, on this subject."
Follow-Ups: