I wouldn't want to tar all of the respondents in this interesting thread with one brush, but I've got a feeling that for many it would be useful to step back and have a look at what "security" is trying to achieve for an electronic transaction such as the email messages of the author.
Although in general usage the word "security" has a range of meanings, when we talk about it in this context, we are mostly referring to the following:
- encryption, to protect a communication against disclosure to other than intended recipients
- signing, to "guarantee" the identity of the sender and to provide for non-repudiation of the message (I can prove that you sent the message, and that it hasn't be tampered with)
So PGP is a good solution for encryption, but would require a deal more before it could be used for non-repudiation. For example, there is a PGP key pair for Patrick Keogh. I assert that I am Patrick Keogh, and indeed the same Patrick Keogh, but the reader would be foolish indeed to assume that any message that comes PGP-signed by Patrick Keogh is written by this/. contributor.
All of that "bureaucratic" stuff that you get with X.509 and an appropriate X.500 infrastructure (RAs, CAs, paying for stuff etc. etc. etc.) end up being necessary if you want a general and flexible "security" solution for electronic transactions. And that's not all... you also need traditional network and server security, a model for authorisation (all the above helps decide who the user is, but you also need to decide what they are authorised to do), well thought out security policy, appropriate auditing etc. etc. etc.
I guess in summary, it is like anything else, the devil is in the detail. Doing e-business security without a really good idea of what you're trying to achieve, and what the pitfalls are, is like do it yourself brain surgery.
Slashdot Mirror
I wouldn't want to tar all of the respondents in this interesting thread with one brush, but I've got a feeling that for many it would be useful to step back and have a look at what "security" is trying to achieve for an electronic transaction such as the email messages of the author.
/. contributor.
... you also need traditional network and server security, a model for authorisation (all the above helps decide who the user is, but you also need to decide what they are authorised to do), well thought out security policy, appropriate auditing etc. etc. etc.
Although in general usage the word "security" has a range of meanings, when we talk about it in this context, we are mostly referring to the following:
- encryption, to protect a communication against disclosure to other than intended recipients
- signing, to "guarantee" the identity of the sender and to provide for non-repudiation of the message (I can prove that you sent the message, and that it hasn't be tampered with)
So PGP is a good solution for encryption, but would require a deal more before it could be used for non-repudiation. For example, there is a PGP key pair for Patrick Keogh. I assert that I am Patrick Keogh, and indeed the same Patrick Keogh, but the reader would be foolish indeed to assume that any message that comes PGP-signed by Patrick Keogh is written by this
All of that "bureaucratic" stuff that you get with X.509 and an appropriate X.500 infrastructure (RAs, CAs, paying for stuff etc. etc. etc.) end up being necessary if you want a general and flexible "security" solution for electronic transactions. And that's not all
I guess in summary, it is like anything else, the devil is in the detail. Doing e-business security without a really good idea of what you're trying to achieve, and what the pitfalls are, is like do it yourself brain surgery.