Subject: RE: Should PKIX protocols support XML well

From: Ambarish Malpani <[email-masked]>
Date: Thu, 16 Nov 2000 07:28:07 -0800

Hi Denis,
    No arguments with your statement that ASN.1 is more compact
than XML. However, as applications start doing more and more with
XML, they also invent mechanisms to store the XML in a way that they
prefer to work with (for example, in our Receipt product line, we
have a mechanism to store the XML in a relational database). Once
people have done this, they would prefer to have XML as their data
format for everything, rather than storing a base64 blob of ASN.1
in their database that they need to write special code to view.

The basic observation is that applications normally have a preferred
format for data. If an application is doing everything in XML, that
is likely to be their prefered format and they are likely to want
their certificate validation protocol to be in that format, rather
than another one.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Tuesday, November 14, 2000 6:27 AM
> To: Ambarish Malpani
> Cc: [email-masked] '
> Subject: Re: Should PKIX protocols support XML well
> 
> 
> Ambarish,
> 
> > Hi Steve/Russ,
> >     I hope nothing that I posted even implied that I recommend that
> > certs and CRLs be encoded in XML. I think there is enough investment
> > in ASN.1 certs/CRLs etc. to not make it a worthwhile effort. The
> > remark I was trying to make is that I think future PKIX work should
> > try and see if specifying protocols in XML or both XML and ASN.1
> > make sense for the task they are trying to do.
> > 
> >     This is precisely why I tried to specify SCVP in both syntaxes.
> 
> Let me jump into this discussion. ASN.1 has been used 
> historically to define
> *protocols*. Since such protocols were carrying data 
> structures that could
> have their own existence outside their transmission in the 
> protocols, we
> ended up with ASN.1 for *data structures*. The prime examples are
> certificates and CRLs.
> 
> The basic question is thus NOT whether we should specify new 
> protocols in
> ASN.1, XML or both XML and ASN.1, but rather whether we want 
> to define NEW
> data structures in XML or ASN.1. As an example, an OCSP 
> response is an ASN.1
> data structure that has an existence beyond its transmission in the
> protocol, since it can be stored and re-used to make sure, 
> e.g., it was
> correctly signed. 
> 
> The basic question is thus the following : should new data structures,
> signed by an authority, which would vouch for the validity 
> (they are various
> flavors around that term) of a certificate or certificate 
> chain against some
> rules be defined in ASN.1 and/or XML ?
> 
> Let me just provide one first argument: ASN.1 is much more 
> compact than XML.
> There are other arguments indeed. You are welcome to provide them.
> 
> Denis
>  
> > Regards,
> > Ambarish
> > 
> > 
> ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                
> 650.567.5457
> > ValiCert, Inc.                                  
> [email-masked]
> > 339 N. Bernardo Ave.                          
> http://www.valicert.com
> > Mountain View, CA 94043
> > 
> > > -----Original Message-----
> > > From: Stephen Kent [mailto:[email-masked]]
> > > Sent: Monday, November 13, 2000 11:04 AM
> > > To: Ambarish Malpani
> > > Cc: [email-masked] '
> > > Subject: Re: Should PKIX protocols support XML well
> > >
> > >
> > > Ambarish,
> > >
> > > XML has various benefits for representing certain kinds 
> of data, but
> > > none of those seem especially relevant to the encoding of certs or
> > > CRLs. Moreover, at a time when people in various quarters (e.g.,
> > > wireless folks) complain about the size of certs, it 
> would not seem
> > > especially appropriate to adopt an XML encoding, which 
> would increase
> > > the size of these data items.
> > >
> > > I am not persuaded by comments that allude only to the 
> "trendiness"
> > > of XML vs. ASN.1 encoding, as several others have pointed 
> out. PKIX
> > > was started as a profiler of X.509 protocols, and we have expanded
> > > our charter to create new protocols that support X.509 certs and
> > > which seem appropriate to PKI use in the Internet. That 
> makes it hard
> > > to justify developing new syntax for existing data structures, as
> > > noted above.  However, as Russ pointed out, standards for 
> carriage of
> > > certs and CRLs (ASN.1 encoded) in an XML context are not 
> out of the
> > > question.
> > >
> > > Steve
> > >
> > 
> > ----------------Russ's Original Message-------------
> > Ambarish:
> > 
> > I agree that we need to support XML clients.  It would not 
> have been one of
> > my three criteria if I thought otherwise.  However, I do 
> not think that we
> > should abandon ASN.1.  I think that certificates and CRLs 
> MUST be ASN.1
> > encoded.  Providing an XML wrapper to carry an 
> ASN.1-encoded blob is just
> > fine.  Base64-encode it if you like.  Anyway, the server 
> can obtain the
> > ASN.1-encode certificate perform validation services.  The 
> server will
> > return an indication of validity and parse some information 
> (especially the
> > public key, alt names, and critical extension information) from the
> > certificate.  This will allow the client to be completely 
> ASN.1 ignorant.
> > 
> > I realize that this is just one aspect of making the entire 
> system XML
> > client friendly; however, I think that it is a very 
> reasonable place to
> > begin.  In many systems, enrollment is handled by issuing a 
> token (such as
> > a smart card).  In this case, the client has nothing to do with
> > enrollment.  So, certificate validation is a good place to begin.
> > 
> > Russ
> > -------------End of Message----------------------------
>

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 16 Nov 2000 16:39:20 +0100

