[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: XKMS

To: Tarun.Matai@xxxxxxxxxxxxxxxxxx
Subject: RE: XKMS
From: "Housley, Russ" <rhousley@xxxxxxxxxxxxxxx>
Date: Thu, 27 Dec 2001 10:57:30 -0500
Cc: ietf-pkix@xxxxxxx
List-archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-id: <ietf-pkix.imc.org>
List-id: <ietf-pkix.imc.org>
List-unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
Sender: owner-ietf-pkix@xxxxxxxxxxxx
I am not sure why your question is in a message with this subject.

Please take a look at RFC 2630.  If this does not answer your questions, 
please post specific questions to the S/MIME WG mail list
(ietf-smime@xxxxxxx).

Russ

At 04:19 PM 12/27/2001 +0530, Tarun.Matai@xxxxxxxxxxxxxxxxxx wrote:

>Hi All!
>         Merry Christmas and a very happy new year ...
>         Can any one tell me what is counter signature and how can I verify
a
>counter signature
>         Pkcs#9 standard says that the counter signature is an pkcs#9
>attribute and the structure is like signer info of pkcs#7 then what is the
>difference.
>The standard also tells that counter signature is a signature on the
>encrypted hash...
>"Encrypted hash " of what???? If it is of original data then which key is
>used for the encryption.
>If there are more than 1 signer infos and then I perform the counter
>signature then how is counter signature made.
>
>Thanks in advance.
>Regards
>Tarun
>
>
>  -----Original Message-----
>From:   Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
>Sent:   Friday, November 30, 2001 10:43 PM
>To:     Hallam-Baker, Phillip
>Cc:     ietf-pkix@xxxxxxx
>Subject:        Re: XKMS
>
>
>Phill,
>
>I noticed that my original question is still not answered:
>
>Does XKMS make a difference between the name of an entity
>certified by CA1 and the same name certified by CA2 ?
>
>Would you be able to answer it ?
>
> > To tie the issue back to the DPD/DPV issue which is probably your
>immediate
> > interest:
> >
> > 1) In the XKMS model the client is not 'in normal circumstances' going
to
>be
> > defining and configuring the trust model, that is the job for the
server.
>
>In the DPV model, this may be pre-defined at the server or set-up by a
>client, but not an ordinary client, an administrator acting as a client. So
>there is no major difference on that aspect.
>
> > 2) The XKMS client may select between different trust models by
accessing
> > different XKMS services, possibly different ports on the same service.
> >
> >         [This has lead to the understanding that the XKMS request and
> > response should contain the authenticated port URI to prevent
substitution
> > attacks].
>
>This means that a model can be selected via a reference, e.g. an OID or a
>URI.
>
> > 3) If it was decided to support client definition (as opposed to
>selection)
> > of the trust model there would be an additional set of services to
support
> > that use. These services would fall within the 'tier 3' of the original
>TAXI
> > (Trust Assertion XML Infrastructure) model, i.e. something that would
not
>be
> > supported by the average client application.
>
>This is the optional Policy definition protocol (PDP) defined in section
10.
>
> > I can certainly see a role in which XKMS and DPD/DPV would interoperate.
>In
> > particular the case of an XKMS gateway which recieves XKMS requests from
> > lightweight clients, applies local, (possibly proprietary) set of rules
>and
> > fires off OCSP, DPD/DPV, LDAP requests as appropriate.
>
>The only problem is the matter of transitive trust, since when transposing
>one protocol into another, all the security (in particular the digital
>signature) is lost at the gateway.
>
>Denis
>
> > 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: Friday, November 30, 2001 7:03 AM
> > > To: Hallam-Baker, Phillip
> > > Cc: ietf-pkix@xxxxxxx
> > > Subject: 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
> > > > >
> > >
>---------------------------------------------------------------------------
-
>
>This message contains privileged and confidential information and is
>intended only for the individual named. If you are not the intended
>recipient you should not disseminate, distribute, store, print, copy or
>deliver this message. Please notify the sender immediately by e-mail if you
>have received this e-mail by mistake and immediately delete this e-mail
from
>your system.
>
>
>E-mail transmission cannot be guaranteed to be secure or error-free as
>information could be intercepted, corrupted, lost, destroyed, arrive late
or
>incomplete, or contain viruses. The sender therefore does not accept
>liability for any errors or omissions in the contents of this message which
>arise as a result of e-mail transmission.  If verification is required
>please request a hard-copy version.
>
>
>--------------------------------------------------------------------------




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================
Prev by Date: RE: XKMS
Next by Date: Attribute Certificate for IP address allocation object
Previous by thread: RE: XKMS
Next by thread: EJBCA 1.0 Beta2
Index(es):
- Date
- Thread