[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-CARM] PKI, CAs, TTPs &c.
> From: "Brian M. Thomas" <bt0008@entropy.sbc.com>
>
> George:
>
> Unless I badly misunderstand you, this is one reason for the existence
> of the SPKI working group. It begins with the notion, illustrated by
> the design, implementation, and subsequent operations of the Internet
> itself, that centralized control structures don't scale. From there it
> observes that the verifier of a message is the ultimate root authority,
> and thus that all authority which it recognizes effectively flows from
> itself.
Brian,
If this is the reason for the existence of SPKI, it reflects a lack
of understanding of PKIX. One of the largest X.509-based product
suppliers (Northern Telecom / Entrust Technologies) and a major consumer
(the Canadian Government PKI) base their architecture on a topology
where each user's root authority is that user's CA. It is one step
removed from the verifier being his own root, but it's close.
Santosh Chokhani, author of the PKIX certification practices framework
specification, refers to this as the "trust begins at home" model. So
"centralized control structures" isn't an X.509 thing, it's just one
supported option among many.
> My interest in SPKI has always been from the perspective of
> wanting standardized code to do what must otherwise be accomplished with
> lots of custom coding for each type of authorization. PKIX is clearly
> not interested in this; they are already committed to using X.509 to do
> the job.
This is a false dichotomy; PKIX (by definition in it's IETF charter) is
committed to using X.509 Certificates and Attribute Certificates to
transport identification and authorization information in standardized
containers. PKIX includes definitions of many standard extensions and
attributes. SPKI defines a standard container format, but no standard
authorizations. If one has a particular application, it seems that the
amount of custom coding required to support it would always be the same
or less with X.509 because many common requirements are already
standardized in X.509. Proof: anything that could be put into an SPKI
<auth> field could be put verbatim in a hypothetical X.509 id-pkix-auth
attribute.
Of course a "full" X.509 implementation which supports every standard
extension and attribute will be larger than a "full" SPKI implementation
which has no standard authorizations. But it's easier to strip out
someone else's code for the things you have no use for than to write
your own custom code for everything you need.
Dave Kemp