Subject: I-D ACTION:draft-yoon-pkix-wireless-internet-00.txt

From: [email-masked]
Date: Fri, 16 Nov 2001 06:58:53 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Wireless Internet X.509 Public Key Infrastructure
                          Certificate Request Message Format and Protocol 
                          WCRMFP)
	Author(s)	: J. Yoon et al.
	Filename	: draft-yoon-pkix-wireless-internet-00.txt
	Pages		: 12
	Date		: 15-Nov-01
	
This document describes the Wireless Certificate Request 
Message Format and Protocol (WCRMFP) in wireless internet 
environment. This format and protocol are used to convey a request 
for a certificate to a Certification Authority (CA) (possibly via a 
Registration Authority (RA)) for the purposes of X.509 certificate 
production.  The request will typically include a public key and 
associated registration information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-yoon-pkix-wireless-internet-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-yoon-pkix-wireless-internet-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-yoon-pkix-wireless-internet-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 16 Nov 2001 13:26:25 +0000

This draft says:

"The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document.  For more information consult the online list of claimed
rights (see http://www.ietf.org/ipr.html)."

But there's nothing relevant there that I can see. Anyone got any
better information?

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 20 Nov 2001 10:02:42 -0500

Hi.

I am confused by your document.  I understand why you might nor want to use 
some of the ASN.1 toolkits on a wireless platform, but I do not see why a 
simple hand coded implementation of this specific data structure is not 
acceptable.

As you know, the PKCS documents have made use of ASN.1 for many years.  I 
have experience with these ASN.1 data structures in smart cards.  We did 
not use a general purpose toolkit, we simply wrote code for the single 
structure that we cared about.  Is seems that similar code would be needed 
to implement the structures proposed in your draft.

I would rather not see another certificate request format become a standard.

Russ

---

From: "Jaeho Yoon" <[email-masked]>
Date: Thu, 22 Nov 2001 22:46:41 +0900

Dear Sir Russ,

Actually our purpose was to implement an ASN.1 notation in mobile terminals at the beginning. 

This can also make PKI interoperability with wired system easily. But while being processing this project with mobile phone makers and PKI vendors, we were faced with problems, memory limitation and computing power of mobile device. 

We needed a toolkit that could provide PKI and related service in mobile device. 

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 understand that you don’t want another request format to be a standard. We are also expecting that ASN.1 in wired system will be moved to wireless system near future. Mobile devices are being developed rapidly. But the user doesn't wait by then. Thus our document might be helpful to the organization that is in the same situation as us. That’s why we submitted this document.

I think we will start the commercial wireless PKI service from next month. Once the PKI module ported in wireless devices, its applied areas are very wide. For instance, PKI will be used not only in mobile banking or shopping, but also in CDMA global roaming, and bluetooth and smart, java card and so forth. PKI is, as you know, infrastructure. Before other technology dominates the wireless, we are trying to attempt all possibilities. PKI is a means of my living. 

Yours sincerely,

==============================================================
                                                                                               ＼              (  .－.  )
This Mail From  :  Jaeho Yoon /                                                ＼         |( ● )
E-Mail Address  :  [email-masked] /                                         |      ⊂￣   )
Korea Information Security Agency Tel : +82 2 405 5434 /       |      ⊂￣  /○
                                                                                                          |       |￣￣

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 26 Nov 2001 12:46:05 -0500

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.  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.

Russ

---

From: Eric Murray <[email-masked]>
Date: Mon, 26 Nov 2001 10:36:15 -0800

On Mon, Nov 26, 2001 at 12:46:05PM -0500, Housley, Russ wrote:
> 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 

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

---

From: Eric Rescorla <[email-masked]>
Date: 26 Nov 2001 10:38:43 -0800

> your draft proposes to eliminate.
I've got to agree with Russ here. Writing a generalized ASN.1 parser
is quite a bit of work. Writing a primitive decoder for a few specific
data structures is straightforward (though tedious) and can be 
executed within quite a small footprint.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 27 Nov 2001 08:48:29 -0500

Olivier:

I did not mention any particular toolkit.  Jaeho Yoon mentioned OSS...

Russ

> > > >manufacturerâ??s (OSS etc.) assistance. So we tested not an ASN.1 but
>Russ,
>you mentioned OSS above.  Did you try their Lean Encoder/Decoder (LED)
>library?  It is is targeted specically to embedded systems, and source is
>available to allow you to further customize it if the image produced by
>the binary version is too large (that version is built with most features
>enabled, such as automatic encoding/decoding of open types).
>--
>Olivier DUBUISSON
>france telecom R&D

---

From: Olivier DUBUISSON <[email-masked]>
Date: Tue, 27 Nov 2001 13:59:09 +0100

Russ,

you mentioned OSS above.  Did you try their Lean Encoder/Decoder (LED)
library?  It is is targeted specically to embedded systems, and source is
available to allow you to further customize it if the image produced by
the binary version is too large (that version is built with most features
enabled, such as automatic encoding/decoding of open types).
-- 
Olivier DUBUISSON
france telecom R&D
     _                 DTL/MSV - 22307 Lannion Cedex - France
    ( )           tel: +33 2 96 05 38 50 - fax: +33 2 96 05 39 45
    /.\/               --------------------------------------
    \_/\               Site ASN.1 : http://asn1.elibel.tm.fr/

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 27 Nov 2001 08:48:29 -0500

Olivier:

Russ

---

From: "Olivier DUBUISSON" <[email-masked]>
Date: Tue, 27 Nov 2001 13:59:09 +0100

Russ,