Subject: Re: Should PKIX protocols support XML well?

From: [email-masked] (Peter Gutmann)
Date: Thu, 16 Nov 2000 07:05:44 (NZDT)

[email-masked] writes:

>When building the Jonah freeware we put together an ASN.1 class library that
>supports almost all of the features you claim as intrinsic virtues of XML:

I'll add my $0.06 (the NZ$ isn't worth a lot at the moment) to this as well...

>>- Immediately recognize the message type by its schema name as found
>>  by the parser. You could even dispatch the parsed message to
>>  various apps directly based on found message type!
>>  Schema=>Application=>Implict semantics.

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

>>- Have the parser automatically check that all expected elements are
>>  there (no more, no less), and fully conform to their format and
>>  possible restrictions (i.e. not 100K UserIDs etc.)  Supporting
>>  standardized diagnostics like: "Address" field too long.
>>  Missing "Session ID" tag etc.

>The Jonah ASN.1 library doesn't do much checking of restrictions, but that was
>an implementation choice rather than something imposed upon us by ASN.1.

Doing strict checking is a downside, not a feature.  In my code I originally
did strict checking for compliance to RFC 2459, but found that there were so
many certs which fail the checks that I probably spent more time adding
special-case code to handle exceptions than in writing the cert-parsing code (I
remember posting a rant to this list some time ago where I noted that of 11
certs grabbed off the net, 10 failed to verify using the RFC 2459
requirements).  Even now I'm still finding lots of certs from newly-appearing
CAs which don't comply with RFC 2459.  When you distribute this per-cert
failure rate over entire chains, the one thing which checking that each cert
"fully conform[s] to their format and possible restrictions" will do is result
in about 90% of cert chains not verifying any more.  In the end you have two
choices, perform strict checking and have your code (in the eyes of the user)
fail for large numbers of certs, or accept any old rubbish and have it appear
to work.  I know which any company with commercial considerations will choose.

>>- Have "wizards" generate access class objects directly from the XML
>>  app-schema if you want.

>Jonah doesn't have wizards; instead you simply declare a C++ class of the
>appropriate type directly from the ASN.1 syntax definition.  

I have something similar, except that you use a simple notation based on the
ASN.1 syntax.  In fact I would imagine that every implementation uses some sort
of automated generation process, I can't imagine anyone is still hand-coding
ASN.1.

>The above isn't intended as a plug for the Jonah code;  It's simply an
>existence proof that the advantages you claim for XML are also achievable by
>ASN.1 (and in freeware too).

Ditto.  Although it's cool to claim that XML invented all of this, it was being
done decades before anyone had ever heard of XML (in EDI/X.12/etc - maybe we
should all use EDI for this if the features touted for XML are so wonderful).
This stuff is hardly rocket science, just because XML is what they're wearing
in Paris this year doesn't mean we should throw away years of experience and
implementation work to chase the latest fad which comes along.

Peter.

---

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

Peter Gutmann wrote:
> >>  by the parser.

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: "Phillip H. Griffin" <[email-masked]>
Date: Thu, 16 Nov 2000 06:55:18 -0500

Peter Gutmann wrote (in part):
> 
> [email-masked] writes (partially):
> 

snip

> special-case code to handle exceptions than in writing the cert-parsing code (I

Certainly the only sane approach to decoding. And
not getting hung up on enforcing DER restrictions
on BER is a good idea, too. 

Enforcing constraints and restrictions is best left
to encoding, where you might want to be careful in 
what values you send to others. But even encoding 
enforcement is sometimes best relaxed, leaving this
to the underlying application code. 

ASN.1 only defines what should be on the line, not 
how it gets there.

Phil

---

From: Paul Koning <[email-masked]>
Date: Thu, 16 Nov 2000 09:47:58 -0500 (EST)

>>>>> "Phillip" == Phillip H Griffin <[email-masked]> writes:

 >>  [email-masked] writes (partially):

 Phillip> snip

 >> >The Jonah ASN.1 library doesn't do much checking of restrictions,
 >> but that was >an implementation choice rather than something
 >> imposed upon us by ASN.1.
 >> 
 >> Doing strict checking is a downside, not a feature.  In my code I
 >> originally did strict checking for compliance to RFC 2459, but
 >> found that there were so many certs which fail the checks that I
 >> probably spent more time adding special-case code to handle
 >> exceptions than in writing the cert-parsing code (I

 Phillip> Certainly the only sane approach to decoding. And not
 Phillip> getting hung up on enforcing DER restrictions on BER is a
 Phillip> good idea, too.

Absolutely.  This is the classic rule "be strict in what you send,
lenient in what you receive."

If the meaning of a received message is clear, pedantically enforcing
encoding rules is only harmful.  It reduces interoperability and it
consumes resources to no benefit.

(Hm, do I sound like a Florida lawyer here?  :-) )

     paul

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Nov 2000 19:07:27 -0500

Sorry guys, but I must disagree.  Peter's lenient decoder is 
appropriate for determining what's wrong with a wide range of 
non-compliant certs, but it's a bad idea for any production system. 
User's (and sys admins) are ill-prepared to deal with the complex 
error indications that would arise if one reported what was wrong 
with non-compliant certs and CRLs. if you don't report the errors, 
they the designer of this "accommodating" software is making value 
judgements about what might or might not be important. One is also 
encouraging non-compliance, rather than providing feedback to vendors 
who don't get it right.

Steve

---

From: Michael Ströder <[email-masked]>
Date: Fri, 17 Nov 2000 07:55:40 +0100

> 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.
2. You might get unexpected and unsecure behaviour of your own
application when accepting certificates not compliant to PKIX specs.

Ciao, Michael.