Re: [Standards] XMPP server certificate
Peter Saint-Andre wrote: On 12/15/09 12:47 PM, Dirk Meyer wrote: Jonathan Schleifer wrote: Peter Saint-Andre wrote: Who said that including CAs is evil? My argument is that policies differ. Just because a lot of people use a particular CA doesn't make it good. Deciding on policies is something the user should do, not the client. I for example trust something open and transparent like CACert much more than some company like VeriSign etc. And my sister has no idea what you are talking about, what these CA things are, why there is a warning, and how she can check these strange numbers called fingerprint. IMHO clients should include a basic sets of CAs. The model in Mozilla, OS X, and other platforms seems satisfactory: they include a common set of CAs but, if you really know what you are doing, you can explicitly signify that you trust CAs outside that set. The latter option is appropriate for geeks, but not for people like your sister. FWIW, I don't think that we need to standardize on CAs within XMPP clients and servers; instead it makes more sense to re-use the certificate bundles provided at the level of the operating system. I tend to agree. If you load the Trust Anchors (TAs) in to the application, then when I want to configure the TAs that my relying parties use in my enterprise I need to have another mechanism to rip out the ones I don't like. spt
Re: [Standards] XMPP server certificate
On 12/15/09 12:47 PM, Dirk Meyer wrote: > Jonathan Schleifer wrote: >> Peter Saint-Andre wrote: >> >>> Who said that including CAs is evil? >>> >>> My argument is that policies differ. Just because a lot of people use >>> a particular CA doesn't make it good. >> Deciding on policies is something the user should do, not the client. I >> for example trust something open and transparent like CACert much more >> than some company like VeriSign etc. > > And my sister has no idea what you are talking about, what these CA > things are, why there is a warning, and how she can check these strange > numbers called fingerprint. IMHO clients should include a basic sets of > CAs. The model in Mozilla, OS X, and other platforms seems satisfactory: they include a common set of CAs but, if you really know what you are doing, you can explicitly signify that you trust CAs outside that set. The latter option is appropriate for geeks, but not for people like your sister. FWIW, I don't think that we need to standardize on CAs within XMPP clients and servers; instead it makes more sense to re-use the certificate bundles provided at the level of the operating system. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XMPP server certificate
Hi, Jonathan Schleifer wrote: > Peter Saint-Andre wrote: > >> Who said that including CAs is evil? >> >> My argument is that policies differ. Just because a lot of people use >> a particular CA doesn't make it good. > > Deciding on policies is something the user should do, not the client. I > for example trust something open and transparent like CACert much more > than some company like VeriSign etc. And my sister has no idea what you are talking about, what these CA things are, why there is a warning, and how she can check these strange numbers called fingerprint. IMHO clients should include a basic sets of CAs. Dirk -- In some cultures what I do would be considered normal.
[Standards] UPDATED: XEP-0189 (Public Key Publishing)
Version 0.10 of XEP-0189 (Public Key Publishing) has been released. Abstract: This specification defines a method by which an entity can publish its public keys over XMPP. Changelog: Major revision; split into three namespaces and three corresponding PEP nodes, one each for public keys, attestations, and revocations; iterated the version number for public keys to urn:xmpp:pubkey:1; added detailed data to each node payload; removed some use cases to simply the protocol. (psa) Diff: temporarily unavailable URL: http://xmpp.org/extensions/xep-0189.html
