Subject: Re: Should PKIX protocols support XML well?

From: [email-masked]
Date: Thu, 16 Nov 2000 10:18:44 -0500

Michael,

OIDs are allocated in a hierarchichal, distributed fashion that guarantees
universal uniqueness.

There is no requirement that there be any ASN.1 definition "related to" a
given OID.  Many (most?) OIDs identify things other than syntaxes (for
example, many OIDs identify cryptographic algorithms).

John
-----------

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

Sent by:  [email-masked]

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

Ed Gerck wrote:
>
> ASN.1 and OIDs are based on hierarchical design rules, central control.
XML is
> 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: Michael Ströder <[email-masked]>
Date: Thu, 16 Nov 2000 17:19:04 +0100

> OIDs are allocated in a hierarchichal, distributed fashion that guarantees

Yes, I know.

> example, many OIDs identify cryptographic algorithms).

Yes, I know.

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.

Ciao, Michael.

---

From: Eric Murray <[email-masked]>
Date: Thu, 16 Nov 2000 09:05:25 -0800

> the URL in the XML data and use it to verify if the XML data is

That sounds like a security problem.  An attacker could modify
the DTD that you download.   So you need to either verify the
integrity of the DTD, or authenticate its source, or both.

With what?

If all your cert-processing is in XML and needs DTDs, you've painted
yourself into a corner.  You would have no way of verifying the DTDs that
you need to verify the DTD.   There is going to have to be some sort
of a priori knowledge of on-the-wire formats required by the end entities--
they can't get it all from somewhere else.    No matter if you use XML
or ASN.1 or ad-hoc formats like SSL/TLS or SSH use.

Adding the download of the schema (after the EE's verfied it and the source)
adds another point of failure.   Depending on the security model of
the system in question, this could be a problem.

On a different sub-issue of the ASN.1 vs. XML: ASN.1 has two purposes-
one is to, along with an encoding mechanisim like BER or DER, define the
on-the-wire protocol.  The other is to provide a human-readable grammar
for describing the protocol, which is what's published into specs.
XML tries to do both at once, by making the on-the-wire protocol be the
human readable definition.  I submit that it's harder to read than ASN.1
grammar is, especially older ASN.1.

If XML follows the evolution that HTML has followed in the past six
years, it will only get harder to read.  A grammar that's hard to read
and understand results in specs with hidden flaws.  Anything that's
proposed as a grammar for describing protocols in specs should address
the readability issue.

-- 
  Eric Murray           Consulting Security Architect         SecureDesign LLC
  http://www.securedesignllc.com                            PGP keyid:E03F65E5

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 16 Nov 2000 18:30:27 +0100

Michael Ströder wrote:

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

Michael, you don't seem to realize that it's very difficult for many peoples to
define an URL that is garanted to be persistent.

What do you do the day the compagny changes domain name, or decides to
reorganize it's html server tree ?
In the world I live in, this happens all the time and destroys thousands of
links without pity.
How does it miraculously never happen for XML when it happens all the time for
HTML ?
It won't just because it's so bad for XML ?
No one will be that stupid ? I don't bet on people's stupidity.

I believe the W3C can handle really persistent link, Netscape probably can too,
I not convinced Microsoft will prove to be able to, and many smaller player will
be completely unable to do it.

And when you use a local name instead of an URL, you become very collision prone
if it's not choosen carefully, wich is fully between the hands of the XML
document designer, wich will not be always so capable.

Therefore I'm _not_ convinced this system is such a great idea and something you
must so proud of.
This is very probably not the strongest point of XML.

In fact, in we were changing from ASN1 to XML, I'd suggest to use instead URI of
the form "oid:1.3.6.1.5.5.7" and have a level of indirection that is able to get
the document from it's oid when it's a public document or to have it stored
locally to solve security problems.

Something as simple as add the following string (user configurable) to the OID
to do an HTTP request, and if the HTTP server answers with a redirection, follow
it, repeat process as long you get a redirection instead of authoritative answer
might work.
It could even be https links, so if you are confident in the first server, you
are sure the end result will be also correct.

I have already received an XML document where I did not have access to the DTD.
I just couldn't even open it with the XML tool I had. It was very fun :-(.

---

From: Michael Ströder <[email-masked]>
Date: Thu, 16 Nov 2000 19:08:29 +0100

Jean-Marc Desperrier wrote:
> Michael, you don't seem to realize that it's very difficult
> for many peoples to define an URL that is garanted to be persistent.

This very valid observation applies to every URI you store in
certificate extensions either.

Ciao, Michael.

---

From: Paul Koning <[email-masked]>
Date: Thu, 16 Nov 2000 13:57:41 -0500 (EST)

>>>>> "michael" == michael  <=?iso-8859-1?Q?Str=F6der?= <[email-masked]>> writes:

 michael> Jean-Marc Desperrier wrote:
 >>  Michael Ströder wrote:
 >> 
 >> > 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.
 >> 
 >> Michael, you don't seem to realize that it's very difficult for
 >> many peoples to define an URL that is garanted to be persistent.

 michael> This very valid observation applies to every URI you store
 michael> in certificate extensions either.

Absolutely.  It is important to realize that every URL in any stored
document was fairly likely to be valid around the time the document
was created -- and less and less likely to be valid the more time has
elapsed since then.

Therefore URLs should never be used as pointers to data that is
essential for the correct interpretation of the enclosing document.
They should only be used to point to data that is merely informative.

     paul

---

From: Aram Perez <[email-masked]>
Date: Thu, 16 Nov 2000 10:13:18 -0800

I think we need to do a manual recount of the ASN.1 vs. XML votes... ;-)

My dos centavos,
Aram Perez

---

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

>integrity of the DTD, or authenticate its source, or both.
Correct. But this is nothing new, its like the root-cert - you need to have
the basic DTD's and schemas to startup in you local trusted store.

Peter
____________________
Dr. Peter Lipp
IAIK, TU Graz
Inffeldgasse 16a
A-8010 Graz
Phone: +43 316 873 5513
Fax:   +43 316 873 5520
eMail: [email-masked]

---

From: Michael Ströder <[email-masked]>
Date: Thu, 16 Nov 2000 23:46:33 +0100

Paul Koning wrote:
>  >> > With XML you can simply download e.g. a DTD from the URL in
>  >>
> [..]

Hmm. Now when validating a certificate where to get the current CRL
from if not from the location e.g. defined by a persistent URL?

If there's consensus here that URLs are not persistent please throw
away uniformResourceIdentifier (and all other options) in
GeneralName out of RFC2459 so that implementors don't have to worry
about useless details.

Ah, maybe we can keep otherName... ;-)

   cRLDistributionPoints ::= {
        CRLDistPointsSyntax }

   CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF
DistributionPoint

   DistributionPoint ::= SEQUENCE {
        distributionPoint       [0]     DistributionPointName
OPTIONAL,
        reasons                 [1]     ReasonFlags OPTIONAL,
        cRLIssuer               [2]     GeneralNames OPTIONAL }

   GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

   GeneralName ::= CHOICE {
       otherName                       [0]     OtherName,
       rfc822Name                      [1]     IA5String,
       dNSName                         [2]     IA5String,
       x400Address                     [3]     ORAddress,
       directoryName                   [4]     Name,
       ediPartyName                    [5]     EDIPartyName,
       uniformResourceIdentifier       [6]     IA5String,
       iPAddress                       [7]     OCTET STRING,
       registeredID                    [8]     OBJECT IDENTIFIER}

Ciao, Michael.