Subject: RE: Should PKIX protocols support XML well?

From: Michael Zolotarev <[email-masked]>
Date: Mon, 20 Nov 2000 11:27:51 +1100

Anders,

Let me try to help all us, by asking once again to stop comparing oranges
and apples. Or I just cannot help myself not to mention my favorite "how to
use a spanner to hammer a screw into a brick wall".

ASN is not a replacement for hi-level EDI definitions. It is not, and has
been never meant to be used in purchase orders, or legal claims, or birthday
postcards dispatch notifications. The use of ASN1 is bound to a *wide* range
of environments where the scope is limited to a set of known and easily
categorizable (not sure there is such a word, though) cases. Like protocols
and PDU definitions.

You should not be saying that "XML is better then ASN1 because it suits some
environments better", referencing environments that don't use ASN1 anyway.
This argument doesn't serve the current discussion well. I suggest we
concentrate on 'XML vs ASN1' for the domains where ASN1 is dominant now, or
is currently anticipated to be used. Otherwise there is nothing to argue
about - that'd be just stupid to push ASN1 into the areas where the
advantages of XML are well recognised. Wise versa? That's a question to be
resolved.

And hopefully, once we define common grounds for the arguments, and
recognise that every approach has its rights and justifications, the whole
discussion will be reduced to just defining the boundaries. And
responsibilities.

Regards
M

> -----Original Message-----
> From: Anders Rundgren [mailto:[email-masked]]
> Sent: Friday, 17 November 2000 20:32
> To: Stephen Kent
> Cc: Michael Zolotarev; PKIX-List
> Subject: Re: Should PKIX protocols support XML well?
> 
> 
> Here comes a major reason why ASN.1 did not make it as an 
> EDI-replacent
> (unlike) XML.
> 
>         RoleSyntax ::= SEQUENCE {
>                 roleAuthority   [0] GeneralNames OPTIONAL,
>                 roleName        [1] GeneralName
>         }
> 
> 
>       name      id-at-role
>       OID       { id-at 72 }
>       syntax    RoleSyntax
>       values:   Multiple allowed
> 
> I.e. this connection between a structure (in the commercial 
> world defined by customers)
> and an OID is based on an issued (requested) unique OID.  
> There is no other programming
> language in the world that requires such measures.  This is 
> 100% Ok for (a limited set of)
> globally/widly recognizable things but totally useless for 
> doing more or less local definitions.
> 
> A Purchase Order in ASN.1 could require 20 _carefully 
> managed_ OIDs while the same could be achived
> with a _single_ schema (=single registration).
> 
> Note that schemas can _also_ support globally valid 
> definitions with same "precision"
> as OIDs!
> 
> I.e. except for the storage factor there is nothing that 
> would make an XML-cert profile any
> less useful (or less trustworthy) than a X509 ditto.
> 
> Anders
>

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 20 Nov 2000 08:31:14 +0100

Michael,

> use a spanner to hammer a screw into a brick wall".

I don't think all (even in this list) think of ASN.1 vs XML, or ASN.1 vs EDI as comparing oranges
and apples.  Basically all three the offer a way to structure data objects. 

To be honest, I don't think that this discussion should be done purely on technical grounds
as it actually belongs to the same leage as

 - Is Socialism better than Capitalism?
 - Is Islam better than Christianty?
 - or really heavy stuff such as:  Is Britney Spears cuter than Christina Aguilera?

So if we must come to the conclusion which is best of ASN.1 or XML we will get nowhere as
the definition of "best" is not only a technical question.  There is though a large body of people
that already have selected XML as their choice and they want to get something done now.

I.e. the ONLY question left is (still) the subject of this message:

========================================================
Should PKIX support XML, or is the proper way to go ahead with PKIXML WG?
========================================================

According to the PKIX chair, the latter is the way to go.

Anders

---

From: Nada Kapidzic Cicovic <[email-masked]>
Date: Mon, 20 Nov 2000 11:06:41 +0100

