Tim, I agree, in particular I do not think a protocol that merely changes the syntax of certificates would be worthwhile. The near term goal of our work has been to ensure that there is absolutely no excuse for not PKI enabling an application. Using XKMS it is possible for a device to implement S/MIME based on X.509v3 certificates while treating them as an opaque blob. While we can argue about the model in the context of email clients the argument becomes rather different when we consider wider application of PKI. Am I expected to cross-certify my refrigerator with the cofee maker and toaster? Does my VCR have to establish a certificate path to the television? PKIX is already deployed in many areas and will be the major force in PKI for some time to come. XKMS is primarily a complimentary technology. It shields the client from the complexity of the underlying PKI. It cuts through the Gordian knot of full feature PKI deployment being dependent on deployment of full feature client support that in turn waits for full feature PKI deployment. The objective is to stamp out passwords, not replace PKIX, at least not for quite a while. Phill > -----Original Message----- > From: Tim Polk [mailto:tim.polk@nist.gov] > Sent: Thursday, December 07, 2000 9:32 AM > To: Anders Rundgren; Stephen Kent; ietf-pkix@imc.org; Paul > Hoffman / IMC > Subject: Re: PKIXML session. Was: PKIX WG tentative agenda > > > Anders, > > It is very important that we come to some consensus regarding how > X.509-based PKIs can be integrated with XML-based clients. > This topic is > in my opinion within the scope of our charter. The PKIX WG > has spent a lot > of cycles on the list discussing this topic, so there is clearly > interest. It makes sense to deal with it as much as we can > during the > session. I deferred this discussion to the end since it will > consume any > available time. > > This is very different from a session on XML-based PKIs, > where ASN.1 is > never used. That is the session I thought you were > requesting, and it is > well outside our charter. It is not my role or Steve's to be > organizing > such a session. To be honest, I personally believe that XML is an > inappropriate encoding format for certificates (public key > *or* attribute). > > I am sorry you assumed we wouldn't discuss PKI and XML at all. The > discussion is incomplete if the "loudest PKI-XML proponent" > (or opponent) > is not present. > > Tim > > At 09:36 AM 12/7/00 +0100, Anders Rundgren wrote: > >Tim, > >What you are saying is that there _will_ be some kind of a > PKIXML session > >(short but something at least) > >which I have asked Steve K to arrange in and off this list > with no success. > > > >Unfortunately, I and few others cannot waste their precious > time on things > >that are decided > >in the last minute with no previous information. As we have > discussed this > >subject for a month > >or so, I am pretty disappointed on how PKIX handled this. > OK, maybe it is > >a "win" in somebody's > >view that the loudest PKI-XML proponent (who still insists > that this is a > >_market_ thing as well) will > >not be there... > > > >Anders > > > > > > > > > I am projecting a half hour for discussions on XML and > PKI. So far, Phil > > > has requested time to describe XKMS. If you would like > to present under > > > this general topic, please send me email. I will try to > get everyone some > > > time to present their views. > > > > > > Thanks, > > > > > > Tim Polk >
Attachment:
smime.p7s
Description: application/pkcs7-signature