Re: draft-yoon-pkix-wireless-internet-00.txt

[Eric Murray <ericm@xxxxxxx>]

On Mon, Nov 26, 2001 at 12:46:05PM -0500, Housley, Russ wrote:
> 
> Jaeho:
> 
> I just want to reply to one small part of your message.
> 
> You said:
> >We had to consider the size of ASN.1 run-time library and its actual code 
> >size and processing time including key generation in mobile devices. We 
> >just have maximum 150Kbyte in a brand-new mobile phone. And it was nearly 
> >impossible to make a partial revision of commercial ASN.1 product without 
> >manufacturer’s (OSS etc.) assistance. So we tested not an ASN.1 but 
> >different methods again and again. Fortunately, we ported the PKI 
> >application at mobile devices and have finished testing it. Now, We are 
> >ready to launch the service.
> 
> I have experience with ASN.1 data structures limited processing 
> environments, specifically smart cards.  In this environment, we did could 
> not use a general purpose toolkit for the reasons that you discuss 
> above.

Same here.  In my case, I headed a team that was doing the client side of
SET in an embedded environment.  SET used ASN.1 quite extensively
and also used X.509 (with cert chains that could reach 20+ certs in length!)   

>  However, we found that there were very few ASN.1 data structures 
> that actually needed to be processed in the limited processing 
> environment.  In some cases, only decoders were needed.  In other case, 
> only encoders were needed.  In very few cases, both encoders and decoders 
> were needed.  Therefore, we simply wrote code for the structures that we 
> cared about.  The resulting structure-specific code was very small, and it 
> had no burdensome run-time requirements (like large tables).  It appears to 
> me that similar code could be used to implement the ASN.1 structures that 
> your draft proposes to eliminate.

My solution was similar, plus some added features for doing ASN.1
encoding using small amounts of memory.  The entire ASN.1 library
(supporting X.509v3, PKCS #1, #7, and stuff for SET) was about 30k of code.
It used very little heap as well.
I've implemented simple decoders in small amounts of code prior to that,
and at my current company I've figured out a way to make ASN.1
procesing code significantly smaller still.

I don't think that having small amounts of memory is a good reason
to not use ASN.1. 


Eric