Re: [pkng] Some more wacky ideas... Usability ?

[Massimiliano Pala <[e-mail]>]

Hi all,

just adding to the list of things we could explore... (Paul,
are you keeping track of all the proposals so far ?), I think
we shall look into keeping the PKNG easy - or, at least, relaying
on some concepts that are easy for the users AND for the
developers. Ease-of-Use = less deployment, implementation
and usage errors.

I am saying this because one big problems we have with PKIs
today is the complexity of the protocols on one side and of
crypto libraries on the other. As a result, augmenting apps
with PKI is a painful process. Many developers have no idea
about what they are doing... so... we still rely on passwds
for the majority of our security needs.

Summarizing: we shall keep an eye on usability for users,
developers and pki managers.

I also really like the Stephen's (Farrel) idea of allowing
for a transition to the PKNG when and if needed.. so keep it
at a high-level of abstraction + technical details.

Also, and this is my last point, as we have seen the need for
isolated PKIs to federate (most of the time AFTER they have
been deployed), I would suggest investigating (and I am totally
volunteering for this) mechanisms to integrate existing and
future infrastructures. In more details, I was thinking about
using Peer-2-peer technologies to provide a sort of PKNG
overlay network for secure communication between PK-nodes
(more for CAs nodes rather than End Entities nodes - for
usability and ease-of-deployment considerations).


Cheers,
Max


On 11/12/2009 04:43 AM, [e-mail] wrote:
>
> ...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.)

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]                   [e-mail]
                                                  [e-mail]

Dartmouth Computer Science Dept               Home Phone: [phone]
PKI/Trust Laboratory                          Work Phone: [phone]
--o------------------------------------------------------------------------
People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov