[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XKMS
Phill,
Thank you for your e-mail. Your response leads to the following question:
Can a user select/ specify the trust model to be used ? If yes, how ?
A reply to the question raised in my previous e-mail would still
be interresting:
Does XKMS make a difference between the name of an entity
certified by CA1 and the same name certified by CA2 ?
Regards,
Denis
> All,
>
> The Working Group is currently working on a version 2.0 of the XKMS
> spec. It is (currently) functionally and structurally identical to 1.1 but
> has a number of important revisions to the schema. These align the schema
> more closely with the new XML Signature schema and SAML and make for much
> better extensibility. The other major change is to the structure of the
> Register function which previously combined 4 functions that are now broken
> out into separate calls.
>
> To answer Denis' point, XKMS does not define a trust model, the XKMS
> service defines its own trust model. The client is delegating the definition
> and concept of trust, not merely the mechanics of processing the trust.
>
> This has lead to debate over whether XKMS should support multiple
> trust models, so that the client could choose between them. At present this
> is possible by introducing multiple XKMS service point URLs, e.g.
>
> http://xkms.xmltrustcenter.org/vtn_class_1
> http://xkms.xmltrustcenter.org/us_gov_bridge_ca_confidential
> http://xkms.xmltrustcenter.org/us_gov_bridge_ca_classified
> http://xkms.xmltrustcenter.org/bal_keyserver
>
> Philosophically, the reason for taking this approach is that real
> world trust relationships tend to turn out to be slightly more complex than
> whatever closed form declarative mechanism is available to describe them -
> until the closed form becomes turing complete.
>
> It is a separation of concerns issue, by avoiding any commitment on
> the issue XKMS can support trust models that would probably be impossible to
> specify completely in a standards forum - providing a bridge CA across the
> VTN, the federal Bridge CA and BAL's PGP keyserver for example. While a
> perfectly good and usefull trust service could easily be configured for
> limited purposes any attempt to completely specify how to interoperate PGP
> and PKIX for all applications, cert issuers etc. is probably a futile task.
>
> As Steve said, this is the sort of issue we will be debating on the
> WG list.
>
> Phill
>
> Phillip Hallam-Baker FBCS C.Eng.
> Principal Scientist
> VeriSign Inc.
> pbaker@xxxxxxxxxxxx
> 781 245 6996 x227
>
> > -----Original Message-----
> > From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
> > Sent: Thursday, November 22, 2001 4:59 AM
> > To: Hallam-Baker, Phillip
> > Cc: ietf-pkix@xxxxxxx
> > Subject: Re: XKMS
> >
> >
> > Phill,
> >
> > I have XKMS Draft Version 1.1 draft 4. January 30 th, 2001.
> >
> > Since the document advertises at a bottom of a page an amendment
> > for a version 1.2, is there a more recent document available ?
> >
> > Is there a document that explains in a few pages the philosophy
> > besides XKMS in particular in terms of the trust model when
> > multiple trust points are used (i.e. multiple self-signed
> > certificates) ?
> >
> > Here is a related question: Does XKMS make a difference
> > between the name
> > of an entity certified by CA1 and the same name certified by CA2 ?
> >
> > Thanks.
> >
> > Denis
> >
> > > > Now I don't think that the folks working on XML-DSIG and XKMS are
> > > > really doing it better. There's also the tendency to be most
> > > > flexible by integrating as many PKI standards as
> > possible. Same old
> > > > problems...
> > >
> > > I think you are misunderstanding what we are doing. XKMS is an
> > > interface to a PKI. It is not by itself a PKI.
> > >
> > > Although it is quite possible to use XKMS in a network of peer-peer
> > > real time responders without the support of a backing PKI the more
> > > usual configuration would be as an interface to a PKI. In most cases
> > > that PKI would be PKIX based.
> > >
> > > The observations that the design of XKMS is based upon are:
> > >
> > > 1) Despite every effort, most developers hate, loathe and
> > detest ASN.1
> > > 2) Client developers complain that PKIX is too complex to implement.
> > > 3) We continue to add to the PKIX specification.
> > > 4) Implementation suggests that inter-organizational trust
> > justifies the
> > > complexity of PKIX.
> > > 5) XML based applications have a different risk profile to the email
> > > messaging applications that X.509 was originally intended to
> > > support.
> > >
> > > The point is that we have come a long way in 10 years and there are
> > > occasions when the thing to do is to attack a problem from
> > a different
> > > angle for a while. I find it very unhelpful for people to start
> > > throwing arround the 'do you think you know better' question.
> > > Clearly the people who put that question think they know better
> > > or they would not have asked it.
> > >
> > > Anyway, the proposal to form an XKMS working group is currently
> > > before the W3C AC reps. The first face to face is planned for 8th
> > > December in Salt Lake city. It is an open meeting.
> > >
> > > Phill
> >