Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 8 Jul 1999 23:31:57 +0100

Well,
sorry for bringing this up.  For certificates with huge informational contents I
see some gain by wrapping an XML information object into ASN.1 X509
wrapper.  If PKI goes big, certificates proliferate the decoding part (RP debugging)
will be helped by using XML rather than ASN.1.  Particularly if XML becomes
the lingua franca of the Web.   But of course XML is not required, it is just
something that could be worth considering for lets say X509.v4

Anders

>I agree with you that the XSL standard does indeed address the encoding
>standards, but ther real issue is why change from the standard ASN.1 mindset
>to XML.
>
>What is the gain here?
>
>Todd
>
>----- Original Message -----
>From: William Z Pope <[email-masked]>
>To: [email-masked] <[email-masked]>; Anders
>Rundgren <[email-masked]>; Stephen Kent <[email-masked]>
>Cc: <[email-masked]>
>Sent: Thursday, July 08, 1999 1:14 PM
>Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
>
>
>>
>> A point of clarification, XML is a human readable data description
>> format.  I has nothing to do with presentation.  XSL defines presentation
>> options for XML documents based on the structure and content of the XML
>> document.
>>
>> I now return you to your regularly scheduled discussion :^)
>>
>> =bill
>>
>> > -----Original Message-----
>> > From: [email-masked]
>> > [mailto:[email-masked]]
>> > Sent: Thursday, July 08, 1999 12:48 PM
>> > To: Anders Rundgren; Stephen Kent
>> > Cc: [email-masked]
>> > Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt
>> >
>> >
>> > Steve is absolutely right here. The While XML will likely expand to
>> > encompass a number of the presentation processing formats, ass the core
>> > representation mechanism we need something better.
>> >
>> > Hard to believe but I support Steve's commentary in this 100%
>> >
>> >
>> > Todd
>> > ----- Original Message -----
>> > From: Stephen Kent <[email-masked]>
>> > To: Anders Rundgren <[email-masked]>
>> > Cc: <[email-masked]>
>> > Sent: Wednesday, July 07, 1999 3:04 PM
>> > Subject: RE: I-D ACTION:draft-ietf-pkix-scvp-00.txt
>> >
>> >
>> > > Anders,
>> > >
>> > > We have heard from others who work for large companies who use the
>> > > technology base that you cite as unable to process ASN.1 structures,
>and
>> > > their comments are at odds with yours.
>> > >
>> > > Yes, there are a lot of folks who are enamored with XML, as one would
>> > > expect of any new mechanism that has gotten so much hype in
>> > trade rags.  I
>> > > don't question the value of XML in some applications, but given the
>> > > commitment we already have to ASN.1 in our protocols and in the
>> > base cert
>> > > and CRL syntax, I don't see a good argument to change here.
>> > >
>> > > Barring more evidence to the contrary, we should stick with ASN.1.
>> > >
>> > > Steve
>> > >
>> >
>> >
>>
>>
>
>
>

---

From: Kathy Dally <[email-masked]>
Date: Thu, 08 Jul 1999 18:22:56 -0400

Hi Anders!

Two reactions:

	Wrapping XML/XSL in ASN.1 encoding means implementations must deal with
both 
	types of encoding.

	Is XSL encoding always unique or will there be a BER/DER-like problem?

Thanks,
Kathy Dally

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 8 Jul 1999 15:55:44 -0700

----- Original Message -----
From: Anders Rundgren <[email-masked]>
To: PKIX-List <[email-masked]>; Stephen Kent <[email-masked]>;
[email-masked] <[email-masked]>; William Z
Pope <[email-masked]>
Sent: Thursday, July 08, 1999 3:31 PM
Subject: Re: I-D ACTION:draft-ietf-pkix-scvp-00.txt

> something that could be worth considering for lets say X509.v4

Actually if that is your intent,  I would think that the real win here is
having a number of different cert representation formats that include
ASN.1/BER-DER, Binary, XML, and SMIME, myself.

and have the approved Cert Management Protocols support these
inter-deployment interoperability issues directly.

Todd.

---

From: "Ambarish Malpani" <[email-masked]>
Date: Thu, 8 Jul 1999 16:43:17 -0700

Can we please change the subject on this discussion?

Thanks,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect					         650.567.5457
ValiCert, Inc.				        [email-masked]
1215 Terra Bella Ave.		              http://www.valicert.com
Mountain View, CA 94043-1833

> Sent: Thursday, July 08, 1999 3:56 PM
> To: Anders Rundgren; PKIX-List; Stephen Kent;
> [email-masked]; William Z Pope
> [email-masked] 
> <[email-masked]>; William Z
> Pope <[email-masked]>
> > sorry for bringing this up.  For certificates with huge 
> informational
> contents I
> > wrapper.  If PKI goes big, certificates proliferate the 
> decoding part (RP
> debugging)
> > the lingua franca of the Web.   But of course XML is not 
> required, it is
> just

