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

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 09 Jul 1999 11:57:59 -0700

Could we defer this discussion, maybe for about a year? This is a serious 
request.

There is already an IETF WG that is looking at XML digital signatures 
(xmldigsig). Although XML certs are explicitly out of scope for that WG, 
they are also out of scope for the PKIX WG. My guess is that, if they can 
agree to an interoperable way of encoding signatures in XML, they will have 
done most of the work toward encoding certificates, and IETF momentum being 
what it is, I imagine they'll plod ahead into the cert realm before they 
shut themselves down.

I speak here as an early casualty of the XML wars (trying to encode simple 
things like vCards in XML). XML is prettier than ASN.1, and it works better 
with my favorite programming language (Perl). It is also still in a state 
of serious flux that even the XML gurus say has no clear resolution. I 
believe it is too early for almost anyone to be writing format standards 
with XML, because we will see big (and positve) changes in XML in a year or 
two.

We are not XML experts. Let's let those folks have a crack at the 
certificate problem. We have a lovely document full of semantics that we 
can offer to them as a starting point for their syntax explorations. Let's 
leave it at that for now.

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: [email-masked]
Date: Mon, 12 Jul 1999 10:37:42 -0400

I think two issues exist: certificates and protocols.

With regard to certificates, Steve makes a good point:

    don't try to stuff everything into a cert

If applications stopped stuffing application data into certificates, they
would not need to understand ASN.1 and DER. A precedent exists: public keys.
How many applications do you know that decode and parse
SubjectPublicKeyInfos. Most applications I know treat ASN.1-defined
DER-encoded SubjectPublicKeyInfos as opaque blobs and pass them to
cryptographic functions (e.g., BSAFE).

With regard to protocols, I do not see much value in using the lowest common
denominator. For example, I would argue against using XML to re-engineer the
next version of the Internet Protocol (IP).

Frank Balluffi
CertCo

-----Original Message-----
From: Michael Myers [mailto:[email-masked]]
Sent: Sunday, July 11, 1999 6:32 PM
To: Stephen Kent; Ben Laurie
Cc: PKIX-List
Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt

Steve,

Let us however lose sight of the fact that certificates provide a very
convenient vehicle for the transport of application-independant attributes.
One's purchasing authority or purchase authorization authority isn't and
shouldn't necessarily be restricted to a particular application context.  We
run the risk otherwise of re-inventing the equivalent of a PKI for each
application.

Mike

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]]
> Sent: Friday, July 09, 1999 7:11 AM
> To: Ben Laurie
> Cc: PKIX-List
> Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
> 
> 
> Folks,
> 
> I think we may be loosing trakc of some issues here.
> 
> 	- certificates are not the only option for passing around signed
> data.  many appications develop their own data structures 
> when then need to
> use signatures to ensure data origin authentication and connectionless
> integrity, or non-repudiation.  thus, the use of XML for various
> applications does not imply a need to use XML in 
> certificates.  don't try
> to stuff everything into a cert just because we have an 
> ability to do so
> via extensions.
> 
> 	- depending on the  context, Ben is right that one 
> might be able to
> avoid some of the issues that motivate the use of DER in 
> ASN.1. however,
> our experience with PEM development back in the late 80s 
> showed the need
> for canonical representations in other than just 
> certificates, with regard
> to signed data structures.  I disagree with Ben's comments re 
> DER.  while
> it is certainly true that people have made mistakes in 
> implementing DER, I
> think we are in pretty good shape these days and I'm not aware of any
> lingering issues now.
> 
> Steve
>

---

From: Michael Myers <[email-masked]>
Date: Tue, 13 Jul 1999 18:29:24 -0700

Steve,

I'll probably bring this point to your attention on the floor before you
read this email, but for the record (and further, for the benefit of those
unable to attend the Oslo session), I would claim that making PKI easy for
developers is a very good thing.  Your comment belows seems to modestly
suggest that such an objective is less worthy than it might ought to be.

Indeed, this principle was the primary motivation for OCSP's original
non-ASN.1 proposal.

Mike

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Tuesday, July 13, 1999 12:28 AM
> To: Anders Rundgren
> Cc: 'Peter Sylvester'; [email-masked]'
> Subject: RE: ASN.1 vs XML (used to be RE: I-D
> ACTION:draft-ietf-pkix-scvp-00.txt)
> 
> 
> Anders,
> 
> 
> >The important thing is that in order to make PKI a 
> main-stream technology
> >(which it is
> >not today), may require changes like going to XML as XML is likely to
> >at least replace EDI which is often used in the same contexts as
> >certificates (or
> >rather should be).  So if XML becomes the HTML (which is closer to a
> >"peoples movement" than a computer language) of business 
> messages, ASN.1
> >may be too obscure (few know it) and less satisfactory as a long-term
> >solution.
> >
> >This should be seen in the light of the fact that the only 
> main-stream
> >PKI-application
> >I can think about, is e-commerce.  As very few e-commerce 
> standards are ready
> >for prime time, there is plenty of room for new things.
> 
> There seems to be an implication here that mainstream users 
> want to be able
> to read the signed data in its native format, and thus XML encoding is
> preferable to DER.  But we know this is not true, i.e., 
> whatever has been
> signed will be decoded prior to display, and then rendered 
> for the user.
> So, it would seem that the use of an encoding scheme such as 
> XML would be
> more attractive for developers performing debugging, rather 
> than for users.
> 
> Steve
>