Secure or not secure, that is the question...

Apoteket (the Swedish monopoly pharmacy) has a website that can receive electronic prescriptions from the doctors that support it. Electronic prescriptions is not something new where I live, but what is new is the ability to use the web to ask the doctor for one. If you want more of the same medication you have used before that is.

That first step, to get the prescription went fine. The prescription also ended up at the Apoteket website. But now the problems started.

First I tried with Safari in MacOSX 10.5.1. It worked fine until I tried to submit a form with my name and address. The name fields where dimmed (but empty) and submitting was impossible as it required data in the name fields.

Second try was with Firefox. This time I took more closely note of all certificate problems that arised. First the cert of the Apoteket website had expired.

When I later identified myself with the “nice” (irony) Java implementation of BankID I got a warning for that transaction as well, as the signature on the java applet could not be verified. Of course due to mismatch on what CA I trust and what CA they have used when getting their certificate.

It is the X.509 multiple root mechanism, where there is no automatic mechanism for finding a trust chain from me to the cert I am to verify, that is broken. And the major reason why I am supporter of single trust root solutions in the cases where not an explicit mesh/web of trust is used, such as in PGP.

I had no choice but accepting all of these certificates that I could not verify, while they asked for strong security in the form of the BankID solution. Not really balance in the trust between me and Apoteket. On top of this, they only asked for credit card ID and expiration date. No security code.