Subject: Re: Should PKIX protocols support XML well?

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

David,
(sorry for snippet of private mail but this one has a larger interest)

> What you ascribe to the XML profile is exactly how X.509 v3 certificates
> work.  The body of the certificate is the "generic header", and extensions
> include generic capabilities (defined in X.509 itself), community
> capabilities (the AIA and SIA extensions defined in RFC 2459 but not in
> X.509), and local extensions which don't need to be published anywhere,
> all they need is an OID assigned to the organization that created (wrote
> the ASN.1 type definition of) the extension.

The OID-stuff  is AFAIK much more complicated (=error-prone) to administer than to
agree on a schema name space and accompanying tags.

That alone, seems to justify turning to XML for things like ACs that may proliferate
in a way that PKCs didn't have to.  And OIDs lack a useful name unless the parser
is "taught" to understand them.  XML parsers dont have to be "educated".

Anders

---

From: Ed Gerck <[email-masked]>
Date: Wed, 15 Nov 2000 23:57:40 -0800

> is "taught" to understand them.  XML parsers dont have to be "educated".

This dialogue seems to be moving like angry ghosts, back and forth, but one
point seem to be missed.

ASN.1 and OIDs are based on hierarchical design rules, central control.  XML is
based on local control. Both control paradigms are useful but, in many cases,
central control beats local control hands down in terms of security.  Think of
a spy ring, for example -- local spies need to be "educated" by the spymaster
and there is no other way around.  This is well-recognized in the intelligence
community, where people learn that they cannot trust that which they cannot
control.  The Internet brings about the need for a different control paradigm, since
it presents cases where you need to trust that which you absolutely can never
control -- the other side of the communication channel, for example. Local control
won't cut it either because it does not solve the trust issue beyond the local
domain.  XML tags may mean different things to different people.

Since neither control paradigm can represent what the Internet needs, another
control paradigm will need to be introduced sooner or later.  I mentioned this
and provided examples some three years ago, using digital certificates as an
example. The study served also to identify several flaws caused both by the
central and the local control approaches when applied as certificate models.
The study is available in a new version at  http://www.mcg.org.br/cert.htm
and  http://www.thebell.net/papers/certover.pdf  and other mirrors.

Regarding PKIX, it would be useful to have both ASN.1 and XML IMO, and then
something else too.  Interoperation is the hallmark of a standard.

Cheers,

Ed Gerck

---

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

Just to prove my point.

*outside* of this crummy list, Warwick Ford and others have no problems pushing XML
for purposes that look *very* similar to PKIX's.

http://www.netegrity.com/news/press_releases/dom/2000/press_release_11_15b_00.html

So what are we waiting on?  To get redundant? Obsolete?

Or give us a new WG!

Anders

---

From: Michael Ströder <[email-masked]>
Date: Thu, 16 Nov 2000 11:09:36 +0100

Ed Gerck wrote:
> based on local control.

Ed, OIDs are subject of local control either.

If you disagree please show me the mechanism how my application can
locate and download the machine-readable ASN.1 definition related to
an arbitrary OID.

Ciao, Michael.

---

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

Ed,

> but one point seem to be missed.
> central control beats local control hands down in terms of security.

XML schemas stored and maintained on a secure server run by a trusted party offers
the possibility to have central control.  Which makes sense for *some* apps.

OIDs are inherently less flexible. And need "educated" parsers.

An example: W2K CryptoAPI returns "OID.2.5.4.5=xyz" instead of "SerialNumber=xyz" so at
least MSFT has some "education" left to do...

Anders

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 16 Nov 2000 13:02:29 +0100

> the possibility to have central control.  Which makes sense for *some* apps.

I think there is a definitive risk of name collision of schemas on a large scale.

> least MSFT has some "education" left to do...

Sure. MSFT tools just seems to have no idea what the OID identified as "Microsoft
Commercial Code Signing" by other tools is.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 16 Nov 2000 11:03:20 +0100

> agree on a schema name space and accompanying tags.

Anders, I totally agree.

Ciao, Michael.

---

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

Jean-Marc,
 
> I think there is a definitive risk of name collision of schemas on a large scale.

Even If every person on this planet makes a billion schemas per day I can't see 
that name-space is global a problem.   Locally anything can happen of course.

I would worry much more about ambiguous uses of OIDs due to their huge numbers, 
ugly ("computer-friendly") look, and potential lack of local tracking. 

But actually, whatever you do, if you have a lousy methodology, you will end up in deep s**t 
sooner or later. 

/anders

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Nov 2000 18:38:32 -0500

Anders,

>So what are we waiting on?  To get redundant? Obsolete?

