Subject: RE: ASN.1 vs XML (used to be RE: I-D ACTION:draft-ietf-pkix-scvp- 00.txt)

From: Alan Lloyd <[email-masked]>
Date: Fri, 16 Jul 1999 05:17:40 +1000

Apologies Todd - I did not cover all the issues.

X.509 certs and crls did come from X.500 as a signed attributes (because
they are part of directory enries), therefore cryptographic bit string
integrity is necessary in cert and crl representation. In addition they
are complex attributes and because one should be able to search on
components of them (such as Issuer Name and Validity, etc) then each
component attribute must have a type and syntax definition formally
applied. In addition matching rules for component matching must also be
defined so that directory system implementors can actually engineer the
search processing algorithms for these complex attributes.

If XML wants to define certs and crls, the types, crypto, syntaxes,
matching rules for these need to be defined also. In addition - the PKI
vendors and businesss that use these "two" formats for PKI use - have to
understand what machines do with two formats, and when one or the other
or both are applied..

It is wrong to say we can have other formats just because of fashion..
when the implications of multiple formats on operations,
validation/revocation and issueance, all have to be dealt with  and
costed and profiled

regards alan

----------
From: [email-masked]
To: Alan Lloyd; ''PKIX-List' '; 'Andrew Probert '
Sent: 7/14/99 3:06:03 AM
Subject: Re: ASN.1 vs XML (used to be RE: I-D
ACTION:draft-ietf-pkix-scvp- 00.txt)

----- Original Message -----
From: Alan Lloyd <[email-masked]>
To: ''PKIX-List' ' <[email-masked]>; 'Andrew Probert '
<[email-masked]>
Sent: Tuesday, July 13, 1999 8:01 AM
Subject: RE: ASN.1 vs XML (used to be RE: I-D
ACTION:draft-ietf-pkix-scvp-
00.txt)

> Andrew - stop being so direct :-)
>
> What we need to do is support a ASN.1 replacement program for
> SNMP, PKCS standards, traffic management standards and onboard
> equipment, financial standards, Defence standards, OCSP, LDAP, X.500
and
> LDAP objects, etc, etc  and redefine all the object identifiers in the
> world as their syntax would change - as the format of these  are
defined
> in the ASN.1 standard...Thats all :-)

I want to be clear about what I was saying by way of XML v. ASN.1; I
dont
think that XML is 'better' than ASN.1 for representing the cert in, but
I do
think that there is no reason that an XML representation of the cert
structure is also not an issue. The cert structure is the cert structure
and
who cares what it is represented in. The fact that ASN.1 is the
'official'
language and syntax used to represent ISO models is neat and spiffy, but
the
fact that the industry is gravitating towards using XML is another big
reason that cert formats should be recognized as being representation
independent.

>
> I get the impression this thread is based on the issue that a
> certificate format is better in XML rather than ASN.1 - rather than
the
> knowledge that ASN.1 represents the Presentation layer of the OSI
> reference model in that it maps internal application layer structures
in
> C, etc (the internal syntax) to the transfer syntax TLV system  (ASN.1
> BER/DER) via the production of code/definitions derived from an ASN.1
> compiler using the input of ASN.1 definitions ... as provided in the
> respective standards. Standard which relate to the development of
> distributed applications.
>
>
> Perhaps some reading on the application of ASN.1 as a distributed
> information systems tool and the application of Object Identifiers for
> protocol and information and where this approach to systems is used
> might sway the decision here..

No, there is no need IMHO (not that I was ever humble...)..

The sheer fact of what XML is and the position it has within the IETF
and
other standards orgs, plus the growing number of tools that use it, I
think
that to shut it out and say that certs are ASN.1 is just a bit
shortsided.

> regards alan

Todd

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 15 Jul 1999 00:54:08 +0200

All,

We are now ready to prepare the next draft after the PKIX meeting in Oslo.
No objections to the presented solutions was raised in Oslo, which includes
keeping the current name of the document.

I have prepared the updated text, including all OID:s assigned for the draft.
Tim will finalize the document mainly by updating the ASN.1 sections and
adding an example certificate.

If anyone wish to examine the present text before the next I-D release, it
can be obtained from:

http://www.accurata.se/QC/documents/draft-ietf-pkix-qc-01prel_07.txt

The next draft will, according to plan, be submitted at latest August 6.
After that we think we are ready for last call.

All contributions, check for errors and unclear descriptions are highly
welcomed.

/Stefan