---

From: Ben Laurie <[email-masked]>
Date: Fri, 09 Jul 1999 14:48:39 +0100

>         Wrapping XML/XSL in ASN.1 encoding means implementations must deal with

Which would make it pointless, I presume you are implying.

>         Is XSL encoding always unique or will there be a BER/DER-like problem?

XSL is for presentation, and its uniqueness or lack thereof is not
relevant. XML is not unique, so there is indeed a BER/DER-like problem,
if you believe that the ability to reconstruct the object is needed to
check the signature.

If, on the other hand, you take a realistic approach and only require
the source of the data to be signed and not a reconstructed version,
then you have no such problem. Incidentally, since almost no-one can
implement DER 100% correctly, it seems, DER doesn't solve that problem
anway.

Finally, if people really do want DER-like abilities, I'm sure extra
rules could be applied to XML to make that possible. And since the
result would be considerably less baroque than DER is, it may even be
that sometimes it will get correctly implemented.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi

---

From: Stephen Kent <[email-masked]>
Date: Fri, 9 Jul 1999 10:11:06 -0400

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: Timothy Fisher <[email-masked]>
Date: Fri, 09 Jul 1999 08:10:57 -0700

I think it would be a very smart idea to move the Certificate encoding
mechanism from ASN.1 to XML.   ASN.1 has always been the down-side of X.509
certificates.  XML would be a great improvement.

Tim
Cyclone Software

---

From: Paul Koning <[email-masked]>
Date: Fri, 9 Jul 1999 11:36:39 -0400

I'm really baffled by the notion of creating Yet Another Format for
encoding something when a format exists today that can do the job.  It 
may be a leading candidate for the world's ugliest encoding,
admittedly, but it is known to do the job.

Creating another encoding will just force implementations to support
two formats rather than one, deal with two sets of bugs rather than
one, cope with backwards compatibility issues when talking to other
boxes that only support one format, etc. etc. etc.

In short, I see no conceivable benefit and lots of drawbacks.  Am I
missing something?

	paul

---

From: Bill Burr <[email-masked]>
Date: Fri, 09 Jul 1999 12:23:34 -0400

>In short, I see no conceivable benefit and lots of drawbacks.  Am I

Paul

The argument, as far as I can see it is:

1.  ASN.1 is so ugly that perhaps it ought to die, and

2.  XML is becoming the great unifying data encoding format, supported by
all the tools, from Microsoft Office to databases and many more specialized
tools, while ASN.1 remains a curiosity with tools that are either largely
unsupported or expensive.  If we will have good pervasive XML tools
supported everywhere, why not plug into them and drop the last OSI baggage?

But, I've been around long enough to remember when very similar claims that
never panned out, were made for SGML and ASN.1 itself.  It seems perhaps a
bit too early to just assume that XML will be the great unifying data model
and format for the next millennium. 

It replacement of ASN.1 be a reasonable idea to consider, but I'd like to
see how XML plays our a little more, before jumping head first into the XML
pool.
Regards,

Bill Burr

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Fri, 9 Jul 1999 13:08:47 -0400

I am reminded of the occasion late in the development of the HTTP spec
when there was some considerable argument over a proposal to correct
the spelling of the 'referer' tag.

I was quite amazed by the number of people who were keen to change the
spelling dispite the fact that they would break an installed base of
gazillions of browsers with a change that would be 1) invisible and
2) if anything slightly decrease performance since each message would
carry an extra byte.

Pausing only to note that my spelling of the word referer is arguably 
the common usage at this point since a trillion web site hits hourly
have that spelling encoded, I would like to make the point that any 
change in syntax needs a lot of justification and that architectural
purity ain't much of a justification.

Tony Hoare once argued that programming language features should be 
argued separately from the syntax. I would be much happier if IETF
process encouraged a separation of protocol semantics and syntax.

		Phill

---

From: Ben Laurie <[email-masked]>
Date: Fri, 09 Jul 1999 20:11:32 +0100

> In short, I see no conceivable benefit and lots of drawbacks.  Am I

I don't know if anyone is suggesting actually creating another format
right now (though there are aleady two, anyway) but the important point,
I think, is whether further use of ASN.1/DER should be encouraged.
Discussing the relative merits of alternate formats is probably the only
way to ever get to a point where we consider using them.

Cheers,

Ben.

---

From: Paul Koning <[email-masked]>
Date: Fri, 9 Jul 1999 15:35:18 -0400