The IETF and PKIX have no monopoly on good ideas. But we do adopt 
scopes for WGs. I try to avoid duplicative efforts, something that 
colors our current OCSP vs. SCVP debate. Overall, the IETF has not 
been a diligent in this regard, in all areas.

On the other hand, just because a technology is new, has some 
attractive features, and is hyped, that does not make it a success 
nor a necessary successor to other technologies.  Java is nice, but 
it has not taken over as predicted. Then, there's WAP, for example.

As for starting a new WG,I thought I addressed this question already.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Nov 2000 18:35:25 -0500

Anders,

I am obviously ignorant of the means by which XML schemas are 
assigned globally unique names to avoid the collision problems 
alluded to in other messages. Coould you explain how that works?  Is 
it hierarchic like OID and DNS, or is it complete distributed and 
probabilistic in its collision avoidance, like some certificate 
serial number assignment schemes we've learned about?

We know how to manage OIDs, and we have considerable experience in 
doing it for several years. I presume that an XML approach to solving 
the problem has less of a track record, although that does not mean 
it may not become equally viable in the future.

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 17 Nov 2000 08:22:48 +0100

> it has not taken over as predicted. Then, there's WAP, for example.

Java has not "taken over" as you say but it is at least much more known, used
etc. than ASN.1 (at dev. level).  And the same is valid for XML although being
pretty new.

>As for starting a new WG,I thought I addressed this question already.

This is one way to do this.  Don't you see a risk of losing a lot of good people to
this new WG?  I think this question is of such magnitude that it requires a
*descision* from the chairs and the members.

Or do you expect the XML-PKI WG to consist of me an a few other "kinky" developers?
Why not try to estimate how many of current PKIX:ers that would put their main focus
in the new WG?

Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 17 Nov 2000 10:42:23 +0100

Steve,

> serial number assignment schemes we've learned about?

I would be a liar if I said that _I_ have the solution to name collisions but
if you build it on DNS-based URIs you at least have a sound foundation.  Then it is
not really a technical problem but an administrative one.   I am *sure* that there
will be name collísions but they will only occurr within an organization (=DNS-name) itself
If that organization is VISA, sorry, it is their problem not ours. In the same way as
CAs must keep track of what they do.

> doing it for several years.

Now you are addressing a core issue. If "we" becomes as I (but not you) assume, 
a wider definition than "a few IETF-hacks" the OID scheme will not look that good
anymore.  I am now talking about ACs and similar stuff (not PKCs) with a potentilly high
application-specific (customer-defined) content.

>I presume that an XML approach to solving 

The distributed approach (like CAs) cannot guarantee any track record,
it will be organization-specific.  Freedom has its price...
And a lot of people are prepared to pay for that.  In some way or another.

Anders

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 17 Nov 2000 11:31:50 +0100

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: Nada Kapidzic Cicovic <[email-masked]>
Date: Fri, 17 Nov 2000 15:28:39 +0100

>application-specific (customer-defined) content.

This is not the best approach in making standards. We are having problems 
with building inter-operable solutions with current uniquely identified 
structures. If we add ambiguity in their naming and identification, that 
will just add more deployment problems.

>And a lot of people are prepared to pay for that.  In some way or another.

Does this mean even if they end up having proprietary solutions? Why then 
making a standard in the first place? For very application specific 
customer defined parts we almost do not need standards. However, for PKCs I 
hope we all agree that we do.

Nada

---

From: Paul Koning <[email-masked]>
Date: Fri, 17 Nov 2000 09:38:33 -0500 (EST)

>>>>> "Anders" == Anders Rundgren <[email-masked]> writes:

 Anders> Here comes a major reason why ASN.1 did not make it as an
 Anders> EDI-replacent (unlike) XML.

 Anders>...

 Anders> I.e. this connection between a structure (in the commercial
 Anders> world defined by customers) and an OID is based on an issued
 Anders> (requested) unique OID.  There is no other programming
 Anders> language in the world that requires such measures.  This is
 Anders> 100% Ok for (a limited set of) globally/widly recognizable
 Anders> things but totally useless for doing more or less local
 Anders> definitions.

 Anders> A Purchase Order in ASN.1 could require 20 _carefully
 Anders> managed_ OIDs while the same could be achived with a _single_
 Anders> schema (=single registration).

I get the feeling you aren't familiar with Vendor MIBs in SNMP.  It is
perfectly straightforward to do "more or less local definitions".

In order to describe 20 different things, you need 20 carefully
managed handles to distinguish them.  That's going to be true no
matter what descriptive technology you use.  The only difference will
be in syntax and in the flexibility of how those handles are assigned.

