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

Re: comments on client auth

> Peter,
> Thanks for the comments ...
> ><Peter>
> >DNs are not a required feature.
> >They are not a problem therefore.
> I will have to mull this over ... you are correct that all my issues were
> directed at DNs.  DNs are not required, but implementations are being built
> using DNs and interoperability concerns will force the support of dual name
> spaces.
> Paul
This is now indeed a SPKI issue, as we are onto names (DN organised or

The requriements for SPKI naming are surely these:

(a) the name space shall be managed
(b) naming domains can be private, else public, and shall thus require administration
(c) a name synatx shall be used to organize name elements
(d) a naming schema shall be evident
(e) name elements shall denote some class of object
(f) name elements shall have some syntax and char set, or other rendition such as graphic
(g) a purpose of naming be identified

Now, it turns out, these are exactly the same requirements as for DNs,
but that is a nasty term, here. Also, DNs have connotations of DirectoryNames
and all those directory-domain-management issues we need not be concerned
with, during the pure "simple" PKI analysis.

My understanding of SDSI is that (a) - (f) are instrumented in the
SDSI environment thus:

(a) space is managed in a distributed manner, segemented by CA, with
full autonomy to any entity to name anything else in the domain

(b) CA-headed naming domains are mainly public, and distinguished competitively
rather than technically, by CA authentication and "quality" policy, not name notions

(c) the name syntax is an ordered list

(d) each and all superior name elements provide a possesive naming context for each
and all of its subordinates, and denoted subordinates may or may not be distinguished
from each other by the element value. Subordinacy is indicated by greco-latin language "posession"
(e) the class of object named at any point in the space is "principal". any
principal can issue useful authentication statements, and also name others, and (I believe
though Im not sure here) issue SDSI-certs whose issuing constraints are
conformant with the CA policy of the trust domain

(f) name element syntax must be a visible char string (visible to anglo-saxons
that is)

(g) purpose is to cite property ownership of the public key, through linked
attestations through the name-based introduction-chain of (c) and (d)

The verification process of a digital signature supported by such a certificate is
not described in SDSI as far as I can tell, as the validation portion
of certificate's trueworthyness acceptance process is not specified.

As naming and keyingn are tied in this system of ideas through the
notion of individual posession (a anglo-saxon imperialist notion, but
lts ignore this class of criticism, for now) there are unstated
assumptions as to the properties of the keying material.

There seem to be assumptions that are satisfied magically:

(1) no principal shall ever share a keyset
(2) the compromise of a key shall be immediately signalled and
resolved throughout the entire principal network
(3) verification of the uniqueness of keying material shall be guaranteed
during each naming attestation by each and every principal in the domain
(4) legal trust guarantees are indicated

My gut feeling is that AT&T are setting up the notion of CA not
(as in X.509) as a principal-controlled service of once-time third-party 
authentication management, but as the behind-the-scenes 
management system which performs the magic of (1) - (3).
The (4) notion is simply a function of being a subscriber to
the particular domain, I suspect.

Such magic shall of course not be standardized, representing
the concrete business interests. By esetablishing an abstract
model here, which - for commercial grade use in the commercial
CA domain - would require that (1) - (3) are indeed satisfied,
the market is formed, and principal-management network 
service sold. Great marketing!

We could compare and constrast with the liberating peer-peer
assumptions of the DN model's choice of how it intruments
(a) to (f), and the DN philosophy of how the entire infrastrsucure
are managed by the principals or their affiliated groupings (i.e.
not the CAs), but perhaps we are required to do this on a different

How simple is the above, as a model?

Its really simple! Its the telephone system model prior
to AT&T breakup. Each CA domain is a national PTT,
and each principal a telephone-switched terminal. The notion
of SDSI-name-attestation is simply that equifalent to the phone company
storing *your own* list of telephone parties at its
centrex switch, which you are allowed to change if
you pay.

This, to my eyes, is the bad old CCITT-version model when applied
to X.400 email services, prior to ISO ensuring that the MOTIS model (internet
model) of organizing email could also be internationally

Its strange that the internet-model of collaborating peers
represented by the DN instruments is not right for the "simple"
Internet PKI, where the telephone company centralised manegement 
model is that being here pursued!

Having see the output now of the Blaze (AT&T research) model
and its impact on selling managemnent services, I think
we should all take careful and closer look at the distributed
trust model ideas, applied to SPKI. Ive yet to read the relevant 
paper, though have seen its impact upon SDSI, and am currently
deeply worried for the soul of internet peer-peer communications structures
which its name and certificate management model seems so far to viciously

But Im still learning about SDSI/SPKI; these early opinions
may be turn out to be based wholly on ignorance.