Subject: Re: PKIXML session. Was: PKIX WG tentative agenda

From: [email-masked]
Date: Thu, 7 Dec 2000 09:39:45 -0800

<snipped>

>> To be honest, I personally believe that XML is an
>> inappropriate encoding format for certificates (public key *or*
attribute).
>
>Forgive me, I'm just an academic. So, my I ask, what does the encoding
>format really matter? And especially, why is XML "inappropriate" for
>certificates?

I believe there is a future for XML (or it's replacement) in how services
can use certificates. But I also have a concern in using XML as an encoding
format for certificates. In every instance of XML "enabled" services I've
seen the processes tend to be very inefficient. The move should be toward a
greater efficiency in the handling of certificates. The long term future of
XML (or it's replacement) may resolve this, but as end-entity devices are
demanding greater efficiency the concern should be against bloating the
certificate.

JohnDavid

Dr. JohnDavid Hascup
Senior Security Architect
ELF Technologies
Issaquah, WA
425-369-5200

After a year's research, one realizes that it could have been done in a
week.
[from Fifty Years of X-ray Diffraction]
- Sir William Henry Bragg, 1862-1942

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 8 Dec 2000 12:04:38 +0100

Resent, did never show up in the list.  Pardon if you already got it!

>  IMHO the main advantage of XML over ASN.1 for any of these PKI
> functions, including AC's, is the far greater number of developers who are
> fluent in XML as compared to ASN.1 with BER or DER.  Speaking as one of the
> relatively few who is more fluent in ASN.1 than XML, I know of no other
> reason why XML should be preferred for such uses.  However, since syntax
> difficulty may well have been one of the reasons why SMTP has become widely
> adopted while X.400 has not, this is not a trivial reason.

Tom,
If you have followed my (too) frequent postings on the subject you should know that
there are actually *two* reasons for ACs to use to XML.  The second reason is the lack
of protocol and CA support for a certificate of the AC type.   By using a self-contained
signed object like PKCS #7, or in the XML-world XMLDSIG, the term "attribute certificate"
can be replaced by "signed attribute container" and make the AC replacement belong to
the same league as signed purchase orders etc.  And use *identical* PKI support code.

Using schemes like S2ML, the currently missing AC PUSH support, is already available w.o.
changing a single bit in the underlying PKI systems, protocols and browsers!

Given these facts I am willing to bet on that PKIX-ACs will be virtually insignificant.
Anyone interested in challenging this???

Anders

---

From: Philip Hallam-Baker <[email-masked]>
Date: Fri, 8 Dec 2000 14:45:10 -0800

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:[email-masked]]
> Sent: Thursday, December 07, 2000 9:32 AM
> To: Anders Rundgren; Stephen Kent; [email-masked]; 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
>

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 9 Dec 2000 08:17:42 +0100

>The two contending standards start fresh, with a lead of roughly one year for the
> binary versions.  I don't think that S2ML or XMLDSIG are so mature that
> they wipe out the lead CMS has - and please remember, this is not prejudice
> against XMLDSIG.

Tom,
We are both speculating but we don't come to the same conclusion.

The AC+CMS thing is ready on paper, while XMLDSIG is not.

Now, I am more a believer in marketing than in technicalities (well, things must work
of course), so therefore I suspect that the lead will be reversed before the ink has dried on
the AC RFC.  At least if we count the number of projects involved, money raised and
general company support.  Not to mention media headlines :-) 

Anders