[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on client auth
Brian M. Thomas wrote:
>
> Peter Williams <peter@VeriSign.com>:
> [lots of confident assertion that X.509v3 could do all that SPKI wants]
They were not assertions; they were propositons, based on compare
and constrast between the requirements and models. The propositions can
perhaps be shown to be false to demonstrating where the similarity
was wrong, else a requriements has not been addressed
in the comparison.
This I would welcome a teaching of, as a professional wishing to wholly
dominate the knowledge area of the area I work in. Im
almost always wrong in my analyses!
>
> I'd like to believe that an existing standard that has accrued a fair amount
> of market acceptance would in fact do everything that we need. I will need
> a lot of help from smarter people than me to figure out whether that's true,
> however, and that by itself doesn't bode well, though it doesn't bother me a
> great deal - it took smarter people than me to build the systems I routinely
> use in my work with great confidence. I look forward to a robust discussion
> of that issue, in particular the questions of how multiple key-centric
> certificates, with identical naming attributes, can be served by an X.500
> service.
I have yet to see the requirements addressed by
this standards group, though have abstracted some from Rivests paper;
this was the basis for the analysis summary I presented
yesterday, and reinforce below:
X.500 service is really not the topic. We are surely discussing X.509,
a piddling little data format which is designed to be used
anywhere, with any management style, any administration model, and
with any name forms, in any security systems, and under
any issing policy, in any nations legal system, and
on any computer.
Its hard to imagine anything more generic than an
X.509 data structure! Even PGP is more constrained
as it only exists for infosec privacy, whereas x.509
exists for control systems, comsec protection, wireless, payment,
telephony, and even data(!) protection systems.
By analysing the SDSI paper, and its well-presented abstract notions,
I mapped those abstracts onto the standard features of X.509 MODELS (and
X.500 naming MODELS). There were NO missing piece in the notions
or elements standardized by ISO, required to perform the culture of
control which the SPKI supported wish to see, as evidenced by
the system & infrastructure design expressed in SDSI.
The Blaze model on distributed naming is not in fact new;
its 10 years old, been abstracted by many intellectuals, and even
even standardized by ISO years ago. This is how old this model is. I wouldnt
dare to publish this stuff, and claim it original work worthy
of a major journal; its embarassing.
The SDSI data encoding rules are at least 15 years old, are
generic recursive structures first actively used by Xerox,
and so old a dsign they were even standardized by ISO... The DER form
of ISO encoding rules is so like S-expr binary encoding
as to be...well the same, but a little wiggle-room.
The SPKI notion of a SIMPLE infastructure is already estalished
in the "v1" model of X.509, where there is just a key
and a name, plus some minimal management data to
faciliate lifecycle management where keys go into a
systems, and get pulled out again, under the users or
issing organizations control (dates, version#).
If you dont want a name, dont put one in. See, its easy!
>
> My issue, however, is one that I have not heard discussed at all so far on
> this list: that of implicit trust. There is implicit trust involved in any
> certification path that has a root that is someone else. When I chase a
> chain of certificates to a trusted root, the thing that bothers me is *why*
> I trust that root.
The same reason why you accept the State of California when
verifying and validating a drivers license used as address guaratee card
when accepting a cheque. There is no difference
in the decision to "accept" a lower trust point, to one at the
top. You either trust your phone company to bill you correctly,
else you keep massive, timed records yourself. Most of us
trust, though bitch alot at the bar.
Put another way, *how* can I be sure that the trust that
> I as programmer had in the root that *I* intended to install in that place of
> trust is appropriate, given the possibility of compromise along the path from
> my statement of trust to the execution of the program?
This is not a question for protocol, but for trusted software or
other means of semi-guaranteeing the integrity of data used in
a security enforcement function. There are book and books
on this topic. At the end of the day, you will choose
to trust the name of the engineering company ,
and make an informed judgement that you
will take a risk based on their reputation/promises to
cover the damages, if it does break within fair
use of the product. You will also take an informed
decision to accredit the product yourself, just
as you choose which toys are safe for your
baby, or which web-sites your kids may browse
to.
The best thing that
> we could come up with in our implementation was that the programs all had the
> root name and key compiled into their execution code. If we were able to be
> absolutely(well, all right, reasonably) certain that no one could substitute
> that key, either in the linking process, or during or after the delivery of
> the compiled executable, it would be all right, but a program doesn't know,
> does it, whether its code was appropriately protected from tampering?
There are techniques, which military systems use to highly protect
trusted software binaries, based on mostly non-deterministic compile-time
instruction code generation techniques, and sympathetic
loader/run-time isntruction executation semantics. Ask your security company
if they use them in their products; perhaps decide to
accredit these vendors higher than those who dont. Its much harder to interfere
with these binaries, than with your average-users home-PGP-compile.
>
> Bear in mind that the issue is not whether the operating environment *can*
> be secured in such a way, but whether I can know at runtime that it *is* so
> secured. If our friend A. Clueless User, for whom we are building all this,
> is fooled into running the wrong program, everything we worked for can be
> out the window (Obviously, this has always been true, and I want my level
> of paranoia to be reasonable %>, still...).
You are surely discussing trusted systems, not trusted key distribution.
Im guess this is out of scope here, though mega relevant to IMPLEMENTATION.
If the ultra-violet pen you are scanning dollar
bills with, to detect fraud, has been tampered with,
you get the wrong answer. Millions of such pens are
in useful application, despite the truth of the proposition.
Practical security means users take risks ,and accept
those risks. Determine how much security you can afford
for the damages you will occur in the event
of compromise, at what ajudged likelehood of occurance.
>
> On the other hand, if a certificate were to be made from any statement that
> could be uttered by any human in any appropriately understandable way (such
> as X.509 certificates and PGP certificates do about names, which humans who
> send or read mail messages can authorize appropriately),
An X.509 cert may or may not make a statement, and may or may not
make a statement about names. This is why is so silly to
have a conflict over a data format. It means, whaveever
the issuer says it means, and a relying party accepts by
agreement or by choice; you believe the issuer, or you dont;
however you express it. I trust VISA to guarantee my loss to $50,
based on a system of control producing a bit of plastic. Thats
it. I dont trust DMV to validate my address on my drivers license,
though I do expect them to regulate that I must inform
them when my residence changes. Each issuer control
is different, with different propoerties. The cert is
just a data structure. Use S-expressions, use DER, use
PGP certs; it makes not the slightest difference to the above
requiremnets and obvious characterisations of signed statements
saupprote by certification, be it the existing manual system
adminstiratered by lawyers, else the automated versions
represented by the VeriSign CPS-controlled Cert semantics.
Use 7bit chars else 8-bit, its still makes no difference.
What matters is who issues it, and have faithful they
are to their practices.
So, its the model which counts. not the encoding nor the syntax.
Given SDSI certs are AS COMPLEX an encoding as X.509 DER,
there is essentially no difference to implementors, here,
when faced with a scratch implementation effort.
then chains of
> authority, not identity, would be possible, and (this is the point, finally)
> the final arbiter, the trusted root, is the relying party {him|her|it}self.
Yes. this has been said by Warwick Ford, only a million times. He
goes to one improved step, to save too much individual angst; namely,
trust your local adminsitrator (head of family) to configure which roots
you (as a group of trusting souls) all want the accept. This
is an announced Netscape product direction, with (irrelevantly) X.509
certs. Again, nothing about the syntax denies this,
in fact it support it.
> That's what we have been trying to do, but implicitly, via corruptible
> mechanisms. All trust and authorization is therefore explicit, and the
> semantics of the authorization can be whatever the relying party wants it to
> be, since nobody else cares about it. Obviously, standards could be evolved
> for those, but they could be specific to the applications, and not hold up
> generic standards efforts while they try to make absolutely sure they've
> figured out every nuance of every possible use of the generic standard.
> I think that's revolutionary in its simplicity and security.
This is exactly the VeriSign CPS. Note, its a policy of consensual
control, or selection of optional controls, between issuer, subscribers and
relying parties rather than some technology format issue, or otherwise.
We asserted in the design that for Class 1, the risks are low, have
implicit controls. As the risks get higher, fequire explicit controls.
In all case, permit explicit controls. This first document by
STeve Kent in RFC 1422, where he asserted that, even for trusted
per-user (IK) keys (aka PGP style), ONE MUST facilaite the user seeing
the entire chain, if s/he wants to revalidate and reassure. Anything
less is not enough.
>
> In case it matters, I am the anonymous "person" to whom Carl refers, the one
> who has implemented chains of authority, including ACLs and group memberships,
> and the authorization to sign those authority instruments, without the benefit
> of simple certificates, and has therefore been working on replacing it with
> an SPKI-type structure.
We have no disagreement. we are very much aligned in our models. SDSI
(I cant speak for SPKI documents I have not read) MODEL partially
addresses some of your requirements, though with deficiencies based
on lack of real understanding about the nature of relying
parties, and the separation between semantics of validation
and verification, as long-established by equivalent
manual legal-attestation and certification, commision
of oath, and notarial practices.
SPKI setout of simplify public key infrastructure; based
on this set of issues, the issues are just as complex
as ever, having NOTHING to do with data syntaxes or
encodings.
I had expected to see SPKI dump all the legal stuff,
and just say - here's a key. Now the world is perfect.
If this mail is the actual topic area Ill join the list!
Ill work with SPKI formats for the standards process, then
deploy whatever/whichever technology is most economic,
though obviously 100% equivalent to the SPKI standard.
I think the benefits are enormous, and primarily involve
> throwing away a lot of custom code. I'm trying to write a paper that will
> describe the effort, but of course, I'm also trying to convince my fellow
> designers to adopt the idea(theirs is some of the code I'd like to toss). Feel
> free to mail me with questions, comments, etc.
That you should use a standard module for the cert bit is obviously
an engineering issue. I dont seek, however, to
evangalise one data format or another! Its quite irrelevant.
The relationship between authority and final assertion of id
is a debate at least 2000 years old.
To be practical, I know all VeriSign is doing is automating
the existing manual system, which seems to work
for the common man, though perhaps not the intellectuals!
Ive so far enjoyed SPKI. Thanks!
>
> Brian Thomas <bt0008@entropy.sbc.com>
> Southwestern Bell
> One Bell Center, Room 23Q1 Tel: 314 235 3141
> St. Louis, MO 63101 Fax: 314 331 2755
Follow-Ups:
References: