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

From: "David P. Kemp" <[email-masked]>
Date: Thu, 1 Jul 1999 13:51:39 -0400 (EDT)

I agree that the perception that ASN.1 cannot be used in a tiny syntax
is largely undeserved.  I would be happy to write a small ASN.1 parser
that should compare favorably in runtime and memory footprint with the
software required to support the alternate encoding.  Support for
indefinite-length (non-DER) coding costs almost nothing so a DER
restriction is not necessary, but using implicit tagging for
context-tagged OPTIONAL elements will save a couple of bytes per
element in the encoded data and one tiny subroutine in the code.
Making every element non-OPTIONAL but potentially zero length would
save more code.

Anyone care for a syntax bakeoff? :-)

>From: "Salter, Thomas A" <[email-masked]>
>
> Are you sure that the tiny syntax saves all that much parsing code?
> 
> It seems to me that you could accomplish much of what you want by
> restricting the protocol to a very small subset of ASN.1.  Suppose, for
> instance, that all protocol elements are implicitly tagged and encoded as
> DER.  Then the biggest difference between that and 'tiny' syntax is that the
> variable-length length field (and perhaps a variable length tag).
> 
> (I would only apply the DER restriction to elements parsed by the client;
> the client could encode using any BER encoding.)
> 
> My question is whether a 'tiny' parser is enough smaller than a parser for
> an ASN.1 subset to be worth inventing a new encoding scheme.

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 01 Jul 1999 11:08:04 -0700

At 01:51 PM 7/1/1999 -0400, David P. Kemp wrote:
>is largely undeserved.

Maybe so, but it is a widespread perception.

>   I would be happy to write a small ASN.1 parser
>software required to support the alternate encoding.

A single instance of a parser is not going to convince many people that 
constrained ASN.1 is sufficient. A syntax that implementors can understand 
well enough to write a parser is what is needed. If we can describe the 
ASN.1 syntax well enough to prove that such a parser is fairly easy to 
write, then there is a win, but I suspect that is impossible due to many 
things, including the lack of easily-findable documentation for creating 
ASN.1 interpreters.

>   Support for

We did not try to optimize for smallest messages; in fact, we didn't see 
that as a requirement at all. A single subroutine is also not important.

>Anyone care for a syntax bakeoff? :-)

We're quite open to any syntaxes that would make client vendors more likely 
to implement SVCP. That's precisely why we have two in the draft, and why 
all of the semantics are in a different section. If we can go with one and 
show how someone with little or no ASN.1 experience can create a program 
that writes requests and reads responses, that would be great. But I'm 
skeptical...

--Paul Hoffman, Director
--Internet Mail Consortium