Ambarish,

> their certificate validation protocol to be in that format, rather

This is absolutely correct.  So what do we do now to create this exciting new
XML-based PKI stuff?  Create a new WG?  Any suggestions?

I personally do *not* believe ín creating dual track standards, as that would be a terrible
wast of talent and resources.

Anders

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 16 Nov 2000 17:33:04 +0100

> wast of talent and resources.

It has been proposed that a XER (XML encoding rule) be defined.

In fact I think it's even feasible to write a standard that can converts an ASN.1 definition,
with incorporated constraints, to an equivalent DTD and schema.

Together with a normalised XML representation, a document created using this DTD and schema
would be the XER representation of the ASN.1, and could be created using standard XML tools
that understands DTD/schema.

We can have a convertion rule from OIDs to URI : for example as simple as "oid:1.3.6.1.5.5.7".

The waste of ressources would be terribly reduced, because the standards themselves would be
_not_ have to be rewritten if you want to do things in XML.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 16 Nov 2000 17:49:16 +0100

Ambarish,

> than XML. 

:-)

So for long term storage, I would favor ASN.1.

> However, as applications start doing more and more with

The point I made was specific to the storage of some signed data, like a
certificate, a CRL or an OCSP response. No other type of data.

> format for data. 

Many applications usually prefer C ++, because it is what they are made
from. (C ++ is only an example - please, no war with C or ADA)

> If an application is doing everything in XML, that

I could argue the same for ASN.1, but this is NOT the point. Let us use an
example:

At the time an XML application receives an OCSP response, it "sees" it in
C ++ (because it is translated from ASN1 into C ++ data structures).

At the time an XML application would like to see again the content of an
OCSP response (which was in ASN.1), it could send the blob to a local
application (originally developped in ASN.1) which will respond by sending
an ASN.1 copy of the blob, ... magically translated into C ++. As an end
result XML applications and XML programmers only see C ++.  :-)

Instead of asking the server to provide two sets of responses (i.e. one in
ASN.1 and one in XML), a single response could be provided (ASN.1).
[I already hear people saying XML, but remember the first argument, XML is
far less compact]. This response could be translated, NOT into XML, but
into the programming language being used (e.g. C or C ++).

So the request would contain the ASN.1 blob, while the response would be in
C ++. Quite a simple service. This approach could be generalized for
certificates (both public key certificates and attribute certificates), CRLs
and OCSP responses, as well as for new signed data structures.

The next question is how to verify years later such a structure. Well, this
may be quite complex and subcontracting the work to a server would be wise.
Light clients would use some new protocols, they could be in ASN.1 for
compactness, since anyway, what remains visible is the programming langage.

