[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on client auth
PALAMBER.US.ORACLE.COM wrote:
>
>
>
> Peter,
>
> You are wrong:
Im suprised that someone with so much OSI in his background
of theory and practice would make these ERRORs:
>
> >X.509 does not have a big problem with name spaces. It
> >provides a name syntax, and that can be administered in any
> >manner a user group wishes.
>
> It depends what you call a big problem, but X.509v3 has name space problems.
X.509 v3 and X.509 AM has NO name space problems; it got rid of them
specifically by saying; you, MR Community, choose your
own name space, and manage it how you will. If
names are now a problem, they are of Oracle's own making.
The X.509 work is NAME-INDEPENDENT, unelss communities
insert names of their own design. HOwever, WE ARE NOT
REALLY HERE TO DISCUSS X.509!! X.509 is just a minor
synatx some of us will use to implement SDSI/SPKI
system and ideas, where appropriate.
(incidentally, Ive already defined a X.509 mapping for the SDSI name space
and its admin procedures (which are "no-admin"). Im
quite happy to go key-centric also: ie. SPKI names ( which
are "no names", and no-admin!))
>
> 1) X.509 uses Distinguished Names (DNs) that can be very long
> making them difficult to use by humans (the name on the
> business card problem).
X.509 v3 does NOT (note NOT) mandate use of DNs. These are an additional option
for those who see their value. Not many of us, here, do. This
is therefore not a problem. Dont use the feature; issuer
and subjectDN are not required fields; place ZERODNs
there, by common IETF assent.
> 2) DNs were designed to be globally unique. They are not.
> There are no viable mechanisms in place to ensure globally
> unique names.
DNs are not a required feature. They are not a problem therefore.
Aside on minor history, which Id expect you to know:
DNs are not designed to globally unique though, the
related notion of DirectoryName is so defined. The
difference is precisely one of DirectoryName - which
assumes all directory agents are connected in the great
DirectoryIntheSky, whereas DNs are a mere techncial notion which
asserts that the names are unambiguous within
a local community shared database; another database, operated
independently, may of course have the same DN.
> 3) The schemas for X.500 DNs are poorly defined. You do not
> know for sure what can be put into a name without detailed
> schema profiling.
DNs are not a required feature. They are not a problem therefore.
Historical Note:
Im sorry you think IETF's Vint Cerf, Steve Kent, and Steve
Kille are so poor intellectuals as to have so
badly designed the Internet-oriented DN schema. Perhaps
we should all review their work in the relevant RFCs...
and issue condemnation. That there work on distributed domain-based
inband schema-management served as the basis for the 1992 revision
to X.500 is also a poor reflection on their capabilities.
Have you read 1992 X.500, Paul? its all about schema-management!
But this is irrelevant topic, as we are all
here trying to do SDSI/SPKI naming, anyway!
> 4) Full name uniqueness in X.509 is determined only by reference to
> the DN and serial number of the issuing authorities(s).
> The "full" unique identification of a X.509 entity now becomes
> very large.
DNs are not a required feature. They are not a problem therefore.
The X.509 AM assumes one need to identify the superior trust
point. it gives std fields to accomplish this, should one wish. AS
you know from your own work so intimately supporting NSA's
OSI-based SDNS KMP, and DMS X.509, work, this is not even necesary, as local knowledge
may be used in place of such fields. There are costs and benefits
to both techniques.
Should one find the current mechanism too hard, then of course
one simply defines a new extension which is, say, a
short identifier. In X.509 v3 we are free as community to do this;
its only syntax!
BUT, I saw NO such requriements expressed in SDSI, so can assume this
is just a irrelevant academic sideline designed to
split people's allegiances over non-issues.
> 5) X.509v3 supports a subject DN and alternate names. Given
> the many applications will not want to use the subject DN,
> these applications will have to support two parallel name
> spaces in the evaluation of a certificate (the subject
> and alternate). The subject name should be allowed to
> be a General name rather then just a DN. The slow
> ISO process prevents this modification.
DNs are not a required feature. They are not a problem therefore.
Also, note, issuer/subjectDN shall be indicated as having a value of
ZERODN when so desired by the community to defintively destroy all
DN notions.
You statement about use of GeneralName as the only
evaluation basis is NOW true. There is nothing
required from ISO, here. This was by (recent) design.
But, once again, SDSI made no mention of this
requiremnet. So why are we discussing it?
Why did you introduce it?
> 6) The X.509v3 certificate only supports a single backward
> reference to a issuing authority. In a multi-rooted
> trust hierarchy or in some cross certification scenarios
> the result of a validation process can be ambiguous.
No. the std extensions support one model of domain organization.
X.509 v3 facilitates communities defining their
own backpointer notions, and specifying procedures for
its evaulation as they wish.
Here is the hard task of defining a Oracle X.509 v3 extensions:
Oracle'sLatestAttemptToMaintainProprietaryTechnologies EXTENSION
SYNTAX IA5String -- see BNF
ID internet.extensions.1.1
-- BNF:
-- olatmpt -> "oracle" ":" tbd
-- tbd -> "anything except open, multi-provider, key management backpointer"
To be serious: (the above defn is not)
Ill check it the AM faciliates multiple backpointers. I suspect
there was desire to eliminate such non-ambiguity.
But, why is this relevant to SDSI/SPKI; there is no discussion
of this feature requirement in those documents!?
Why are we now criticising a document's features
which is not required for the current design!?
The whole point of SDSI/SPKI was, sod the naming adminisration
stuff. Now you reintroduce it. WHY!
X.509 listens to us all, and gets rid of all that
stuff by generalising. So, now Oracle says, we need it! Strange!
The more I read, the more I like SDSI/SPKI, without
all these Oracle Complications about non-issues.
Peter.
>
>
>
> --------------------------------------------------------------
> Paul Lambert Director of Security Products
> Oracle Corporation Phone: (415) 506-0370
> 500 Oracle Parkway, Box 659410 Fax: (415) 413-2963
> Redwood Shores, CA 94065 palamber@us.oracle.com
> --------------------------------------------------------------
>
>
> ---------------------------------------------------------------
>
> Subject: Re: comments on client auth
> Date: 11 Jun 96 15:19:48
> From: "Peter Williams " <owner-spki@c2.org>
> Reply-To: peter@verisign.com
> To: Carl,Ellison,cme@cybercash.com
> CC: spki@c2.org
>
> Carl Ellison wrote:
> >
> > At 02:04 PM 6/11/96 -0700, Peter Williams wrote:
> > >Im
> > >assuming the SDSI models are coherent with SPKI!
> >
> > SDSI has solved one of the biggest problems I've seen with X.509-like certs
> > -- the lack of a global name space.
>
> X.509 does not have a big problem with name spaces. It provides a name
> syntax, and that can be administered in any manner a user group wishes.
>
> That SDSI model chooses the name admintration model first pratically advanced by the
> NADF - namely a collection of large adminsitration-managed domains (with
> CA's as roots), in which there is full freedom for each node=naming-context
> to choose the names of subordinates - is great. SDSI is pure X.500, using a
> selected profile based on disjoint ADDMD domain adminsitration (to be formal)
> and a single class of named object, where each naming element (arc) is a autonomous
> naming context (phew!)
>
> The other signiificant reason why X.509 has not a problem is
> that one need no longer bother with X.500 names whatsoever,
> at the behest of many who have long since stopped listening
> to the above argument, regardless of merit. We can
> now all choose our own syntax and format, be we
> EDI, Internet, SDSI, or whatever.
>
> The final reason why X/509 has no problem, as there
> is absolutely no need to use the BER/DER encoding rules.
> So lets use S-expr as the canonical encoding. Hopefully
> someone will assist us have international char sets...
>
> X.509 v3 certificate directly facilitate names based on SDSI name
> forms "Bob's Cat's recent-meal's (mouse's) public key". The
> difference between this and and encoding "cn=Bob; cn=Cat; cn=recent-meal"
> is hard to tell, but its irrelevant. Lets use the anglo-saxon-biased
> format with its possesives and western char sets. Why not! (sic)
>
> Rivest and Lampson have recognized that
> > there is no such thing -- that all names are local. To me, this smacks of
> > early Relativity work and I think we're all convinced that it's a Good Thing.
>
> R/L re-introduced a classical naming scheme, the like of which has
> been around for 10 years. I was a student when I read Lampson's
> NATO seminar texts on this distributed system's naming stuff!
>
> It hasnt changed very much! X.500 also facilitated local naming
> as inherited much of DEC early work.
>
> >
> > They took that and extended it to allow a nice method of defining groups.
>
> Yes. But I didnt really follow this bit. Ill try harder.
>
> >
> > They've chosen an S-expression encoding with which some SPKI folks quibble,
> > but to me the encoding isn't anywhere near as big an issue as the contents
> > of a cert. It's very important, IMHO, to throw out the kitchen sink and
> > reduce certs to basics.
>
> The difference between an S-expression encoding and the X.509 D/BER
> encoding is so minor as to not hopefully be an issue. Anyone
> who objected to ASN.1/DER must reject S-expressions, as ASN.1
> may have S-expression encoding rules, binary or text,
> as BER and S-expressions are both just tag-(length)-value recursive
> structures. S-expr has a text tag, DER has a binary number tag chosen
> by the user.
>
> >
> > There is one apparent divergence between SDSI and SPKI which will work out
> > shortly, I predict: SDSI as described in Ron's paper is strictly
> > name-centric. I have a way to merge key-centered certs into that structure,
> > but I haven't written that up yet much less gotten agreement from Ron and
> > Butler that it fits in their scheme.
>
> This will be interesting. As long as you *merge*, this will be great.
> We will soon have reinvented the X.509 syntax, and the generic
> authentication framework capable of all these various models.
>
> >
> > Beyond that, the person I mentioned who is implementing SPKI is inside a
> > large corporation where SDSI's name linking isn't as important as it is
> > among us web crawlers. The corporation has a single name space. However,
> > as they extend services to their customers, SDSI's naming will become very
> > important, IMHO.
>
> Naming is a management issue; few people bother to think through
> name management until their deployment size hurts or costs too much.
> This is why Verisign chose to ignore name mangement in our Class 1 cert
> service, and let users choose their own names. After a while,
> I suspect consumers will tell us they care more...
>
>
> >
> > Beyond that, SDSI is a little weak in attribute certification. It's all by
> > group definition. Blaze/Feignebaum/Lacy have a good start at improving that
> > and I've been working with one other person on an enhancement which should
> > save a great deal of time and effort in dealing with certificates.
> >
> > So -- what I write as my offering for the RFC isn't going to be straight
> > SDSI, but it will certainly use that work!
>
> great. So far Ive heard NOTHING which isnt catered for in the
> X.500 naming model, and expressible in the X.509 syntax with an
> S-expression or any other recursive TLV-encoding.
>
> If one uses S-expr, and has the public key before the name,
> really quite irrelevant! All we need to do now is reinvent
> an extension mechanism...
>
> Is all SPKI mail of this quality; Id heard it
> was mainly an anti-ASN.1, anti-ISO rant, so didnt subscribe
> given the irelvancy of these topics to the issues.
>
> As Warwick Ford says - its only syntax!
>
> >
> > --------back to your regular channel---------
> >
> > - 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 |
> > +--------------------------------------------------------------------------+
Follow-Ups: