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 :-)
> works reliably I don't know. This is all particularly useful in the case
> whether the certificate contains multiple identifiers, ambiguous identifiers
> (like wildcards) or no identifiers at all.
>
Yes, that's what XEP-0178 is for; but you're right, maybe it's a
redundancy in this case, since the from attribute can be used for
identification.
> 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).
--
Daniele
