On 23 Apr 2013 09:21, "Daniele Ricci" <daniele.ath...@gmail.com> wrote: > > 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. >
Yes, but if you separate the key used to sign account keys from the key used to act as the server credential, then the "CA" key can be used offline, and becomes harder to subvert. I've seen people deploy private CAs over an airgap; remotely subverting such a CA is really quite hard. > > 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). I don't think your aims above are affected by having a distinct signing key. > > 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). Right, agreed. It's somewhat unfortunate that we don't have a deployed equivalent to PGP signing messages quite yet. I'm unconvinced by that spec as it is, but it has the advantage of working and being deployed. There are signing/encryption proposals based around X.509, too. In the XMPP world, I'm tempted to suggest hammering > > 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? No, you can't replace keys immediately; that's really the problem. So PKIX (Or X.509) does this by having revocation information provided by the CA (or a delegate). If your key is compromised, you can tell the CA, who puts it in the list. People wanting to trust your certificate find out by either getting the list (A Certificate Revocation List, or CRL), by querying a service with the list (Online Certificate Status Protocol, or OCSP), or by having the revocation status provided alongside the certificate in the TLS negotiation (OCSP Stapling; currently being enhanced). In the PKIX model, the key used for signing belongs to a CA, which can be protected better against compromise than a key used for signing and encryption (and authentication), such as a client or server key, so revocation of entire CA certificates is rare, and typically makes headline news. > > 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 :-) > Sure; I'm pretty sure there are good reasons why using PGP keys at the TLS layer and so on is a good idea. I'm trying to understand if this is the case here. > > 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? Well, if you want to have the certificate provision based around an in-band, or client-driven, registration protocol, then I think you need a method for having the certificate (or PGP key) signed. It seems reasonable to want to standardize this. Dave.
