[pkng] Some more wacky ideas...

[[e-mail]]

...none of which are even a bit thought through yet of
course:-)

1) Whatever formats we end up with carrying about keys and
other stuff, I'd like selective field confidentiality to
the max. (Up to and including encrypting the public keys
as well since they expose identity pretty well:-)

2) I want zero-or-more of everything in any structure
(keys, identifiers, locators, blahs...) and to be able
to express relationships between those ("two of these
keys are needed for banking," "any of these keys for
family"...)

3) I'd like to think about the private key holder never
seeing anything like a cert. In many cases, its only
the RP (or a service acting on its behalf ala XKMS/SCVP),
who actually needs whatever structure is involved. That
could push any enrollment burden onto the beneficiary,
which'd be nice. (And in that case, different RPs should
be able to share the burden between them, if the private
key holder is ok with that.)

4) Not all clocks are accurate so I want something that
doesn't need any real time clocks at all, (its ok to use
'em sometimes though).

5) There're probably a bunch of crypto papers about RSA
like keys with more than two factors, split-keys, etc
and they should just work as well as more traditional
keys if they're useful. Not sure how to map that to a
story, but maybe related to different keys having
wildly different crypto APIs associated with them. Maybe
I'll even send you the runtime for that with the key.

6) I want something that works with load-balanced
services - it should be cheap to use whatever we want
to do without having to do it all over again each
time I talk to a different VM or whatever.

7) DTN scenarios, where you can't wait on a round-trip
and sensor-networks where you can't send big packets
should be considered, but are probably corner-cases.
(We might learn from them though.)

8) (Ignoring Paul's instructions:-) I'd like to be able
to hack whatever we do so that the results look like an
X.509 cert so not all PKIX-consuming protocols would have
to know we're messing about under the hood. (Or, put
more soberly, I'd like us to consider migration:-)

9) I'd like some "soft" failure modes, so people (users
or developers) don't have to get stupid PKNG errors to
replace stupid certificate errors. ("Please Mr. RP: If
nothing else works, would you let me do *something*
based on this key?") Put another way: all keys are
valid, some are just better-suited than others for
a particular purpose. (Could revocation even go away?)

10) I want to be able to develop an application so
that when I protect application layer PDUs, then
different receivers get to see different parts, maybe
according to some complex set of rules. (We have a
project on securing electronic health care records
starting in March and this is a requirement for that,
that can probably only be met very clumsily with
current PKI.)

That's enough for now...

S.