Is it a crazy idea ?

Denis

Note: I am not an ASN.1 compiler vendor. :-)

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 16 Nov 2000 20:11:47 +0100

Jean-Marc et al.

> _not_ have to be rewritten if you want to do things in XML.

Although all you say is technically correct, the "truth" (dangerous stuff),  is that writing ASN.1
and defining OIDs is something that is "hard to market" and will limit audience to a set of "gurus".
This would be bad if we anticipate end-user-community profiling of some magnitude. I do at least.

If our goal is to make PKI popular and useful, we should try to become compatible with the rest of the
"e-world" which is leaving EDI (in spite of being used for 20 years or so), and proprietary systems in favor of XML.
I.e. PKIX should not bother about ASN.1 <-> XML conversions except for firmly rooted things like
PKCs and CRLs.  For new  protocols and structures we should IMO *only* target XML.

But as there is no chance of reaching consensus on that (the EDI to XML "conversion process" is
likely to take 5-7 years or so to give you a hint of what we are dealing with), it may be easier to
move PKIX-like XML activities to a new WG?  Poll Time?

Regards
Anders Rundgren
co-founder, X-OBI AB

+46 70 - 627 74 37

---

From: "Peter Lipp" <[email-masked]>
Date: Thu, 16 Nov 2000 21:52:20 +0100

Denis,

>into the programming language being used (e.g. C or C ++).
That's what happens anyhow - at least in our implementation - when we parse
e.g. an ASN.1-structure. Well, it's a Java-Object, but thats conceptually
what you mean. I assume other ASN.1-software do the same. So do XML-parsers,
basically. And as you cannot transfer your "C or C++"-structure directly
over the wire, I don't see the point.

Peter

---

From: "Peter Lipp" <[email-masked]>
Date: Thu, 16 Nov 2000 22:12:19 +0100

Folks,

having read through all these opinions, I'd concede that everybody is right
to some extend. I understand that many don't see the need to define
XML-format for things were ASN.1-solutions are available or seem better
suited. There may be more hype in XML than it's worth, but with major
commitment into XML from folks like e.g. Microsoft and many others, this is
unlikely to end. Now, I see the following two points that IMHO will make
somebody come up with XML-schemas for close-to-everything that existed in
ASN.1:

Purity:

I see folks that see no point in mixing different ways to do basically the
same things, if not unavoidable. Technical reasons for that may be
discussable, comparing the additional cost of an ASN.1 parser compared to an
XML-parser. Still, I can imagine some who simply want that. Maybe because
they don't want to understand ASN.1 after having learned XML. And at some
point you can't avoid learning some of it.

"Religion":

There are folks that strongly dislike XML and others that strongly hate
ASN.1.

Assuming that I am right and somebody comes up with say XML-certificates, to
choose the extreme example, the open question is if these developments will
be relevant. Don't know. But does it hurt if we start such an activity in
advance before such things happen? Yes, it would acknowledge that XML was
important, and push away from ASN.1 towards XML, which obviously is not
something many here want to see happen, for whatever reason.

If a move into that direction was bad, then XML-Signatures were a bad move
in the first place - why not use CMS - and it still has happened, ETSI
201.733 / XML is under development and XML-encryption is on its way. So,
lets go for it!

An open question to me is where it should happen. Either a new WG - joint WG
with W3C seems optimal - or maybe XMLDsig can take over?

>Poll Time?
I wonder if that's meaningful - in this WG :-) - but why not. Count this as
PRO.

Peter

---

From: "Phillip H. Griffin" <[email-masked]>
Date: Thu, 16 Nov 2000 15:19:31 -0500

Jean-Marc

XER work (and workable alternative solutions) have 
been and are being discussed on the [email-masked]
list. A NWI has been approved and work on ASN.1/XML
related issues is well underway. And it is not too 
late to influence or to get involved in this effort.

But XER is not really a relevant PKIX topic.

Phil