Subject: Comments on the OKID draft

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 17 Apr 2002 11:16:40 -0700

While I like the overall idea I think it can be substantially improved as
follows:

1) The initial string is 2 characters, yet the argument is made that we are
so short of space that we cannot afford any form of parity check.

I suggest that we change this so that the first charater represents the type
of OKID and the second is a parity check. This leaves us room for up to 32
different OKID types, and that before we start using bits in the data
portion.

I suggest that we form the parity check as follows:

Let the OKID be

WW-XXXX-XXXX-XXXX-XXXX-XXXX
WP-AAAA-BBBB-CCCC-DDDD-EEEE

W = E, C, A, B as before
    L to stand for license activation
    R to stand for one time authentication code

P = a 5 bit parity check formed as follows

Bit 0 = Parity of W AAAA
Bit 1 = Parity of W AAAA BBBB
Bit 2 = Parity of W AAAA BBBB CCCC
Bit 3 = Parity of W AAAA BBBB CCCC DDDD
Bit 4 = Parity of W AAAA BBBB CCCC DDDD EEEE

This mechanism gives a 50% chance that an error will be caught in any given
block as it is typed
and failing that a 50% chance it will be caught in the next block, etc.

2) The format described in the first part of the draft is for a 100 bit
OKID, the example describes an 80 bit OKID

I prefer the 100 bit format, in fact I would like to have the option of
specifying as many blocks as I like, up to 8 if necessary.

3) The use of the OKID in the manner of a PGP fingerprint should be
explicitly considered under security considerations.

4) I would suggest that the registry concept should be unnecessary if the
hash is large enough. There should be a means of re-using exisitng IANA
identifiers, e.g. by combining a hash of an IANA mime type and the hash of
the data... H ( H (type), H (data) )

5) I would also suggest that we try to avoid unnecessary dependence on PKIX
data formats here, the probability of collision should be negligible and so
the option of using an OKID for PGP or SPKI or PKIX keys is attractive.

6) This technology could provide a means to address the one remaining
objection voiced of PGP over S/MIME, the ability to generate short key
signing lists. I do not propose the draft address this, but someone should. 

		Phill