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

Apology and requirements

I think my modest offer really worked to get this list off to a bad start.
Sorry.

I took that initial word in my subject line "If it's binary ye be wanting"
to be critically important.
    *IF* the group wants binary *THEN*
        there is a free production-quality standards-level package
        available that includes abstract notation, code generators, and
        efficient on-the-wire transfer syntax.
    *FI*

Having left all that behind, here are some requirements that I would like
an PKI to meet.  I'm not planning on maintaing or updating this list; I
hope someone else will step forward (perhaps our Chair?).

    1   Not limited to ASCII.  I will have performance constraints
        where a cert must fit in a very small UDP-style packet and
        the typical 30% inflation isn't acceptable.

    2   Must be extensible.  For example, I'd like to put authorization
        information into a cert.  But using something like "X-DCE"
        isn't sufficient since anyone else could "usurp" that header
        and break interoperability.  Either their must be a fast and
        lightweight registry that will grant me exclusive use of DCE.
        Since IANA typically hasn't had this, I mildly prefer something
        like ISO OID's or DCE UUID's (which basically use IEEE 48bit
        node addresses as the core of their uniqueness).

    3   Must be optimized for open systems and COTS hardware.  This
        means ASCII rather than EBCDIC, 8bit-bytes and n-byte integers
        rather then infinite binary digit strings.

    4   Must be nestable.  It should be possible for a "trusted introducer"
        to take an unknown cert, "override" some fields, and then present
        that to a local agent for ultimate processing.  (I know this is
        terse; let me know if more explanation is needed.)

    5   Must not assume trusted communication paths.

    6   All uses of crypto must be tagged so that they can be replaced
        later without changing protocols. For example, Micali's lightweight
        CRL protocol should have an explicit field identifying MD5 as
        the one-way hash that's used.  Of course I'll need a registry
        like that required in #2.

    7   Must support multiply-rooted tree for trust chains.  (Of course
        others will want more; consider this item incentive to help define
        requirements.)

    8   On-the-wire protocols must be specified.  This is the only way to
        guarantee interoperability.  This means ASN.1 should not appear
        in final specs, although ONC XDR and DCE IDL are okay, as is
        (sigh...) ASN.1+[DB]ER restricted to that subset that meets #3
        above.

    9   Must scale in a variety of ways.  These numbers are guesses:  A
        single CA should be able to handle a million clients, and the
        trust model should support a half-million CAs.  it is not my
        requirement that everyone be able to act as their own CA, but I
        am not opposed as long as it doesn't impact my other requirements
        here.

Hope this gets some more productive discussion going.
        /r$
Follow-Ups: