|Avoiding reinventing the wheel
||[Dec. 6th, 2007|11:53 am]
During the more than 20-years history of internet, a lot of standards which can be relevant for our problem were developed.|
These standards are typically based on big amount of reaserch and address problems which new developers are not even aware of.
So it is good practice to use existing standard whenever available, instead of inventing something own.
Which standaras can be relevant to distributed blogging?
1. HTTP and (X)HTML - these standards and their implementation in web browsers and web servers made entire fenomenon of blogging possible. Every user of internet has browser, and can read HTML pages via HTTP protocol. Since blogging is public activity, than
content which is not intended for limited auditory, should be available for casual user, which have nothing more than browser.
HTTP is very flexible protocol and can be used for interserver communication as well as in server-to-client communication.
There are extensions to HTTP which allow remote procedure call interfaces over HTTP (XML-RPC, SOAL) filesystem object manupulation with versioning (WebDAV) etc. These extensions are well supported by existing software.
2. Digital singing and public key encryption.
Digital signing is tricky thing. Existing digital signature algorithms sign sequence of bytes, while blog entries are formatted text which can be reformated during integration into variouws feed, friend-tape etc. There are two ways to handle this situation:
sign text as byte stream and base64 encode it or use some canonization method which allow to format same message into same stream of bytes regardless any reformatting which do not change content of messages. Later is covered by RFC 3076 and signature syntax by RFC 3275. I prefer this way, because it leaves message clear-text and readable by casual user who doesn't have cryptography support in the browser.
Encrypted messages are better handled by former way, because they shouldn't be readable by non-authorized person, This is covered by RFC 3852 also known as PKCS#7.
3. Cryptography support in browsers
Internet Explorer can implement all cryptography functions using CAPICOM Active-X object. Unfortunately this object is not included into default Windows installation and have to be downloaded from Microsoft site.
Less widespread browsers such as Konqueror and Opera typically implement Mozilla-compatible interface
4. Secure connections
There is standard for encrypted and authenticated TCP connections which can be used for any TCP-based protocol - TLS (RFC 4346) also known as SSL. Since it is already implemented in all browsers and there are a lot of publically available implementations, we do not need to concern with protocol details. We should only take into account basic security principles of this protocol. Most basic one is that server have to be authenticated using public key cryptography, otherwise connection cannot be considered secure regardless of encryption strength. If we are not sure whom we communicate with, what's a talk about security. Client authentication is a bit less important. Once secure (encrypted) channel to trusted server is established, client can authenticate itself using other methods such as passwords.
5. Public key infrasturctire
Both digital signing and encryption and TLS rely on the public key infrastructure. They need reliable and trusted way to find out whom public key belongs to, or even (in case of encryption) find out which public key of particular person to encrypt message for him.
There are two standartized types of public key infrastructure - X.509 (RFC 3280)
and decentralized Web of trust used by whidespread PGP/GnuPG programs.
X.509 has an advantage that it is already supported by browsers and various server-side TLS implemetations, but most people thinks that it is strictly centralized - requires that public keys should be signed by some official Certification Authorities,
such as VeriSign, which charge a lot of money for digital certificates. Really, it is not true. Certification authority is, by definition, someone, whom your browser trust identifying other parties. Nothing more. So it is quite possible to implement web of trust concept using X.509 certificate format.