>>>>> "Ben" == Ben Laurie <[email-masked]> writes:

 Ben> Paul Koning wrote:
 >>  I'm really baffled by the notion of creating Yet Another Format
 >> for encoding something when a format exists today that can do the
 >> job.  It may be a leading candidate for the world's ugliest
 >> encoding, admittedly, but it is known to do the job.
 >> 
 >> Creating another encoding will just force implementations to
 >> support two formats rather than one, deal with two sets of bugs
 >> rather than one, cope with backwards compatibility issues when
 >> talking to other boxes that only support one format,
 >> etc. etc. etc.
 >> 
 >> In short, I see no conceivable benefit and lots of drawbacks.  Am
 >> I missing something?

 Ben> I don't know if anyone is suggesting actually creating another
 Ben> format right now (though there are aleady two, anyway) but the
 Ben> important point, I think, is whether further use of ASN.1/DER
 Ben> should be encouraged.  Discussing the relative merits of
 Ben> alternate formats is probably the only way to ever get to a
 Ben> point where we consider using them.

It sure looked like a proposal to create another formant for existing
things, because people were talking about certificates.

I do agree that new things that don't have any encoding yet should not 
be encoded in BER/DER.  But when an encoding exists, no new encodings
should be proposed unless there are VERY strong arguments why it is
better to have to encodings than one.

	paul

---

From: Ben Laurie <[email-masked]>
Date: Mon, 12 Jul 1999 15:34:36 +0100

I thought I'd replied to this, but I haven't seen the reply.

Stephen Kent wrote:
> to signed data structures.

Showed how?

>  I disagree with Ben's comments re DER.  while

Well, OpenSSL seems to have a fair few workarounds for broken
implementations, and Peter Gutmann recently commented that the only way
to check signatures reliably was to keep the original binary data,
because reconstruction didn't work.

OpenSSL/SSLeay itself failed to correctly construct SETs for years and
no-one noticed.

And so on.

Cheers,

Ben.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 13 Jul 1999 03:39:38 -0400

Ben,

>> to signed data structures.

RFC 822 specifies a canonicalization algorithm for simple text messages.
Messages are stored en route and often mail gateways modify text in an
effort to be "helpful."  So, in PEM we performed the 822 processing to
ensure a canonical format prior to signing, and developed the base64
encoding technique (now used in MIME) to discourage mail gateways from
modifying the signed text.

>OpenSSL/SSLeay itself failed to correctly construct SETs for years and

This seems to be an example of sloppy work, embraced by a developer
community which did inadequate testing.  In contrast, folks working in the
CA and X.500 product communities, and those who used ASN for various ISO
protocols, seem to have been more careful, or have had more time to find an
fix errors.  I stand by my comments.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Tue, 13 Jul 1999 21:32:38 +0100

> fix errors.  I stand by my comments.

Leaving aside the attempt at a personal slight (which widely misses the
mark, as I was not a developer of OpenSSL when this problem was current,
and one of the first things I did as a developer was to fix it), I
completely fail to see the distinction between the OpenSSL/SSLeay
"developer community" and the "CA and X.500 product communities". Any CA
or X.500 developer with any pretence at credibility will surely have
tested SSLeay. In fact, many of them used it as the basis for their
products.

And when Peter Gutmann made that remark, he was certainly not referring
to OpenSSL's standards conformance, as it was in the context of checking
signatures in OpenSSL.

Cheers,

Ben.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 14 Jul 1999 02:17:47 -0400

Ben,

>tested SSLeay. In fact, many of them used it as the basis for their

There was no personal slight intended in my remarks, nor, in my reading,
none expressed.  There was, however, a pointed criticism of SSLeay, a
collection of software, not a standard.  I do disparge the notion that
standards are established by distributed software.

As the CTO of a CA product developer I can and do take exception with the
suggestion that use of SSLeay is relevant to core CA business.  We
developed our own ASN.1 compiler years ago, even sold it to some folks, and
have not found it necessary to avail ourselves of freeware.  I think your
sample of CA vendors and mine differ considerably.

>to OpenSSL's standards conformance, as it was in the context of checking

OpenSSL, what's the RFC for that protocol?  TLS is a standard, and SSL as a
proprietary protocol developed by browser vendors.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Wed, 14 Jul 1999 12:44:51 +0100

> standards are established by distributed software.

I didn't suggest they were. However, interoperability testing is a part
of establishing a standard and is a good way of testing conformance to a
standard.

> sample of CA vendors and mine differ considerably.

Again, I'm not suggesting that you should use SSLeay, I'm suggesting
that you would be wise to test against it (well, against OpenSSL).

> proprietary protocol developed by browser vendors.

OpenSSL conforms to standards, such as the TLS draft standard (unless I
missed something, it isn't a standard yet) and a pile of other ones,
too. I am not suggesting that OpenSSL is a standard. I don't know why
you think I am.

Cheers,

Ben.