On Tue, Apr 23, 2013 at 2:29 PM, Dave Cridland <d...@cridland.net> wrote: > Ah, OK, so the server's key is also its own trust anchor. > > The problem I worry about here is that it means that a server compromise > event will lead to a situation where the server's keypair can be used to > subvert existing accounts. This is a bit of a nightmare scenario in many > deployments. >
Isn't it what could happen with CA authorities too? At least until the compromised keys are replaces with new ones, the compromised key can be used for malicious purposes. > You could work around this by separating the functions - so the server > trusts a third party, which itself signs the keys of registering clients. > Well, my aim is: client always has one single credential, with which it can login to any of the servers within the network. Using passwords or some hard-stored credential would require data replication; checking key signatures will save space and resources. I know there are consequences to this (continues below). > However, once you worked in ways to handle client key compromise, and all > the rest, I don't see what this is buying you that running a private X.509 > CA for the service would not. And doing the latter would mean using > off-the-shelf components (including an unmodified server and often > unmodified clients, too). Personally, I'm lazy enough to see the idea of > avoiding having to write new code to be a great idea. > Clients will be using their OpenPGP keys to sign messages for one another, I thought it could be useful to use the same keys to authenticate too - thus avoiding having two different keypairs (one for authentication, one for encryption/signing). > I don't see how you'd handle key rollover either. > I wonder how do they do in X.509: I mean if a key is compromised, *all* certificates signed with that key must be discarded almost immediately - and replaced with a new one. Couldn't I do the same? > I'm not saying you're doing everything entirely wrong, just that X.509 has > these problems well-understood and (usually) solved. The primary advantage > of using something like OpenPGP keys would be to buy into an existing > infrastructure without use of public CAs, but you can do the latter whilst > still using PKIX, and you don't seem to be trying to do the former. > My implementations and ideas I'm exposing here are just a start; I'm still starting to dive into all these (for me) new concepts as I try to build this instant messaging system. I know I still have a lot to learn, I'm here also for that :-) > FWIW, the unsolved problem using PKIX is that you need the client to supply > a CSR during registration, and obtain a signed certificate back, possibly > later. I'd be very keen to see this defined, and would be interested in > helping. > In which way this is a problem? Because of the delay between key+CSR generation and its signing by the CA? -- Daniele