With OIDs, if you need to define locally managed things, you get a
Vendor OID from IANA, then you put things underneath that.  No
Problem...

	paul

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 17 Nov 2000 16:43:54 +0100

Hi Nada,
Nice to see another Swede make it to the list!

> will just add more deployment problems.

To take it from the e-business sector: Standards can be as deep or as thin
as required by the target.  SOAP, BizTalk do not specify content, they specify
protocols and place-holders.  This make sense for same apps.  Then specific
messages are "standardized" (or not) depending on requirements.

For ACs (_____not_____ PKCs) I would like to enhance the container concept one step further.
But also switch to XML which is better suited for that purpose IMO (but not in some
others opinion).  To "standardize" the representation of _some_ attributes you know
of (like in AC), is like if Microsoft would try to define suitable elements in "Purchase Orders".
They did not.  And for a reason.  It does not work! 

Note: Not a _single_ person have claimed that they will create a _universal_ AC application (.EXE).

What does this say? That ACs really are _exactly_ as application-specific as I claim.

SW ,manufacturers will though provide frameworks, toolboxes etc.

Using XML schemas the framework will be hardly anything as it will re-use the XML parser
that is already in place.  I expect the framework to be standard as well.

> customer defined parts we almost do not need standards.

We need (or will get) a multi-level standard. At the top (IETF and others) we 
have basic technology. At the next step we have local, national, global, or 
community-based profiles of various dignity. 

>However, for PKCs I hope we all agree that we do. 

Agreed 1000000% ! Me exaggerate? 

PKCs, LDAP objects and CRLs, will probably continue to be _defined_ in ASN.1 _forever_. But they will also 
be represented in XML in as BASE64 and as XML<=>ASN.1 element-by-element compatible data. 

Regards
Anders

---

From: Ed Gerck <[email-masked]>
Date: Fri, 17 Nov 2000 12:02:09 -0800

> less useful (or less trustworthy) than a X509 ditto.

This reminds me of the Prolog wars in AI.  Is this WG really trying to block
XML-based X.509 certs on the basis that ASN.1 has some advantages in
terms of central control, while ignoring other advantages of XML?  Well,
this WG is supposed to be PKI with X.509, not PKIA, as PKI with ASN.1.

Can we form a group within this WG to look into PKI with X.509, but encoded
in XML?  Who knows, this may avoid us doing the same for PGP and actually
save us some work.

Cheers,

Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Tue, 28 Nov 2000 19:37:00 -0500

><snip>

Many of us manage to participate in multiple WGs in the IETF, 
although it is a time consuming task.  So, I don't fear that if a new 
WG were created to focus on XML PKI support that the drain would 
cripple the current PKIX work. if the extent of XML support is of the 
magnitude of what is proposed in SCVP, I don't think there is a need 
for a separate WG. However, if the intent is to create XML parallel 
syntax for all PKIX protocols, any maybe even to mandate support for 
that syntax in clients, CA, etc. then a separate WG, with a charter 
focused on that sort of work is the most appropriate way to proceed. 
Hope the clarification helps.

Steve

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 29 Nov 2000 09:22:08 +0100

Steve,

> Hope the clarification helps.

It does to some extent only as neither you and I know exactly what will be created
in the future as it depends on demand.

Long-term, I anticipate the entire X500 family to be XML-ized, short-term ACs
seem to be a good target as it is a type of item that requires fundamental changes
in client-platforms and CA-systems.  Which I BTW do not expect to happen as
solutions like my proprosed XML-AC, and S2ML build on the infrastructure that others
already are creating on top of existing PKI-systems.  I.e. e-commerce and banking
using XMLDSIG. 

Due to the fact that no mailing-list or BOF-session was granted, I probably will not go to San Diego.
But I intend to write a PKIXML WG charter proposal.

Talking about ACs: I have hard to see that ACs will be "issued" by CAs & RAs in the
usual sense, they will typically be created automatically on demand based on information
in various systems.  And distributed to the client's "PSD" or similar - Never.

Anders

---

From: Stephen Kent <[email-masked]>
Date: Wed, 29 Nov 2000 09:57:58 -0500

Anders,

>in various systems.  And distributed to the client's "PSD" or similar - Never.

That's one model, but I have seen and heard briefings on models that 
do call for authorities to create and distribute ACs that are managed 
in a way analogous to PKCs. There is a potential for more automation 
if existing ACLs exist from which to authorize issuance of ACs, since 
there often may not be a need for the procedural activities 
associated with initial user authentication as per PKCs. However, the 
AC issuance procedure may be equivalent to some PKC issuance 
procedures, i.e., ones where users are already known and have some 
form of online authentication capability.  Then the situation is 
exactly analogous to issuing an AC on demand based on a pre-existing 
ACL.

Steve