>and apples.  Basically all three the offer a way to structure data objects.

Anders, I agree with Michael on this issue.

>I.e. the ONLY question left is (still) the subject of this message:

Have you not agreed with my last mail that PKCs should stay defined in 
ASN.1/DER as they are?

Most of the discussions so far on the list was regarding ACs and possibly 
some kind of remote certificate path building and verification protocols 
being encoded in XML, so that non-ASN.1 aware clients can still use 
existing PKI infrastructures.  This is _not_ the whole PKIX, but a small 
subset of it. That is exactly what Michael referred to as apples vs. oranges.

You are asking the wrong and too general question. It is not a question 
whether "whole PKIX should support XML". Would you re-define CMP and CMC to 
use XML? I suppose not.

Even if you decide to go with a separate WG it should not be called PKIXML, 
since, in my opinion, it should not cover the whole work of PKIX, but only 
a small subset. The name PKIXML implies replacing ASN.1 with XML for 
everything, and that would be wrong and probably not very productive.

Nada

>According to the PKIX chair, the latter is the way to go.

______________________________________________________________

Nada Kapidzic Cicovic, Ph.D.
Technical Director,   Entegrity Solutions
office: + 46 8 477 77 37,   cell: + 46 70 495 09 03,    fax: + 46 8 477 77 31

---

From: "Anders Rundgren" <[email-masked]>
Date: Mon, 20 Nov 2000 13:08:00 +0100

Nada,

> everything, and that would be wrong and probably not very productive.

PKIXML should be translated as "PKI with XML-flavor" which can be as narrow
or wide as the _MEMBERS_ want it to be.  If there is considerable
support for XML PKCs - let there be one.  I don't think that there should be any kind of restriction
on the scope (except PKI and XML), and regarding PKIXML's relation to ASN.1 it is so far
not specified at all.

MY interest in this is just to get the ball rolling and maybe participate in forming a new WG. 
It may though turn out that W3C is a better place to be in, as they actually "host" the core of all other
XML technologies.

> Have you not agreed with my last mail that PKCs should stay defined in 

Yes.  But PKCs are already defined and need AFAIK no further work.
 
> subset of it. That is exactly what Michael referred to as apples vs. oranges.

Ok, I did not interprete Michael in that way.  If all new exciting stuff including ACs effectively become
represented in XML the scope grows from "a small subset" to "mainstream".

Lets say that PKCs starts to be represented in XML as ASN.1 <=> XML element-by-element
compatible data .  Some day RP SW will stop convert back and forth and only work at the XML
level.  If the push in XML persists, this is bound to happen, it is just when that is the question.
And in "the next round" the PKC itself _could_ actually be redefined from scratch in XML.
And even further down the road, ASN.1 PKC support is no longer "standard"!

Note: I am not _advocating_ this, I am merely pointing to what I have seen happening in other
sectors. Over and over again.  EDI vs XML, IPX vs IP, Command-line vs GUI, Leased lines
vs Internet, etc , etc, etc,  

> whether "whole PKIX should support XML". Would you re-define CMP and CMC to 

Actually I have no idea on that at this point.  It could happen once the ball gets rolling.
A pure market decision IMO.   If these protocols (which I know rather little about)
have a wide usage, they could be _candidates_ at least.

For a company like yours (Entegrity), it could be important to actually jump on the
XML PKI bandwagon if only for marketing reasons. I guess you saw that Warwick
Ford of VeriSign supported a variant of XML ACs (S2ML).  

Anders

---

From: "Peter Lipp" <[email-masked]>
Date: Mon, 20 Nov 2000 14:21:42 +0100

Anders,

>It may though turn out that W3C is a better place to be in, as they
actually "host" the core of all other
As I already mentioned, a joint WG would be optimal - to bring in experts
from both sides. I'll ask in the XML-DSig-list what they think...

Peter