Subject: Re: WAP X.509 Certificate profile specification

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 13 Nov 2000 15:24:17 -0700

The Novell Certificate Server was architected to support multiple CA server's running concurrently in a distributed system. In order to avoid possible synchronization problems, we use a SHA-1 hash of a 128-bit machine-unique ID and a 32-bit local machine-specific serial number to form a 160-bit (20 byte) certificate serial number.  (Yes, I understand that this only provides probabilistic uniqueness, but I'll take the risk, and worry about it after generating 2^80 certificates.)

Although I'm sympathetic to processor power limitations for WAP devices, you would think by now we had learned our lesson with respect to setting artificial memory limitations.  Remember when 640K of memory was all that a PC would ever need? Remember Y2K??

The reason for using ASN.1 was to avoid these kinds of problems, and I see no reason to change or revisit those decisions.  20 bytes, or even more, won't break the bank.

If they really want to save certificate space, they should mandate the use of UTF-8 for DNs, especially for the Asian languages, rather than using BMPString.

Bob

>>>  $(G¤ý¤å¥¿ <[email-masked]> 11/03/00 11:24PM >>>
Hi Magnus,

I've downloaded the WAP X.509 certificate profile specification, and noticed
that there is a recommendation on the length of Certificate Serial Number:

6.2.1 Certificate Serial Number
CAs claiming conformance with this specification should avoid using
serial numbers longer than 8 bytes (63 bits, topmost bit cannot be set to
1).

I believe that the recommendation is due to the limit memory space and
processing power of WAP device. However, I suggest that the specification
should extend the limitation on the length of certificate serial numbers
from
8 bytes to at least 16 bytes, since there are many root CA's and
intermediate
CA's are currently usning 16-byte certificate serial numbers. By allowing
merely more 8 bytes be used for certificate serial numbers, existing CA's
may issue WAP-compliant certificates without changing their algorithms for
generating certificate serial numbers.

--
Wen-Cheng Wang
Telecommunication Lab.
Chunghwa Telecom Co., Ltd.

On Mon, 30 Oct 2000, Magnus Nystrom wrote:
> Hi Tom,
>
> I would suggest that you send them directly to me, unless they are
> pkix-related. I will make sure to forward them to WAP's security group
> mailing list - and Cc: you.
>
> Thanks,
> -- Magnus
>
> On Mon, 30 Oct 2000, Tom Arnold wrote:
>
> I've downloaded the document and am beginning to review it.  My company is
> not a member of the Wap Forum...  As such, if I have comments, where
should
> I send them? I'm assuming the PKIX list is not the correct location...
>
> At 04:19 PM 10/26/2000 +0200, you wrote:
> >Dear PKIX members,
> >
> >On behalf of WAP's security group WSG, I would like to inform you that
> >a document named "WAPCert-20000309" can be found at
> >
> >http://www.wapforum.org/what/technical.htm.
> >
> >This document describes X.509 certificate profiles to be used for those
> >cases when X.509-compliant certificates will be sent over-the-air in WAP
> >protocols (or stored locally in WAP clients).
> >
> >An accompanying document, "WAP-217-WPKI-20000303" describes WAP's PKI.
> >
> >Comments and suggestions related to these documents are welcome and
> >solicited.

---

From: Magnus Nystrom <[email-masked]>
Date: Tue, 14 Nov 2000 11:11:30 +0100 (W. Europe Standard Time)

Bob,

Thanks for your comments.

On Mon, 13 Nov 2000, Bob Jueneman wrote:

> The Novell Certificate Server was architected to support multiple CA
> server's running concurrently in a distributed system. In order to
> avoid possible synchronization problems, we use a SHA-1 hash of a
> 128-bit machine-unique ID and a 32-bit local machine-specific serial
> number to form a 160-bit (20 byte) certificate serial number.  (Yes, I
> understand that this only provides probabilistic uniqueness, but I'll
> take the risk, and worry about it after generating 2^80 certificates.)

From your description, it seems that for a given machine, The probability
of issuing two certificates with the same serial number is approx 0.5
already after that machine has issued 2^16 certificates (assuming that the
machine-unique ID remains invariant over time). But I may well have
misunderstood, in which case I apologize for the confusion.

> Although I'm sympathetic to processor power limitations for WAP
> devices, you would think by now we had learned our lesson with respect
> to setting artificial memory limitations.  Remember when 640K of
> memory was all that a PC would ever need? Remember Y2K??
> 
> The reason for using ASN.1 was to avoid these kinds of problems, and I
> see no reason to change or revisit those decisions.  20 bytes, or even
> more, won't break the bank.

Yes - and hence this is only a recommendation, not a "MUST". Clients
should handle longer serial numbers, but there are some bandwidth (and
storage space) to be saved by limiting their length.
 
> If they really want to save certificate space, they should mandate the
> use of UTF-8 for DNs, especially for the Asian languages, rather than
> using BMPString.

The WAP Certificate Profile does recommend the use of UTF8 (and, in line
with 2459, mandates its use after December 31, 2003). Further, since WAP
clients are not mandated to be able to display values of types other than
NumericString, PrintableString and UTF8String, this will hopefully be an
incitement to move away from BMPString (which is not mentioned in the WAP
Cert Profile).

-- Magnus
Magnus Nystrom
RSA Security