Subject: Re: Should PKIX protocols support XML well?

From: [email-masked]
Date: Thu, 16 Nov 2000 09:30:39 -0500

Michael,

>John, Peter, how does your code recognize any PKI-related object?
>IMHO you're doing some kind of type probing, don't you?

I can't speak for Peter's code, but the Jonah library allows you to define
objects that can parse and generate BER/DER according to a given ASN.1
syntax (they'll parse BER, and generate DER).  You can define an
"AllPKIXMessages" class which, in ASN.1 terms would be a CHOICE of all the
defined PKIX messages.  No coding is required (other than declaring a
CHOICE {} object).  For example, if you've already defined classes
PKIXMessage1, PKIXMessage2, and PKIXMessage3, your AllPKIXMessages class
would be defined:

class AllPKIXMessages : public asn_choice {
public:
  PKIXMessage1 m1;
  PKIXMessage2 m2;
  PKIXMessage3 m3;
  AllPKIXMessages() {
    register_child(&m1);
    register_child(&m2);
    register_child(&m3);
  };
}

Provided the individual messages are structurally distinct, an object of
this class will be able to parse (or generate) any of the messages.  This
works because (unlike ASN.1) the Jonah library doesn't insist on distinct
tags for the members of a CHOICE - they just have to be distinguishable
syntactically.

>In XML you can just determine the type by schema name. Isn't that
>much simpler?

Once you've used the above object to parse a message, you can ask it what
message type it read by calling its "selected()" member function which will
return 0 for a PKIXMessage1, 1 for a PKIXMessage2, etc.  You can't get much
simpler than that.

John

---------------

Michael Ströder <[email-masked]>@ms.inka.de on 11/16/2000 04:43:36 AM

Sent by:  [email-masked]

To:   [email-masked]
cc:
Subject:  Re: Should PKIX protocols support XML well?

Peter Gutmann wrote:
>
> [email-masked] writes:
>
> >>- Immediately recognize the message type by its schema name as found
> >>  by the parser.
>
> >The Jonah library can do that (recognize a message type either
implicitly by
> >its structure or explicitly by an embedded tag).
>
> My code does the same, throw any PKI-related object at it and it'll
recognise
> it automatically and process it as appropriate.

John, Peter, how does your code recognize any PKI-related object?
IMHO you're doing some kind of type probing, don't you?

In XML you can just determine the type by schema name. Isn't that
much simpler?

Ciao, Michael.

---

From: [email-masked]
Date: Thu, 16 Nov 2000 10:05:02 -0500

Anders,

>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...

I don't understand how you're measuring flexibility, but I disagree with
your comment about educated parsers.

It would be an extremely well-educated parser that could work out for
itself what to do with the ASCII string "SerialNumber".  I don't see why
such an intelligent piece of code should have any more trouble with the
three-byte OID value 2.5.4.5.

Or do you mean "human" (or more specifically "English-speaking human") when
you say "parser"?  If so, then yes, XML has a definite advantage if you
intend it to be consumed by humans.  But code doesn't understand ASCII (or
Unicode) any better than it understands hexadecimal values.

John

"Anders Rundgren" <[email-masked]> on 11/16/2000 06:49:09 AM

To:   "Ed Gerck" <[email-masked]>
cc:   "PKIX-List" <[email-masked]>, "David P. Kemp"
      <[email-masked]>
Subject:  Re: Should PKIX protocols support XML well?

Ed,

> 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.

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: "David P. Kemp" <[email-masked]>
Date: Thu, 16 Nov 2000 12:11:27 -0500 (EST)

> From: Michael Ströder <[email-masked]>
> 
> But in the case of an OID defining an ASN.1 syntax (widely used in
> PKIX) where can I automatically locate the syntax? You have to teach
> your application a-priori knowledge for simply verifiying the
> structure (not to mention all these more or less human-readable
> aliases for OIDs). With XML you can simply download e.g. a DTD from
> the URL in the XML data and use it to verify if the XML data is
> compliant to the schema.

With widely-used ASN.1 syntax the definition is expected to be stable
enough so that manually downloading an RFC from an FTP server and
importing a module into a library is considered adequate.  The manual
process only needs to be done once; then the library of standard
modules is available to all users of a particular package.  I assume
Jonah, Secude, OSS, OpenSSL, Cryptlib, and other packages all include
extensive ASN.1 libraries.

It hasn't been apparent that dynamically downloadable ASN.1 type
definitions are needed, and I'm not aware of a service that provides
them.  However, it would be trivial for someone to set up such a server
containing ASN.1 definitions, and include the server URL in attribute
certificates.  The application verifying an AC could query the server
for definitions of any attributes not defined in its local library,
e.g.  http://asn1-server.org/q?oid=1.3.6.1.5.5.7.10.1 to retrieve the
definition for authenticationInfo.

As Anders points out, this is theory, not practice.  But given the
triviality of putting it into practice, the current lack of
downloadable type definitions is not much of an argument against the
use of ASN.1 for attribute certificates.  Should we define a PKIX
type-server attribute now, just to get the ball rolling?

id-aca-typeServer  OBJECT IDENTIFIER ::= { id-aca 6 }   -- IA5String URI

---

From: Michael Zolotarev <[email-masked]>
Date: Fri, 17 Nov 2000 17:41:43 +1100

> With XML you can simply download e.g. a DTD from

And what after it? Does the application (knowing that the sctucture is Ok)
use the structure? If it does (why bother with verification otherwise?),
then the application must KNOW what's inside the structure, and pull the
values out of it. So that the XML application has to posess the same degree
of awareness of the actual content of the structure, as any other (ASN)
application. 
The only difference is: you parse already knowing that what you are parsing
is all right (XML), or you parse and validate at the same time (ASN).

XML certianly does have its advantages over ASN. But schemas-based
validation doesn't necessarily present a convincing argument, compared to
the ASN1's way of structure validation.

M

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 18 Nov 2000 07:56:20 (NZDT)

Michael StrM-vder <[email-masked]> writes:

>Paul Koning wrote:
>>Absolutely.  This is the classic rule "be strict in what you send,
>>lenient in what you receive."

>1. But if you are strict with what you receive you can influence other
>implementors to be compliant because they might try to test their
>implementations and data against your lib.

No, it has no effect at all.  The number of broken certificates has stayed more
or less constant in the three-odd years in which I've been maintaining the
X.509 style guide as new CAs and implementations appear, and it's really going
to explode if PKIs ever take off.  In addition you've got legacy certs and
chains with CAs with 20-year validity periods which will be around
(effectively) forever.  The problem of broken certs will never go away, and
it's not getting any better either.

>2. You might get unexpected and unsecure behaviour of your own application
>when accepting certificates not compliant to PKIX specs.

Sure, but when users come to you and say "Your code is broken, it doesn't
accept this cert" and you tell them "Well actually the cert doesn't comply with
section 4, subsection 2, paragraph 4, clause 8(b) of RFC 2459" they'll just
find a vendor whose code doesn't reject the cert (this is one reason why I went
and back-patched my code to accept all sorts of rubbish, because if you present
users with a safety warning they'll respond by disabling the warning or finding
something which doesn't warn them).

Peter.