[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

encodings, character sets, general requirements

In my opinion the specification and formats should be as easy to
understand as possible, with as little background study as possible.
Having to read several cross-referenced standards to be able to
understand increases implementation complexity by a substantial
factor and makes it hard to understand for the casual reader.

I have doubts about the usefulness of ascii encodings; I don't think
most of the information will be very useful anyway, and ascii
encodings are often pain to parse and sign, especially since we may be
talking about somewhat recursive structures.  Binary encodings are
probably easier to parse and handle, and more compact.

It is quite feasible to pass both the base-64 encoded version and a
plaintext comment stating the owner of a key (for informative purposes
only) together when useful.

I think it is very important to support character sets other than
7-bit ascii, especially if things like names of persons are included.
I think unicode is a good choice; as I recall, the first 256
characters are essentially iso-latin-1 and are thus easy to print in a
7- or 8-bit environment.  My understanding is that fonts containing
eastern or other characters typically use Unicode encoding, both on
Windows/NT and X11.

> breaking away from 8+3 character file names.  A 16-bit string length is
> not infinite, but infinite enough for our purposes.  With radix64 encodings

I wouldn't count on that.  But, doubt anyone here will say that a
32-bit length is too short; it takes no more space.  Likewise, I think
it makes sense to encode dates as yyyymmddhhmmss rather than seconds
since 1970, because this avoids ugly dependencies on current Unix
practises but is almost as easy to process (and is easy to covert
to/from the unix representation using gmtime() and mktime(), both of
which are freely available).

However, the most important thing now is what it is going to be used
for.
  - Encryption keys for E-mail and file encryption
  - Authentication of people or other entities
  - Digital signatures (unforgeability)
  - Timestamping / notary services
  - Host authentication
  - Service authentication

Other requirements:
  - Trust model must be a web (people want to choose whom they trust).
    People must be able to choose whome they trust or consider
    reliable roots (maybe with varying reliabilities).
  - Some applications (e.g., notary services) require highly trusted
    keys; generation complexity is not an issue here
  - Some applications (e.g., host authentication) require extremely
    light (or no) bureauchracy.  Even communication with the central
    administrator may be a problem.
  - Especially in lower-end applications (e.g. host authentication)
    the people generating the keys (e.g., administrators) will change,
    and you will no longer want them to be able to certify.  On the
    other hand, you will usually also not want all keys they have
    generated to expire.  This may imply a "certification right
    expiration" certificate requirement, probably to be implemented
    together with notary services.
  - Keys will need to be cached locally to avoid long delays fetching
    frequently used keys.  Cf. current name servers.  The key
    infrastructure may in future get used almost as often as the name
    server.  The caching and performance requirements are similar.
  - Reliable distribution of key revocations and other certificates
    (e.g., the ceasing of the right to make new certificates).  May
    involve goals like "will have spread everywhere in 24 hours"
    or something like that.  This interacts with caching.


    Tatu
Follow-Ups: References: