On 23 Apr 2013 08:17, "Daniele Ricci" <[email protected]> wrote:
>
> On Tue, Apr 23, 2013 at 2:06 PM, Dave Cridland <[email protected]> wrote:
> > So in X.509 terms, the peer provides a certificate, and you assemble a
chain
> > back to a known trust anchor (typically a public CA, by walking back
through
> > the issuers). If that chain looks good (and if the other parameters on
the
> > certificate, such as expiry, are OK, and if the certificate has not been
> > explicitly revoked, and so on) then you trust the certificate, and can
use
> > the identifier information within it (Subject Alternative Names, or the
> > Subject DN itself, typically extracting CommonNames in ways that leave
me
> > queasy) to decide on an identifier.
> >
>
> Maybe I wasn't clear enough, sorry. Server does check for its own
> signatures on client's public key just as a server inspects the CA
> chain for X.509 certificates. That is possible because during prior
> registration to the XMPP server, client public key is signed by the
> server private key (no XEP for this yet AFAIK :-)
>
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.
You could work around this by separating the functions - so the server
trusts a third party, which itself signs the keys of registering clients.
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.
> > You've given how to extract identifiers from PGP keys, which seems
useful,
> > but not how each party might decide to trust the key at all.
> >
>
> I described client authentication before; client instead, in my case,
> has already a list of valid fingerprints it can accept as valid
> ("trusted" servers I might say).
Again, you see, I worry that by conflating the server's key with the trust
anchor, you'd be centralising key compromise cases.
I don't see how you'd handle key rollover either.
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.
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.
Dave.
