[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.
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.
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
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
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
Hope this gets some more productive discussion going.